Resilient Web Architecture
AWS · High availability · Active-passive

Stay online when regions go offline.

A two-layer failover design for a resilient web app. CloudFront handles application errors at the edge; Route 53 redirects around a regional outage to a static S3 maintenance site.

2 layersIndependent failover paths
2 regionsPrimary + standby
2–6Primary EC2 instances
~90 secDocumented DNS recovery test
System overview

One app. Two ways to recover.

Choose a scenario to trace traffic through the system. This is an illustrative architecture walkthrough, not a live connection to AWS.

Active-passive traffic flow Primary: eu-central-1 · Standby: us-east-1
Primary regionACTIVE
VisitorsHTTPS requests
CloudFrontEdge cache + origin group
Application Load BalancerHTTP target health checks
Auto Scaling Group2–6 instances · two AZs
Standby regionPASSIVE
Route 53Health check · failover record
S3 static siteMaintenance page · us-east-1
CloudWatch + SNSAlarm and email notification
CloudWatchRoute 53 health status alarm
Amazon SNSEmail alert subscription
Normal traffic CloudFront origin failover Route 53 regional failover
Walk through a scenario

Visitors reach the primary app through CloudFront and the load balancer.

Resilience strategy

Two layers, different failure modes.

Fast application-level recovery comes first. DNS failover provides a separate route when the primary region itself is unavailable.

01

Edge origin failover

CloudFront monitors the primary ALB origin. On configured origin failures, its origin group serves the S3 maintenance page without waiting for DNS propagation.

  • Handles primary origin errors
  • Routes at the CloudFront edge
  • Requires a configured secondary origin
02

Regional DNS failover

Route 53 health-checks the public endpoint and switches the failover record to the standby S3 website endpoint if the primary is unhealthy.

  • Provides a path around regional failure
  • Example: 10-second checks, 3 failed checks
  • Recovery depends on health checks and DNS caching
Infrastructure building blocks

A small, reproducible stack.

The reference implementation uses Terraform to provision primary-region compute and networking alongside a low-cost static standby.

Edge

Amazon CloudFront

Distribution, ALB origin, and an S3 origin group.

Networking

VPC + Application Load Balancer

Two public subnets across availability zones, with an ALB target group.

Compute

EC2 Auto Scaling

Amazon Linux launch template; scales from two to six instances.

Disaster recovery

Amazon S3 static website

Maintenance page hosted in the secondary region.

DNS

Amazon Route 53

Health check and primary/secondary failover records.

Operations

CloudWatch + SNS

Health-status alarm with an email notification subscription.

Project notes

Validation checklist.

The source material reports these as completed tests for its reference deployment. Results are documented here, not verified against a live AWS account.

TestReported result
Terraform validation and plan✓ Passed · Plan showed 38 resources
CloudFront endpoint and Route 53 health check✓ Passed · Website reachable; health check healthy
Layer 1 · forced ALB 5xx responses✓ Passed · CloudFront served the S3 page
Layer 2 · primary instances terminated✓ Passed · DNS switched to S3 in about 90 seconds
Failback and Auto Scaling✓ Passed · Primary recovered; capacity scaled 2 → 4 → 2

DNS detection and failover time vary with health-check settings, DNS TTL, and resolver caching.

Design notes

Keeping the standby page static avoids running a second application fleet. The two failover layers are independently useful and should be exercised separately during testing.

Operational considerations

CloudFront distribution changes can take time to deploy. Keep health checks public and verify the S3 website access policy and failover behavior for your own security requirements.

Continue learning

AWS documentation.