DEV Community

Cover image for Designing a Production-Grade Multi-AZ Web Architecture on AWS Using ALB, EC2, and Auto Scaling
Ntseze-Nelvis
Ntseze-Nelvis

Posted on

Designing a Production-Grade Multi-AZ Web Architecture on AWS Using ALB, EC2, and Auto Scaling

#aws #devops #tutorial #architecture

Executive Summary

In this project, we design and deploy a highly available, fault-tolerant, and scalable web application architecture on AWS using an Application Load Balancer integrated with an existing Auto Scaling Group across multiple Availability Zones.

This architecture reflects real production systems used by:

  • Banking platforms
  • E-commerce websites
  • SaaS products
  • Enterprise web backends

If you’re preparing for AWS certifications, DevOps interviews, or real production work, this project checks all the boxes.

LOAD BALANCER DIAGRAM

Project Objective (Interview-Ready Framing)

Design and deploy a production-grade web architecture that automatically handles:

  • Traffic spikes
  • Instance failures
  • Availability Zone outages

— without downtime.

We achieve this by:

  • Distributing traffic using an Application Load Balancer
  • Running EC2 instances across multiple AZs
  • Integrating an existing Auto Scaling Group
  • Enforcing security best practices
  • Validating real-world failure scenarios

Prerequisites

Networking

  • VPC with:
    • At least 2 public subnets in different AZs
    • Internet Gateway
    • Route table: 0.0.0.0/0 → IGW

Compute & Access

  • Existing Auto Scaling Group: hsbc-asg
  • EC2 Key Pair (for SSH)
  • IAM permissions for:
    • EC2
    • Load Balancers
    • Target Groups
    • Auto Scaling
    • Security Groups

Section 1 — Security Groups (Foundation of Security)

1.1 EC2 Security Group — sg_web-servers

Purpose: Control backend server access.

Inbound Rules

EC2 Security Group

Security Groups

Type Port Source
HTTP 80 0.0.0.0/0 (temporary)
SSH 22 My IP

Intentional design: Public HTTP is allowed initially for validation, then hardened later — a classic interview scenario.

Imagtre

1.2 Load Balancer Security Group — sg_alb

Purpose: Allow public web traffic to ALB only.

Type Port Source
HTTP 80 0.0.0.0/0

sg-alb

Sections 2 & 3 — Launch EC2 Web Servers (Multi-AZ)

To demonstrate high availability and fault tolerance, deploy two EC2 instances in different Availability Zones (AZs).

The steps below show how to launch one instance.

Repeat the same steps for the second instance, selecting a different AZ and user data script.

Launch EC2 Instance (Repeat for Second AZ)

Launch a New EC2 Instance

  1. Navigate to AWS Console → EC2 → Instances
  2. Click Launch Instance

Imageec2

Configure Instance Basics

  • Name: hsbc-server1
  • AMI: Amazon Linux 2
  • Instance Type: t2.micro
  • Key Pair: Select an existing key pair

Imafrjr

Network Configuration (Critical)

  • VPC: Select your existing VPC
  • Subnet: Public subnet in AZ-A
  • Auto-assign Public IP: Enabled
  • Security Group: sg_web-servers

Imagfgsw

Imauytg

For the second instance, choose a public subnet in a different AZ (AZ-B).

Configure Storage

  • Leave default settings (8 GB gp3)

Advanced Settings — User Data

Paste the following User Data script:

#!/bin/bash
yum update -y
yum install httpd git -y
git clone https://github.com/Ntseze-Nelvis/CloudReality-ecommerce-web-app.git
cp -r CloudReality-ecommerce-web-app/server1/* /var/www/html/
systemctl start httpd
systemctl enable httpd
Enter fullscreen mode Exit fullscreen mode

Imadfgh

Instance B — hsbc-server2 (AZ-B) 

#!/bin/bash
set -e
yum update -y
yum install -y httpd git
cd /home/ec2-user
git clone https://github.com/Ntseze-Nelvis/CloudReality-ecommerce-web-app.git
if [ ! -d "CloudReality-ecommerce-web-app/server2" ]; then
  echo "ERROR: server2 directory not found"
  exit 1
fi
rm -rf /var/www/html/*
cp -r CloudReality-ecommerce-web-app/server2/* /var/www/html/

chown -R apache:apache /var/www/html

systemctl enable --now httpd
Enter fullscreen mode Exit fullscreen mode

Section 4 — Backend Validation (Before ALB)

Why this matters

Always validate components before adding complexity.

Steps

  • Access each EC2 via public IP (http://)

Imon

  • Confirm content loads correctly

Imageon

  • Ensure HTTP service is running

✔ Isolates issues early

✔ Follows production troubleshooting best practices

Section 5 — Target Group (ALB → EC2 / ASG)

Target Group Configuration

  • Name: tg-hsbc-web
  • Protocol: HTTP
  • Port: 80
  • Health check path: /

Imageiption

Register targets

  • hsbc-server1
  • hsbc-server2

Imagscription

Wait until both show Healthy.

Imcription

Section 6 — Application Load Balancer

create alb

ALB Configuration

  • Name: hsbc-alb-web
  • Scheme: Internet-facing
  • Subnets: 2 public AZs
  • Security Group: sg-alb
  • Listener: HTTP :80
  • Action: Forward to tg-hsbc-web

Imagption

Section 7 — Load Balancing Test

Visit the ALB DNS name:

http://hsbc-alb-web-xxxx.elb.amazonaws.com
Enter fullscreen mode Exit fullscreen mode

Imagscription

Load Balancing Validation

Refresh the ALB endpoint multiple times:

✔ Confirms round-robin traffic distribution

✔ Confirms ALB health checks are functioning correctly

Section 8 — Attach Existing Auto Scaling Group

Attach hsbc-asg to the Application Load Balancer:

Steps

  • Navigate to Auto Scaling Group → Load Balancing
  • Attach to an existing target group
  • Select tg-hsbc-web

Imagcription

✔ New instances automatically register with the ALB

✔ Zero manual intervention required

Section 9 — Real-World Failure Scenarios (Interview Ready)

Test 1 — Instance Failure

  • Manually terminate an EC2 instance
  • Auto Scaling Group launches a replacement
  • ALB reroutes traffic automatically

Test 2 — Load Spike 

sudo stress --cpu 4 --timeout 120
Enter fullscreen mode Exit fullscreen mode

✔ ASG scales out automatically

✔ ALB distributes increased traffic

Test 3 — Application Failure

Stop the web service on an instance:

sudo systemctl stop httpd
Enter fullscreen mode Exit fullscreen mode

✔ ALB marks the instance as unhealthy

✔ ASG replaces the instance automatically (if configured)

Section 10 — Security Hardening (Production Must)

Before (Insecure)

  • EC2 instances allowed HTTP access from 0.0.0.0/0

After (Correct)

  • Remove public HTTP rule from the EC2 Security Group
  • Allow HTTP only from sg-alb

✔ EC2 instances are now private

✔ ALB is the single entry point

✔ Highly tested AWS exam & interview concept

Section 11 — Cleanup (Cost Control)

  • Delete the Application Load Balancer
  • Delete the Target Group
  • Restore ASG desired capacity
  • Terminate test EC2 instances
  • Remove unused Security Groups and volumes

Certification & Interview Mapping

AWS Exam Topics Covered

  • High Availability
  • Elastic Load Balancing
  • Auto Scaling
  • Health Checks
  • Security Groups
  • Fault Tolerance

Why This Architecture Matters (Interview Gold)

Common Production Problems

Problem Impact
Single EC2 failure Application downtime
Traffic spikes Performance degradation
Manual scaling Slow & error-prone
Public EC2 exposure Security risks

Solution Implemented

  • Multi-AZ EC2 deployment
  • Application Load Balancer
  • Auto Scaling Group integration
  • Health checks & self-healing
  • ALB → EC2 security isolation

This is the default architecture AWS expects in real environments.

Final Architecture Overview

✔ Highly available

✔ Horizontally scalable

✔ Secure by design

✔ Production-ready

Interview Questions This Project Answers

Q: Why use an ALB instead of exposing EC2 directly?

A: Security, scalability, health checks, and zero-downtime deployments

Q: How does an Auto Scaling Group integrate with an ALB?

A: Through target groups with dynamic instance registration

Q: What happens if an Availability Zone goes down?

A: The ALB routes traffic to healthy AZs automatically

Problem → Solution Summary

Problem Solution
EC2 failure Auto Scaling replacement
Traffic spikes Horizontal scaling
Single-AZ risk Multi-AZ deployment
Public EC2 exposure ALB-only access
Manual recovery Automated health checks

Top comments (0)