Building a Highly Available Architecture on AWS

High availability is a critical aspect of modern cloud infrastructure, ensuring that applications remain accessible even in the event of system or network failures. In this lab, I set up a highly available architecture using AWS services across two Availability Zones (AZs). Below, I’ll walk through the steps I took to achieve this, supported by screenshots from my build.

1. Creating a New VPC with Multiple Subnets

I started by creating a new VPC named KingsonHA-Lab-SG. To ensure high availability, I configured:

2 Availability Zones (AZs)

4 Subnets in total (2 public and 2 private, one pair per AZ)

1 NAT Gateway for outbound internet access from the private subnets

This setup ensures that workloads can fail over between AZs if one becomes unavailable.

1. Enabling Auto-Assign Public IPv4 Addresses

For both public subnets, I enabled the Auto-assign Public IPv4 Address option. This guarantees that any instance launched in these subnets will automatically receive a public IP, making them accessible over the internet when needed.

1. Configuring Security Groups

Next, I created a Security Group dedicated to my architecture. I edited the inbound rules as follows:

HTTP (Port 80): Allowed traffic from all IPs (0.0.0.0/0) to make my web server accessible publicly.

SSH (Port 22): Restricted access to my own IP address for secure remote management.

This ensures controlled but secure access to the environment.

1. Creating a Launch Template with User Data

I created a Launch Template that defines the configuration for EC2 instances. Within the template:

I attached the Security Group I created earlier.

I added User Data to automatically install and configure the application (such as a simple web server) when instances launch.

This automation ensures consistency across all instances deployed by the Auto Scaling Group (ASG).

1. Setting Up an Auto Scaling Group (ASG) with an Application Load Balancer (ALB)

Using the Launch Template, I created an Auto Scaling Group (ASG):

I selected both public subnets across the two Availability Zones.

During ASG creation, I also configured an Application Load Balancer (ALB) to distribute incoming traffic evenly across the EC2 instances.

The ASG ensures scalability, while the ALB improves availability by routing traffic intelligently.

1. Testing the Load Balancer

To validate my setup, I tested the ALB by accessing its DNS name in my browser. With each refresh, I observed the public IP address change—confirming that the ALB was successfully balancing requests across multiple instances in different AZs.

1. Achieving High Availability

By hosting the same application on two instances spread across two Availability Zones, I ensured redundancy. If one instance or AZ fails, traffic automatically fails over to the healthy instance in the other AZ.

This demonstrates how a well-architected AWS environment can achieve high availability and fault tolerance with minimal downtime.

Final Thoughts

This hands-on lab reinforced my understanding of how to design and implement a highly available architecture on AWS. Leveraging VPCs, subnets, security groups, launch templates, ASGs, and ALBs provides the foundation for resilient, scalable cloud solutions.

With this setup, I successfully built an environment capable of handling failures gracefully, ensuring uninterrupted application availability.