Reference Architecture — Web Application Hosting (Part II)
A brief step-by-step walk through in designing a model architecture for any (read “most”) web hosting applications.
Deploying an n-tier architecture in AWS warrants certain intelligent design principles that demand best practices in security, operational resiliency and high availability.
6. A good step towards securing your AWS deployment would be to add a Web Application Firewall(WAF) that will secure the perimeter of your AWS resources. AWS WAF is a service that helps protect your web applications from common web exploits such as SQL injection or cross-site scripting.
Never say no to security!
Now, comes the design for resiliency.
While having the user(customer) HTTP requests be presented to the web server is what we intended to do ultimately, we intend to throw in a couple of resources in between to better secure our AWS environment.
7. Chief among them, is the Elastic Load Balancer (ELB). ELB is a managed service from AWS that distributes the web traffic that is trying to hit your servers. Having an ELB in front of your web servers can serve dual purposes:
it can protect the IP address(es) of your actual web servers from being public while also distributing web traffic among the available servers in your cluster so that no single server takes the brunt of handling all the HTTP requests.
As an example, think of the following scenario:
Let’s assume that you know your EC2 web server can handle up to 25000 HTTP requests at once at peak load, and you have currently deployed 2 such EC2 web servers. You can configure your ELB such that either one EC2 server takes up all the load and anything overflowing the buffer limit of 25000 gets redirected to your second EC2 web server (or) both EC2 web servers share the workload at all times thereby being capable of handling 50000 HTTP requests together without overloading each other(preferred approach).
Hence, we proceed by adding an ELB with a public IP address. In other words, your Route 53 (Step 2: DNS server) actually redirects all incoming HTTP requests to the ELB creating an illusion to the customers(who are actually smart enough to lookup the IP address of the domain host) that the ELB is the actual web server. Anyone trying to flood your servers with fake HTTP requests will actually end up flooding your ELB and be unable to harm your actual web servers.
In essence, ELBs are just normal EC2 servers that perform this task of load distribution except that they are managed by Amazon based on the rules that are set by you.
Now that we have set up Load Balancers which distribute traffic between available web servers, let’s get to discussing the deployment of actual servers.
8. In AWS, as a general best practice, we deploy each tier of our n-tier architecture as a separate cluster in what can be defined in the network layer as a subnet.
For example, if the three tiers of your web application are the web tier, the application tier and the database tier (think of a LAMP stack), then the
cluster of web servers, the cluster of application servers, and the cluster of DB servers are all deployed in a separate subnet each governed by a set of rules customized for the servers within that subnet.
This separation of clustering will also enable to define custom rules for yet another feature offered by AWS which is called Auto Scaling. Each cluster can be set in a separate Auto Scaling group that defines the conditions under which the number of servers in that cluster should either scale up or scale down.
Such a design optimizes operational efficiency while making them resilient to failures. For example, if your website is heavy into data processing with a bulk of code running in the application server while the web servers simply establish a connection to your application and process HTTP servers, then going by the above example, you can have just 2 web servers that can cater to approx. 50000 HTTP requests concurrently while you can even have 200 application servers within the subnet hosting the application server clusters concurrently crunching your customer data.
Additionally as mentioned, you ensure that each of these clusters are placed in a separate subnet with custom rules(your web servers could only be allowed to receive HTTP, HTTPS traffic by opening up ports 80,443 while your application servers could only be allowed to listen on application specific port number). These subnets are also mandatorily made private meaning none of them can be directly be accessed from the open internet and can only be accessed by the ELB which will serve as a proxy for sending the HTTP requests to the servers.
As a final note, we deploy multiple clusters in multiple Availability Zones(AZs) so that the failure of any AZ won’t bring down your website.
The final tier of our n-tier application, the Database tier deserves special mention which is explained in the subsequent post: Part III