Introduction

In modern enterprise cloud environments, application downtime leads directly to lost revenue and poor user experience. Designing a High Availability (HA) architecture ensures your applications remain resilient, performant, and operational even during server failures or sudden traffic surges.

In this step-by-step tutorial, we will construct a fault-tolerant, highly available architecture on AWS. We will deploy an Application Load Balancer (ALB) and an Auto Scaling Group (ASG) across multiple Availability Zones using custom private networks.

What is High Availability in Cloud Computing?

A High Availability Architecture eliminates single points of failure by distributing application workloads across isolated data centers.

Core pillars of cloud high availability include:

• Redundancy: Provisioning duplicate resources across multiple Availability Zones (AZs).
• Load Balancing: Distributing client traffic evenly across healthy server instances.
• Auto Scaling: Dynamically adjusting compute capacity up or down based on real-time traffic demand.

Core Architecture Overview

Our production-grade setup will consist of the following components:

• Custom VPC: A dedicated network with two public subnets and two private subnets spanning two Availability Zones (us-east-1a and us-east-1b).
• Application Load Balancer (ALB): Placed in public subnets to receive external HTTP traffic and forward requests to backend web servers.
• Auto Scaling Group (ASG): Deployed across private subnets to automatically manage EC2 web server lifecycles based on CPU utilization.
• Golden Amazon Machine Image (AMI): A customized web server image containing pre-installed application software.

Step-by-Step Implementation Guide

Step 1: Create a Multi-AZ Custom VPC and Subnets

First, build an isolated virtual network with public and private subnets across two Availability Zones:

• Open the VPC Dashboard in the AWS Management Console and click Create VPC.
• Select VPC only -> Name: myvpc | IPv4 CIDR Block: 10.0.0.0/16. Click Create VPC.
• Navigate to Subnets -> Click Create subnet and create four subnets in myvpc:
  • Public-Subnet-1: AZ us-east-1a | CIDR 10.0.1.0/24
  • Public-Subnet-2: AZ us-east-1b | CIDR 10.0.2.0/24
  • Private-Subnet-1: AZ us-east-1a | CIDR 10.0.3.0/24
  • Private-Subnet-2: AZ us-east-1b | CIDR 10.0.4.0/24

Step 2: Configure Internet Gateway and Route Tables

Next, set up public routing so your Application Load Balancer can receive internet traffic:

• Go to Internet Gateways > Click Create internet gateway -> Name: MyInternetGateway.
• Select MyInternetGateway -> Click Actions -> Select Attach to VPC -> Choose myvpc.
• Go to Route Tables -> Click Create route table -> Name: Public-Route-Table | VPC: myvpc.
• Select Public-Route-Table -> Open Routes tab -> Click Edit routes -> Add Route:
  • Destination: 0.0.0.0/0 | Target: MyInternetGateway
• Open Subnet associations tab -> Click Edit subnet associations -> Select Public-Subnet-1 and Public-Subnet-2.

Step 3: Launch Base Instance and Create a Custom Golden AMI

Now, configure a temporary web server to build a reusable pre-configured Machine Image (AMI).

• Navigate to the EC2 Dashboard -> Click Launch Instance.
• Name: Template-Web-Server | AMI: Amazon Linux 2023 | Type: t2.micro.
• Network: myvpc | Subnet: Public-Subnet-1 | Enable Auto-assign Public IP.
• Configure Security Group: Allow SSH (Port 22) from your IP and HTTP (Port 80) from anywhere.
• Connect via SSH and install the Apache Web Server:

sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd

# Create custom homepage
echo "<h1>Hello from High Availability AWS Architecture</h1>" | sudo tee /var/www/html/index.html
    

• Return to the EC2 Console -> Select Template-Web-Server -> Click Actions -> Image and templates -> Create image.
• Set Image name to MyWebServerAMI -> Click Create image. Terminate Template-Web-Server once AMI status is Available.

Step 4: Create an Application Load Balancer and Target Group

Configure an Application Load Balancer to accept incoming HTTP requests and health-check targets:

• In the EC2 Console, navigate to Target Groups -> Click Create target group.
• Choose Instances -> Group name: MyTargetGroup | Protocol: HTTP (Port 80) | VPC: myvpc.
• Health check path: /index.html -> Click Next -> Click Create target group.
• Navigate to Load Balancers -> Click Create load balancer -> Select Application Load Balancer.
• Name: MyPublicALB | Scheme: Internet-facing | VPC: myvpc.
• Mappings: Select both us-east-1a (Public-Subnet-1) and us-east-1b (Public-Subnet-2).
• Security Group: Create an ALB Security Group allowing HTTP (Port 80) from 0.0.0.0/0.
• Listeners and routing: HTTP (Port 80) -> Forward to MyTargetGroup.
• Click Create load balancer.

Step 5: Create Launch Template and Auto Scaling Group

Deploy an automated capacity manager across private subnets for optimal elasticity:

• Navigate to Launch Templates -> Click Create launch template.
• Name: MyWebLaunchTemplate | AMI: Select MyWebServerAMI | Type: t2.micro.
• Security Group: Create an Internal Web Security Group allowing HTTP (Port 80) ONLY from the MyPublicALB Security Group.
• Navigate to Auto Scaling Groups -> Click Create Auto Scaling Group.
• Name: MyAutoScalingGroup -> Launch template: MyWebLaunchTemplate.
• Network: myvpc -> Subnets: Select Private-Subnet-1 and Private-Subnet-2.
• Attach to an existing load balancer -> Select MyTargetGroup.
• Set Group size: Desired: 2 | Min: 2 | Max: 5.
• Dynamic scaling policy: Target tracking policy -> Metric type: Average CPU utilization -> Target value: 50%.
• Click Create Auto Scaling Group.

Step 6: Testing High Availability and Elasticity

Verify that your infrastructure operates seamlessly under live conditions:

Test Load Balancer Routing

• Copy the DNS name from your MyPublicALB dashboard page.
• Paste the URL into your browser. You should see the message:Hello from High Availability AWS Architecture

Test Auto Scaling Under Load

• SSH into one of the running instances via a bastion host or AWS Systems Manager Session Manager.
• Install and execute the stress utility to spike CPU utilization above 50%:

# Install stress utility
sudo yum install stress -y

# Generate CPU load for 5 minutes
stress --cpu 2 --timeout 300
    

• Open the Auto Scaling Group dashboard. ASG will detect the high CPU utilization metric and automatically spin up additional EC2 instances across private subnets to handle the capacity.

Security Best Practices for AWS High Availability

• Keep Application Servers Private: Never assign public IP addresses to backend instances in an Auto Scaling Group. Keep compute nodes isolated in private subnets.
• Restrict Security Group Access: The Security Group attached to private EC2 instances should accept HTTP traffic ONLY from the Application Load Balancer’s Security Group ID.
• Clean Up Cloud Resources: After testing, terminate the Auto Scaling Group, delete the Load Balancer, and release Elastic IPs to avoid unexpected AWS charges.

Troubleshooting Common Load Balancer & ASG Issues

Diagnose and resolve common setup issues when deploying load-balanced environments:

Error 1: Target Group Instances Fail Health Checks

• The Cause: The Security Group attached to EC2 instances is blocking HTTP Port 80 traffic originating from the Load Balancer, or Apache is not running.
• The Fix: Ensure Apache starts automatically on boot (systemctl enable httpd) and verify that the EC2 Security Group permits inbound Port 80 traffic from the ALB’s Security Group.

Error 2: Auto Scaling Instances Launch and Immediately Terminate

• The Cause: The Golden AMI is corrupted or missing application files required by the health check path (/index.html).
• The Fix: Verify that /var/www/html/index.html exists and returns an HTTP 200 OK response before generating the AMI.