Lab: Designing Secure and Highly Available Load Balancing Architectures

This hands-on lab guides you through building a resilient, multi-AZ application architecture using AWS Application Load Balancers (ALB), Auto Scaling Groups (ASG), and security integrations. You will implement a Layer 7 solution that ensures high availability, scalability, and security through TLS termination and AWS WAF.

[!WARNING] This lab involves creating real AWS resources. Remember to run the teardown commands at the end to avoid ongoing charges.

Prerequisites

An active AWS Account with Administrator access.
AWS CLI installed and configured with appropriate credentials.
A VPC with at least two public subnets in different Availability Zones (AZs).
Knowledge of basic Linux commands and VPC networking.

Learning Objectives

Differentiate between Layer 4 (NLB) and Layer 7 (ALB) load balancing.
Configure a highly available Application Load Balancer across multiple AZs.
Implement a Target Group with customized health checks.
Deploy an Auto Scaling Group integrated with an ELB.
Secure the entry point using SSL/TLS termination and AWS WAF concepts.

Architecture Overview

Loading Diagram...

Visualizing the OSI Layers

Before we begin, remember how load balancing fits into the OSI model:

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Step-by-Step Instructions

Step 1: Create Security Groups

We need two security groups: one for the ALB (allowing port 80/443 from the internet) and one for the EC2 instances (allowing port 80 ONLY from the ALB).

bash

# Create ALB Security Group
aws ec2 create-security-group --group-name alb-sg --description "ALB Public Access" --vpc-id <YOUR_VPC_ID>

# Allow HTTP ingress to ALB
aws ec2 authorize-security-group-ingress --group-name alb-sg --protocol tcp --port 80 --cidr 0.0.0.0/0

▶Console alternative

Navigate to EC2 > Security Groups > Create security group. Name it 'alb-sg', add an Inbound rule for HTTP (80) from 0.0.0.0/0.

Step 2: Create a Target Group

The target group defines where the load balancer sends traffic and how it checks for instance health.

bash

aws elbv2 create-target-group \
    --name brainybee-tg \
    --protocol HTTP \
    --port 80 \
    --vpc-id <YOUR_VPC_ID> \
    --health-check-path / \
    --target-type instance

[!TIP] In production, use ip target type for ECS or Lambda targets, and instance for standard EC2 deployments.

Step 3: Create the Application Load Balancer

Deploy the ALB across at least two public subnets for High Availability.

bash

aws elbv2 create-load-balancer \
    --name brainybee-alb \
    --subnets <SUBNET_ID_1> <SUBNET_ID_2> \
    --security-groups <ALB_SG_ID>

Step 4: Create a Listener

A listener checks for connection requests and forwards them to the target group.

bash

aws elbv2 create-listener \
    --load-balancer-arn <ALB_ARN> \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=<TG_ARN>

Step 5: Setup Auto Scaling Group (ASG)

We will use a Launch Template to define the instances. The ASG will ensure that if an instance fails a health check, it is replaced.

bash

# Create Launch Template (Assume UserData script installs Apache)
aws ec2 create-launch-template \
    --launch-template-name brainybee-template \
    --launch-template-data '{"ImageId":"ami-xxxx","InstanceType":"t3.micro","SecurityGroupIds":["<INSTANCE_SG_ID>"]}'

# Create ASG
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name brainybee-asg \
    --launch-template LaunchTemplateName=brainybee-template \
    --min-size 2 --max-size 4 --desired-capacity 2 \
    --target-group-arns <TG_ARN> \
    --vpc-zone-identifier "<SUBNET_ID_1>,<SUBNET_ID_2>"

Checkpoints

Verification 1: Run aws elbv2 describe-load-balancers --names brainybee-alb and ensure State is active.
Verification 2: Navigate to the ALB DNS name in your browser. You should see the default Apache page or your custom HTML.
Verification 3: Terminate one EC2 instance manually. The ASG should automatically provision a new one, and the ALB should stop sending traffic to the terminated instance once health checks fail.

Troubleshooting

Problem	Potential Cause	Fix
Health Check Failed	Security Group blocks ALB traffic	Ensure Instance SG allows port 80 from the ALB SG ID.
503 Service Unavailable	No healthy targets in TG	Check if instances are running and the health check path (e.g., `/index.html`) exists.
403 Forbidden	WAF Rule blocking traffic	Check WAF ACL logs for blocked IP addresses or headers.

Concept Review

Feature	Application Load Balancer (ALB)	Network Load Balancer (NLB)
Layer	Layer 7 (Application)	Layer 4 (Transport)
Best For	HTTP/HTTPS, Microservices	TCP/UDP, Ultra-low latency
Static IP	No (uses DNS name)	Yes (Elastic IP per AZ)
Termination	SSL/TLS Termination supported	SSL/TLS Passthrough or Termination

Stretch Challenge

Implement HTTPS: Use AWS Certificate Manager (ACM) to request a public certificate and add an HTTPS listener to the ALB on port 443.
Path-Based Routing: Create a second Target Group and configure a Listener Rule to route traffic to /api/* to the new group.

Cost Estimate

ALB: ~$0.0225 per ALB-hour + ~$0.008 per LCU-hour. (Approx. $18/month for 24/7 run).
EC2 (t3.micro): Free tier eligible (or ~$0.0104 per hour).
WAF: $5.00 per web ACL per month + $1.00 per rule (Pro-rated for this lab).

Clean-Up / Teardown

To avoid ongoing charges, delete the resources in this exact order:

bash

# 1. Delete Auto Scaling Group
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name brainybee-asg --force-delete

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

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

# 4. Delete Launch Template
aws ec2 delete-launch-template --launch-template-name brainybee-template

# 5. Delete Security Groups
aws ec2 delete-security-group --group-id <ALB_SG_ID>
aws ec2 delete-security-group --group-id <INSTANCE_SG_ID>