Lab: Building a High-Availability 3-Tier Web Stack on AWS

In this lab, you will architect a resilient infrastructure that eliminates single points of failure by leveraging Multi-AZ deployments for compute and data layers. This aligns with the AWS Certified DevOps Engineer - Professional (DOP-C02) domain of Resilient Cloud Solutions.

Prerequisites

AWS Account: Admin-level access to an AWS Account.
CLI Tools: AWS CLI installed and configured with aws configure.
IAM Permissions: Permissions to manage EC2, RDS, VPC, and Auto Scaling.
Knowledge: Basic understanding of VPC networking, Security Groups, and Linux shell.

[!WARNING] Remember to run the teardown commands at the end of this lab to avoid ongoing charges for RDS and ELB resources.

Learning Objectives

Provision a Multi-AZ Amazon RDS instance for synchronous data replication.
Configure an Application Load Balancer (ALB) to distribute traffic across Availability Zones.
Deploy an Auto Scaling Group (ASG) to maintain instance availability.
Simulate a failure and observe the self-healing nature of the architecture.

Architecture Overview

This architecture ensures that even if an entire AWS Availability Zone (AZ) goes offline, the application remains reachable and the database fails over automatically.

Loading Diagram...

Figure 1 — Mermaid diagram

Step-by-Step Instructions

Step 1: Create Security Groups for Tiers

We need two security groups: one for the ALB (allowing public access) and one for the EC2 instances (allowing access ONLY from the ALB).

bash

# 1. Create Web-DMZ Security Group (for ALB)
aws ec2 create-security-group --group-name web-dmz-sg --description "ALB Security Group"

# 2. Authorize Port 80 for public traffic
aws ec2 authorize-security-group-ingress --group-name web-dmz-sg --protocol tcp --port 80 --cidr 0.0.0.0/0

# 3. Create App-Tier Security Group (for EC2)
aws ec2 create-security-group --group-name app-tier-sg --description "App Instance Security Group"

▶Console alternative

Navigate to

EC2 > Security Groups > Create security group

. Name it

web-dmz-sg

and add an inbound rule for HTTP (80) from

0.0.0.0/0

Step 2: Provision a Multi-AZ RDS Instance

This creates a primary database in one AZ and a synchronous standby in another.

bash

aws rds create-db-instance \
    --db-instance-identifier brainybee-db \
    --db-instance-class db.t3.micro \
    --engine mysql \
    --allocated-storage 20 \
    --master-username admin \
    --master-user-password Password123! \
    --multi-az \
    --backup-retention-period 7

[!IMPORTANT] The --multi-az flag is critical here. It enables the secondary instance in a different AZ automatically.

Step 3: Create Application Load Balancer

We will target at least two subnets (AZs) to ensure the load balancer itself is highly available.

bash

# Replace <SUBNET_ID_1> and <SUBNET_ID_2> with your default VPC subnets
aws elbv2 create-load-balancer \
    --name app-ha-alb \
    --subnets <SUBNET_ID_1> <SUBNET_ID_2> \
    --security-groups <SG_ID_OF_DMZ>

Step 4: Configure Auto Scaling Group (ASG)

Create a Launch Template first, then the ASG. The ASG will use the ALB health checks to determine if an instance is healthy.

bash

# Create Launch Template
aws ec2 create-launch-template \
    --launch-template-name web-stack-template \
    --launch-template-data '{"ImageId":"ami-0c55b159cbfafe1f0", "InstanceType":"t2.micro", "SecurityGroupIds":["<APP_SG_ID>"]}'

# Create Auto Scaling Group
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name web-ha-asg \
    --launch-template LaunchTemplateName=web-stack-template \
    --min-size 2 --max-size 4 --desired-capacity 2 \
    --vpc-zone-identifier "<SUBNET_ID_1>,<SUBNET_ID_2>"

Checkpoints

RDS Status: Run aws rds describe-db-instances --db-instance-identifier brainybee-db --query 'DBInstances[*].MultiAZ'. It should return true.
ALB Health: Navigate to the EC2 Console > Target Groups. Ensure that the 2 instances in the ASG are listed as healthy.
Connectivity: Copy the DNS Name of your ALB and paste it into a browser. You should see the default web page (provided your AMI has a web server configured).

Teardown

To prevent unwanted costs, execute these commands in order:

bash

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

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

# 3. Delete RDS Instance (Skip snapshot for lab speed)
aws rds delete-db-instance --db-instance-identifier brainybee-db --skip-final-snapshot

Troubleshooting

Problem	Likely Cause	Fix
ALB Health Check Failing	SG Rules	Ensure `app-tier-sg` allows Port 80 from `web-dmz-sg` (Security Group Referencing).
RDS Multi-AZ slow to provision	Provisioning lag	Multi-AZ involves creating a snapshot and restoring it to a new AZ. This can take 5-10 minutes.
ASG not launching instances	Subnet mismatch	Ensure the subnets provided to the ASG match the AZs available to the Launch Template.

Stretch Challenge

Cross-Region Resilience: Currently, our app is Multi-AZ. How would you handle an entire AWS Region outage?

Goal:

Research RDS Read Replicas (Cross-Region).
Use Amazon Route 53 Health Checks and Failover routing policies to redirect traffic to a secondary region (e.g., us-east-1 to us-west-2).

Cost Estimate

RDS db.t3.micro (Multi-AZ): ~$0.036 per hour (roughly double the Single-AZ price).
ALB: ~$0.0225 per hour + LCU charges.
EC2 t2.micro: Free Tier eligible (if within limits).
Estimated Total: < $0.10 for the duration of this 30-minute lab.

Concept Review

Understanding the trade-offs between High Availability (HA) and Disaster Recovery (DR) is vital for the DevOps Professional exam.

The Resilience Continuum

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Figure 2 — TikZ diagram

RTO vs. RPO

RTO (Recovery Time Objective): The maximum acceptable delay between the interruption of service and restoration. Multi-AZ targets a very low RTO (seconds to minutes).
RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time. Multi-AZ RDS has an RPO of zero because replication is synchronous.

Feature	Multi-AZ	Multi-Region
Primary Goal	High Availability	Disaster Recovery / Latency
Replication	Synchronous	Asynchronous
Automatic Failover	Yes (DNS update)	Manual or Route 53 DNS Failover
Distance	Miles (Latency < 2ms)	Hundreds/Thousands of Miles

Lab: Building a High-Availability 3-Tier Web Stack on AWS

Prerequisites

AWS Account: Admin-level access to an AWS Account.
CLI Tools: AWS CLI installed and configured with aws configure.
IAM Permissions: Permissions to manage EC2, RDS, VPC, and Auto Scaling.
Knowledge: Basic understanding of VPC networking, Security Groups, and Linux shell.

[!WARNING] Remember to run the teardown commands at the end of this lab to avoid ongoing charges for RDS and ELB resources.

Learning Objectives

Provision a Multi-AZ Amazon RDS instance for synchronous data replication.
Configure an Application Load Balancer (ALB) to distribute traffic across Availability Zones.
Deploy an Auto Scaling Group (ASG) to maintain instance availability.
Simulate a failure and observe the self-healing nature of the architecture.

Architecture Overview

This architecture ensures that even if an entire AWS Availability Zone (AZ) goes offline, the application remains reachable and the database fails over automatically.

Loading Diagram...

Figure 1 — Mermaid diagram

Step-by-Step Instructions

Step 1: Create Security Groups for Tiers

We need two security groups: one for the ALB (allowing public access) and one for the EC2 instances (allowing access ONLY from the ALB).

bash

# 1. Create Web-DMZ Security Group (for ALB)
aws ec2 create-security-group --group-name web-dmz-sg --description "ALB Security Group"

# 2. Authorize Port 80 for public traffic
aws ec2 authorize-security-group-ingress --group-name web-dmz-sg --protocol tcp --port 80 --cidr 0.0.0.0/0

# 3. Create App-Tier Security Group (for EC2)
aws ec2 create-security-group --group-name app-tier-sg --description "App Instance Security Group"

▶Console alternative

Navigate to

EC2 > Security Groups > Create security group

. Name it

web-dmz-sg

and add an inbound rule for HTTP (80) from

0.0.0.0/0

Step 2: Provision a Multi-AZ RDS Instance

This creates a primary database in one AZ and a synchronous standby in another.

bash

aws rds create-db-instance \
    --db-instance-identifier brainybee-db \
    --db-instance-class db.t3.micro \
    --engine mysql \
    --allocated-storage 20 \
    --master-username admin \
    --master-user-password Password123! \
    --multi-az \
    --backup-retention-period 7

[!IMPORTANT] The --multi-az flag is critical here. It enables the secondary instance in a different AZ automatically.

Step 3: Create Application Load Balancer

We will target at least two subnets (AZs) to ensure the load balancer itself is highly available.

bash

# Replace <SUBNET_ID_1> and <SUBNET_ID_2> with your default VPC subnets
aws elbv2 create-load-balancer \
    --name app-ha-alb \
    --subnets <SUBNET_ID_1> <SUBNET_ID_2> \
    --security-groups <SG_ID_OF_DMZ>

Step 4: Configure Auto Scaling Group (ASG)

Create a Launch Template first, then the ASG. The ASG will use the ALB health checks to determine if an instance is healthy.

bash

# Create Launch Template
aws ec2 create-launch-template \
    --launch-template-name web-stack-template \
    --launch-template-data '{"ImageId":"ami-0c55b159cbfafe1f0", "InstanceType":"t2.micro", "SecurityGroupIds":["<APP_SG_ID>"]}'

# Create Auto Scaling Group
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name web-ha-asg \
    --launch-template LaunchTemplateName=web-stack-template \
    --min-size 2 --max-size 4 --desired-capacity 2 \
    --vpc-zone-identifier "<SUBNET_ID_1>,<SUBNET_ID_2>"

Checkpoints

RDS Status: Run aws rds describe-db-instances --db-instance-identifier brainybee-db --query 'DBInstances[*].MultiAZ'. It should return true.
ALB Health: Navigate to the EC2 Console > Target Groups. Ensure that the 2 instances in the ASG are listed as healthy.
Connectivity: Copy the DNS Name of your ALB and paste it into a browser. You should see the default web page (provided your AMI has a web server configured).

Teardown

To prevent unwanted costs, execute these commands in order:

bash

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

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

# 3. Delete RDS Instance (Skip snapshot for lab speed)
aws rds delete-db-instance --db-instance-identifier brainybee-db --skip-final-snapshot

Troubleshooting

Problem	Likely Cause	Fix
ALB Health Check Failing	SG Rules	Ensure `app-tier-sg` allows Port 80 from `web-dmz-sg` (Security Group Referencing).
RDS Multi-AZ slow to provision	Provisioning lag	Multi-AZ involves creating a snapshot and restoring it to a new AZ. This can take 5-10 minutes.
ASG not launching instances	Subnet mismatch	Ensure the subnets provided to the ASG match the AZs available to the Launch Template.

Stretch Challenge

Cross-Region Resilience: Currently, our app is Multi-AZ. How would you handle an entire AWS Region outage?

Goal:

Research RDS Read Replicas (Cross-Region).
Use Amazon Route 53 Health Checks and Failover routing policies to redirect traffic to a secondary region (e.g., us-east-1 to us-west-2).

Cost Estimate

RDS db.t3.micro (Multi-AZ): ~$0.036 per hour (roughly double the Single-AZ price).
ALB: ~$0.0225 per hour + LCU charges.
EC2 t2.micro: Free Tier eligible (if within limits).
Estimated Total: < $0.10 for the duration of this 30-minute lab.

Concept Review

Understanding the trade-offs between High Availability (HA) and Disaster Recovery (DR) is vital for the DevOps Professional exam.

The Resilience Continuum

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Figure 2 — TikZ diagram

RTO vs. RPO

RTO (Recovery Time Objective): The maximum acceptable delay between the interruption of service and restoration. Multi-AZ targets a very low RTO (seconds to minutes).
RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time. Multi-AZ RDS has an RPO of zero because replication is synchronous.

Feature	Multi-AZ	Multi-Region
Primary Goal	High Availability	Disaster Recovery / Latency
Replication	Synchronous	Asynchronous
Automatic Failover	Yes (DNS update)	Manual or Route 53 DNS Failover
Distance	Miles (Latency < 2ms)	Hundreds/Thousands of Miles