Hands-On Lab: Building Highly Available Architectures with ALB and ASG

Welcome to this hands-on lab on designing highly available and fault-tolerant architectures in AWS. In this 30-minute lab, you will deploy a multi-AZ web architecture using an Application Load Balancer (ALB) and an Auto Scaling Group (ASG). This setup ensures that if one Availability Zone experiences an outage or an EC2 instance fails, your application remains online.

Prerequisites

Before starting this lab, ensure you have the following:

AWS Account: Access to an AWS account with Administrator or PowerUser IAM permissions.
AWS CLI: The AWS CLI version 2 installed and configured (aws configure) with valid credentials.
Default VPC: An existing default VPC with at least two subnets in different Availability Zones.
Prior Knowledge: Basic understanding of AWS Regions, Availability Zones, and basic Linux command-line navigation.

Learning Objectives

By completing this lab, you will be able to:

Provision a Launch Template containing a bootstrapping script to automate web server setup.
Deploy an Application Load Balancer to distribute incoming traffic across multiple Availability Zones.
Configure an Auto Scaling Group to enforce high availability and self-healing across instances.
Simulate fault tolerance by intentionally terminating an instance and observing the automated recovery.

Architecture Overview

The following diagram illustrates the resilient architecture you will build. Traffic flows from the end user through the load balancer, which distributes it across healthy instances maintained by the Auto Scaling Group.

Loading Diagram...

Step-by-Step Instructions

Step 1: Create a Security Group

First, we need to create a security group that allows incoming HTTP traffic from anywhere so users can reach our web application.

bash

# Find your Default VPC ID
aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query "Vpcs[0].VpcId" --output text

# Create the Security Group (Replace <YOUR_VPC_ID> with the output from above)
aws ec2 create-security-group \
    --group-name brainybee-ha-sg \
    --description "Allow HTTP for High Availability Lab" \
    --vpc-id <YOUR_VPC_ID>

# Authorize port 80 (HTTP) ingress (Replace <SG_ID> with the ID returned by the previous command)
aws ec2 authorize-security-group-ingress \
    --group-id <SG_ID> \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

[!TIP] Always note down your output IDs (like sg-0abcd1234efgh5678), as you will need them in subsequent steps.

▶Console alternative

Navigate to EC2 Dashboard > Security Groups.
Click Create security group.
Name it brainybee-ha-sg.
Under Inbound rules, click Add rule, select HTTP, and set the source to 0.0.0.0/0.
Click Create security group.

📸 Screenshot: Security Group Inbound Rules configured for HTTP.

Step 2: Create a Launch Template

A Launch Template holds the configuration for our EC2 instances. We will include a user data script that automatically installs a web server when the instance boots.

First, create a local file named userdata.txt with the following content:

bash

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from BrainyBee! My AZ is $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</h1>" > /var/www/html/index.html

Now, execute the CLI command to create the template:

bash

# Replace <SG_ID> with your Security Group ID
# The AMI ID provided is a generic Amazon Linux 2023 AMI in us-east-1. If you are in a different region, use an applicable Amazon Linux 2 AMI ID.
aws ec2 create-launch-template \
    --launch-template-name brainybee-web-template \
    --launch-template-data '{"ImageId":"ami-0a3c3a20c09d6f377","InstanceType":"t2.micro","SecurityGroupIds":["<SG_ID>"],"UserData":"'$(base64 userdata.txt | tr -d '\n')'"}'

▶Console alternative

Navigate to EC2 Dashboard > Launch Templates > Create launch template.
Name: brainybee-web-template.
AMI: Amazon Linux 2023 AMI.
Instance type: t2.micro.
Select the brainybee-ha-sg security group.
Expand Advanced details, scroll to User data, and paste the bash script provided above.
Click Create launch template.

Step 3: Create a Target Group and Load Balancer

The Application Load Balancer needs a Target Group to know where to send traffic.

bash

# Create the Target Group (Replace <YOUR_VPC_ID>)
aws elbv2 create-target-group \
    --name brainybee-tg \
    --protocol HTTP \
    --port 80 \
    --vpc-id <YOUR_VPC_ID>

# Get two subnet IDs for your default VPC
aws ec2 describe-subnets --filters "Name=vpc-id,Values=<YOUR_VPC_ID>" --query "Subnets[0:2].SubnetId" --output text

# Create the ALB (Replace <SUBNET_1>, <SUBNET_2>, and <SG_ID>)
aws elbv2 create-load-balancer \
    --name brainybee-ha-alb \
    --subnets <SUBNET_1> <SUBNET_2> \
    --security-groups <SG_ID>

# Create a Listener (Replace <ALB_ARN> and <TG_ARN> with outputs from the above commands)
aws elbv2 create-listener \
    --load-balancer-arn <ALB_ARN> \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=<TG_ARN>

▶Console alternative

Navigate to EC2 Dashboard > Target Groups > Create target group.
Choose Instances, name it brainybee-tg, port 80, and select your default VPC. Click Next > Create.
Navigate to Load Balancers > Create load balancer > Application Load Balancer.
Name it brainybee-ha-alb, Internet-facing, IPv4.
Select your default VPC and map at least two distinct subnets.
Select the brainybee-ha-sg security group.
Under Listeners and routing, forward to brainybee-tg.
Click Create load balancer.

📸 Screenshot: Load Balancer listener forwarding port 80 to the target group.

Step 4: Create an Auto Scaling Group

We will now link everything together by creating an ASG that automatically launches EC2 instances into our Target Group.

bash

# Create the Auto Scaling Group (Replace <SUBNET_1>,<SUBNET_2> and <TG_ARN>)
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name brainybee-ha-asg \
    --launch-template LaunchTemplateName=brainybee-web-template,Version=1 \
    --min-size 2 \
    --max-size 4 \
    --desired-capacity 2 \
    --vpc-zone-identifier "<SUBNET_1>,<SUBNET_2>" \
    --target-group-arns <TG_ARN>

▶Console alternative

Navigate to EC2 Dashboard > Auto Scaling Groups > Create Auto Scaling group.
Name: brainybee-ha-asg, select brainybee-web-template. Click Next.
Select your VPC and choose two Availability Zones. Click Next.
Select Attach to an existing load balancer and choose your Target Group (brainybee-tg). Click Next.
Set Desired: 2, Min: 2, Max: 4. Click Skip to review > Create Auto Scaling group.

Checkpoints

Verify that your highly available architecture is functioning correctly.

1. Verify ALB DNS Routing

Retrieve your Load Balancer's DNS name (e.g., brainybee-ha-alb-12345.us-east-1.elb.amazonaws.com) from the console or CLI (aws elbv2 describe-load-balancers).

Run the following command a few times:

bash

curl http://<YOUR_ALB_DNS_NAME>

Expected Result: You should see "Hello from BrainyBee!" followed by different Availability Zone names (e.g., us-east-1a, us-east-1b) as the ALB routes your requests to different instances.

2. Test Fault Tolerance (Self-Healing)

Let's test the resiliency of the architecture.

Find an instance ID running in your ASG.
Terminate it forcefully:

bash

aws ec2 terminate-instances --instance-ids <INSTANCE_ID>

Wait 2-3 minutes and check the ASG status. Expected Result: The Auto Scaling Group will notice the health check failure and automatically launch a replacement instance to maintain the desired capacity of 2.

Loading Diagram...

Troubleshooting

If you run into issues, refer to this table of common pitfalls:

Error / Symptom	Likely Cause	Solution
ALB DNS times out	Security Group does not allow HTTP (port 80) from 0.0.0.0/0.	Check the Inbound Rules on `brainybee-ha-sg` and ensure Port 80 is open to the world.
Targets are "Unhealthy"	Instances failed to configure the web server.	Check if the AMI selected in the Launch Template matches the User Data (apt-get vs yum).
Cannot create ASG	Subnets provided are in the same Availability Zone.	Ensure `<SUBNET_1>` and `<SUBNET_2>` map to different AZs in your AWS Region.

Clean-Up / Teardown

[!WARNING] Remember to run the teardown commands to avoid ongoing charges. Load balancers and running EC2 instances incur hourly costs outside the free tier.

To destroy the infrastructure we just provisioned, execute the following CLI commands in order:

bash

# 1. Delete the Auto Scaling Group (Force delete to terminate instances)
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name brainybee-ha-asg --force-delete

# Wait ~3 minutes for the EC2 instances to terminate completely before proceeding.

# 2. Delete the ALB listener 
aws elbv2 delete-listener --listener-arn <LISTENER_ARN>

# 3. Delete the Load Balancer
aws elbv2 delete-load-balancer --load-balancer-arn <ALB_ARN>

# 4. Delete the Target Group
aws elbv2 delete-target-group --target-group-arn <TG_ARN>

# 5. Delete the Launch Template
aws ec2 delete-launch-template --launch-template-name brainybee-web-template

# 6. Delete the Security Group (Must wait until instances are terminated)
aws ec2 delete-security-group --group-id <SG_ID>