In this post we are going to look at a typical highly available 3 tier architecture implemented on AWS. We will look into compute options, load balancing, a few AWS database services and finally see how we can iteratively transition to serverless architecture.
The N-tier architecture is a well-known architecture that organises applications into a number of logical tiers. In theory, N can be any arbitrary number from but 3 tends to be the most common. In 3 tier architecture, applications are organised into the presentation tier, which implements application components that deals with user interface; the logic tier (sometimes referred to as application tier), where business logic are implemented; and the data tier, where the data associated with the application is stored and managed. The prime drivers for three-tier architecture are:
-
Decoupling
-
Independent scalability
-
Separately developed, managed and maintained by different teams
While we are now seeing more organisations that have applications that are born in the Cloud, it is very common for enterprises to have workload on-premises or ones that operate on Hybrid Cloud environment. Many of these enterprises are moving or planning to move their workload to the Cloud. The architecture of applications that are just born in Cloud and those that are just migrated to Cloud are typically quite different. Applications that are born in the Cloud tend to lean more towards the serverless computing model, whereas applications that are migrated from on-premises to the Cloud typically starts off with more IaaS services then progressively transition to use more PaaS or might even eventually move towards the serverless computing model.
Let’s say you have a 3-tier application that you would like to move to AWS. Unless you are lucky enough to work with stakeholders who have secured funding and have bought in to the rebuild story, chances are we will be talking about some sort of lift-and-shift as the first iteration. If your application is business critical, you would also want to design the application with High Availability in mind without completely rearchitecting. So let’s see how this can be achieved on AWS.
3 tier architecture using mostly IaaS
What I have shown above is a single-region highly available 3 tier architecture. In this architecture, we have:
-
A single VPC with an Internet Gateway.
-
2 availability zones are used. Note that this is the minimum and is required for Application Load Balancer.
-
An internet facing ALB (Application Load Balancer) deployed across 2 AZs in the public subnets. User will access the application through this ALB.
-
The ALB is attached to the Presentation tier’s EC2 ASG (Auto Scaling Group). The ASG is deployed to the Presentation tier’s private subnet and spans across 2 AZs.
-
The Application (Logic) tier is also implemented as EC2 ASG that spans across 2AZs, deployed in a separate private subnet and fronted with an Internal ALB.
-
Presentation tier talks to the Application (Logic) Tier via this Internal ALB.
-
Data tier is implemented using RDS. Here we use the multi AZ setup so we have a standby instance in the second AZ. We also implement read scale out using a read replica on the second AZ.
-
Here we use Route 53 private hosted zone with weighted routing to load balance the traffic from the Application (Logic) tier to the Data tier. If your application tier is able to split read traffic to write traffic then this may not be required, but it is still good to have in case you need to add more read replicas. Note that Route 53 is a workaround as RDS doesn’t provide a load balanced endpoint. Aurora does. If you don’t want to use Route 53, then you would have to roll out your own database load balancing solution that typically require you to manage yet another fleet of EC2 with custom software such as HAProxy.
-
Each Tier is secured by a security group that restricts traffic to the tier above. As such, the data tier’s security group only allows inbound traffic from the application tier’s security group. The Application tier’s security group allows outbound only to the data tier’s security group and allows inbound only from the Internal ALB. The Internal ALB’s security group allows outbound only to the application tier’s security group and allows inbound only from the presentation tier’s security group. The presentation tier’s security group allows outbound only to the Internal ALB’s security group and allows inbound only from the internet facing ALB. The internet facing ALB allows inbound from anywhere but only on HTTP/HTTPS ports (80 and 443).
The set up is fine and can run your workload just fine, but you got to remember that these are running on EC2 and with it comes the responsibility of patching. You also need to make sure that you right-size the instances. Implementing monitoring and fine-tuning your ASG’s setting can help but it does take a bit of maintenance overhead. So how can we improve this? The next architecture here can be the transition state architecture towards a full serverless model.
This transition state architecture is also interesting because it provides a mid point where organisations can reach a point where they are operating on Cloud native architecture but at the same time can be tweaked so that it is a Cloud-agnostic architecture.
3 tier semi-serverless architecture
In this transition state architecture:
-
The application (logic) tier is left intact. The argument for this is that this tier is typically the most complex. Hence, you got to really assess whether reworking this tier translate to cost saving or operational efficiency gain that you can justify.
-
RDS is replaced with Amazon Aurora or Aurora serverless. We still use multi AZ and replica. But with Aurora, see that we won’t need Route 53 to do the load balancing anymore because it comes by default with Aurora. However, this is entirely optional and would largely depend on your organisation’s strategy. Aurora is proprietary to AWS and some organisations can be a bit hesitant because they don’t like the idea of getting locked in to a single Cloud provider.
-
The presentation tier is replaced with simply configuring S3 bucket as the origin behind a CloudFront distribution for serving static contents. Now, I should reiterate that this is an AWS Architecture article, hence this architecture uses AWS services, but for organisations that want to be Cloud-agnostic, my suggestion is don’t panic. S3 is simply an object level storage. Objects can easily be moved; and CloudFront works with not just S3. It can work with any HTTP server as its origin.
-
For dynamic contents, API Gateway and Lambda functions come into the picture.
-
Optionally, there may be scenarios applicable for NoSQL database as well, and DynamoDB can be used.
-
To integrate API gateway to the Application tier, we use VPC links. This way, API Gateway can be configured to talk to the internal ALB.
While we can also go a step further and replace the EC2 instances in the Application tier with containers, this approach would largely depend on your organisation’s strategy as well. Like I mentioned above, some organisations are a bit hesitant to go all in to serverless because they fear that doing so will lock them in to a particular Cloud provider and it will be hard to move later on. If this case apply to you, then it probably make sense to take one step further and containerise the Application tier to use ECS or EKS and stop there.
Otherwise, see below for how we can further thin out and simplify this architecture by replacing the Application tier with more APIs and Lambda functions. Lambda can be configured to run in VPC as well and access resources in your VPC.
3 tier serverless architecture
Here we see the 3 tier serverless architecture on AWS. The key to this is that there is no server to manage, no EC2, no ASG, no ALB, hence the term serverless. While this most closely align to Web application that serves web pages, variations of this suits other applications as well. Another example is using this architecture as a mobile back end. In this scenario, the presentation tier would simply be the App in mobile, but the rest of the architecture will be very similar if not the same.
If I have a green field application, I would certainly choose to start right off with the 3 tier serverless architecture because it is so much simpler and efficient to operate. The only 2 final things I would caution for serverless would be:
- Security is non negotiable. You are still responsible for security. Ensure that you follow best practices: e.g. Give your Lambda functions least privilege IAM roles. Do not store credentials, use secrets manager instead.
- Assess the cost effectiveness of serverless carefully. If your workload is highly predictable or is constant, serverless might not always be the best choice. Reserved EC2 instances can offer big discounts.
As always, this is only a baseline or starting point but I do hope it helps. Please read through the official AWS documentation & blogs to assess your use case more closely.
