Beginner’s Guide to a Scalable and Highly Available 3-tier Application

In this guide, I will walk you through designing a highly available and scalable architecture for deploying a 3-tier application on AWS. As we go further, we will also highlight some best practices. You will gain an understanding of basic AWS services like Virtual Private Cloud (VPC), subnet, route table, etc., and how they work together. This guide is designed for beginners and aims to help you create your architecture.

What is High Availability?

High availability (HA) doesn't aim to prevent failures entirely but ensures that when failures occur, the system recovers quickly to minimize downtime. High availability focuses on maximizing system uptime.

Understanding what an Availability Zone (AZ) means is essential before talking about high availability on AWS. An AZ is a physical location with one or more data centers within a specific AWS region. These AZs are geographically isolated from one another. Deploying resources (such as EC2 instances or databases) across multiple AZs ensures that our application remains operational even if one AZ fails, making it highly available.

Regions are represented by their name and code. For example, a region with code us-east-1 represents the US East (N. Virginia). Each region has a certain number of AZs. Depending on how highly available we want our application to be, we must find a region that has the required number of Az we need. For example, if we select a us-east-1 region to deploy our application, Hosting our application in us-east-1a AZ and us-east-1b AZ will make the application highly available even if one AZ fails due to an outage. Our Application in both AZs makes it highly available..

Set Up Your Virtual Private Cloud (VPC)

A VPC (Virtual Private Cloud) is an isolated section of AWS where you can launch and manage resources. It's essentially your private network in the AWS cloud. You can control access and configure how resources in the VPC communicate with each other and the internet.

When setting up your VPC, here are some best practices:

• Use Multiple AZs: When setting up your VPC, you need to select a region; you Deploy your VPC in a region with multiple AZs to ensure a highly available architecture. Not all regions have the same number of AZs.

• Plan CIDR Block: This refers to your VPC's IP address range. Make sure the CIDR blocks don’t overlap with other networks.

Create Subnets

A Subnet is a subdivision of your VPC where you can run resources like EC2 instances. Each subnet is associated with a single AZ, so if an AZ fails, the subnet in that AZ fails as well. You can create multiple subnets within an AZ, but a single subnet can’t span multiple AZs.

A tier separates the application component. The following is a list of tiers and the type of subnet they reside in.

1. Web Tier: This tier will contain the frontend (e.g., a React app) accessible from the public internet. Therefore, the instances in this tier will reside in a public subnet.

2. Application Tier: This tier will contain the backend (e.g., a Node.js app) that processes requests. To secure this tier, its instances will reside in a private subnet inaccessible from the internet.

3. Database Tier: This tier will store the application's data using a managed service like Amazon RDS (MySQL) and reside in a private subnet.

Example Subnet Layout

• AZ 1 (us-east-2a):

  • subnet-web: Public (Web tier)

  • subnet-app: Private (App tier)

  • subnet-db: Private (Database tier)

• AZ 2 (us-east-2b):

  • subnet-web: Private (Web tier)

  • subnet-app: Private (App tier)

  • subnet-db: Private (Database tier)

Route Tables

A Route Table contains rules for routing traffic in and out of subnets. Each subnet must be associated with a route table. With a route table, you can determine what happens to data when it leaves the subnet.

• Main Route Table: Automatically created with the VPC.

• Custom Route Table: You can create custom route tables and associate them with specific subnets to define traffic flow.

Establish Internet Connectivity: Internet Gateway (IGW)

The internet gateway is responsible for traffic leaving the VPC. By default, all subnets are private. To allow internet access to the subnet for our web, we need to set up an Internet Gateway (IGW), which is region-resilient and connects the VPC to the Internet. Once the IGW is attached to the VPC, we update the route table for the web subnet, routing all internet traffic (IPv4 and IPv6) through the IGW. This makes the web subnet public.

Set Up Load Balancing and Target Groups

A Load balancer is an AWS service that automatically distributes incoming application traffic across multiple EC2 instances. Our architecture has a load balancer for the web and app tier; for the database, Amazon RDS has a built-in mechanism to handle availability and read scalability.

1. Web Tier Load Balancer: A public-facing Application Load Balancer (ALB) handles incoming HTTP/HTTPS traffic and routes it to the EC2 instances in the public web subnet.

2. App Tier Load Balancer: An internal ALB distributes traffic within the application tier, handling communication between the web and app tiers without exposing the app tier to the Internet.

Implement Auto Scaling

Auto Scaling adjusts the number of EC2 instances based on demand, ensuring the application can handle traffic spikes while minimizing costs during low-demand periods. We have an auto-scaling group for the web and app tier, but the database tier handles high availability with the primary and standby instances.

• Web Tier: An Auto Scaling Group ensures at least one instance in each AZ. Auto Scaling can add more instances up to a predefined limit as demand increases.

• App Tier: Like the web tier, this tier also uses Auto Scaling to maintain one instance per AZ and scale up when necessary.

Stay tuned for future posts to discuss security groups, advanced monitoring, etc.