0Pricing
AWS Solutions Architect · Lesson

Resilient and Highly Available Architecture Scenarios

Tackle multi-AZ database failover, auto scaling under burst traffic, and Route 53 health-check failover scenarios to solidify reliability concepts.

Resilient and Highly Available Architecture Scenarios is a free AWS Solutions Architect lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AWS Solutions Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Scenario 1: Multi-AZ Web Application

Scenario: A company runs a two-tier web application (ALB → EC2 → RDS) and wants to eliminate any single point of failure within the AWS Region. Solution: Deploy EC2 instances in an Auto Scaling Group spanning at least 2 Availability Zones behind an ALB (which is inherently multi-AZ). Enable RDS Multi-AZ for synchronous standby replication. Configure health checks on the ALB to automatically route away from unhealthy instances. With this architecture, the loss of any single AZ causes automatic failover at every tier.

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

Scenario 2: RDS Read Scaling Under Load

Scenario: An e-commerce application's RDS instance is hitting CPU limits during peak hours due to read-heavy analytics queries from the business intelligence team. Solution: Create RDS Read Replicas and point BI queries to the replica endpoint. Read Replicas use asynchronous replication — slight lag is acceptable for analytics. This offloads read traffic from the primary RDS instance, which is reserved for write operations and application reads. For extremely read-heavy workloads, add an ElastiCache layer in front of RDS for frequently accessed data.

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

Scenario 3: Auto Scaling on CPU Spike

Scenario: A stateless API runs on EC2 behind an ALB. CPU usage spikes to 90% during business hours and drops near zero at night. The company wants the fleet to scale automatically. Solution: Configure an Auto Scaling Group with a Target Tracking scaling policy targeting 60% average CPU utilisation. ASG will automatically add instances when CPU exceeds 60% and remove instances when it drops below the target. Add a scheduled scaling action to pre-warm minimum capacity before business hours start, preventing lag at the morning traffic burst.

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

Scenario 4: Route 53 Failover to DR Site

Scenario: A company runs a primary web application in us-east-1 and wants to fail over to a static S3-hosted maintenance page in us-west-2 if the primary becomes unhealthy. Solution: Create a Route 53 health check monitoring the primary ALB endpoint. Create two Route 53 records with failover routing policy: Primary record pointing to the ALB (associated with the health check), and Secondary record pointing to the S3 static site. If the health check fails, Route 53 automatically serves the secondary record DNS response.

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

Scenario 5: Decoupling with SQS for Resilience

Scenario: An order processing backend writes to a database, but the database sometimes becomes unavailable during maintenance windows, causing orders to be lost. Solution: Place an SQS queue between the front end (which accepts orders) and the backend (which processes them). Orders are put on the queue immediately, giving the customer instant acknowledgement. Background workers pull from the queue and process orders when the database is available. During maintenance, orders queue up rather than being dropped — providing resilience through asynchronous decoupling.

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

Scenario 6: Pilot Light DR

Scenario: A company needs a disaster recovery solution with an RPO of 1 hour and RTO of 4 hours for a moderate budget. Solution: Implement a Pilot Light DR strategy. Keep the core database replicated to the DR Region using RDS Cross-Region Read Replica. The application servers do not run in the DR Region during normal operation — only the minimum 'core' (the database) is kept warm. In a disaster, promote the Read Replica to standalone and launch application servers from pre-created AMIs using CloudFormation. RTO is hours rather than minutes because servers must be launched.

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

Scenario 7: SQS Dead-Letter Queue for Failed Messages

Scenario: Messages on an SQS queue fail processing repeatedly due to a bug in the consumer Lambda. The messages keep reappearing and blocking the queue. Solution: Configure a Dead-Letter Queue (DLQ) on the main queue. After a message fails processing a configurable number of times (maxReceiveCount), SQS automatically moves it to the DLQ rather than redelivering it forever. This unblocks the main queue for healthy messages. Set a CloudWatch alarm on the DLQ ApproximateNumberOfMessagesVisible metric to alert the engineering team when messages accumulate in the DLQ.

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

Scenario 8: Aurora Global Database

Scenario: A company operates in the US and Europe. Users in Europe experience high database read latency because RDS is in us-east-1. Solution: Use Amazon Aurora Global Database. The primary cluster is in us-east-1; a secondary read-only cluster is added in eu-west-1. Aurora replicates data to the secondary Region with typical latency under 1 second using storage-level replication. European users read from the eu-west-1 secondary cluster. In a regional disaster, the secondary can be promoted to primary in under 1 minute (the best RTO among any AWS multi-region DB option).

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

Scenario 9: ECS Service with ALB and Auto Scaling

Scenario: A containerised API service running on ECS Fargate needs to scale based on CPU utilisation and survive AZ failures. Solution: Register the ECS service with an Application Load Balancer target group so traffic is distributed across running tasks. Place tasks across multiple AZs by specifying multiple subnets in the service configuration. Configure ECS Service Auto Scaling with a target tracking policy on ECS service CPU utilisation to scale task count up and down automatically. If an AZ fails, ECS restarts failed tasks in healthy AZs.

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

Scenario 10: Health Check Failover with Route 53

Scenario: A company runs two EC2 instances in different AZs serving the same domain. They want Route 53 to automatically stop sending traffic to an unhealthy instance. Solution: Use Route 53 Weighted Routing with equal weights (50/50) and associate an endpoint health check with each record. When Route 53 detects an unhealthy endpoint, it removes that record from DNS responses and sends 100% of traffic to the healthy endpoint. When the instance recovers and health checks pass again, Route 53 automatically rebalances traffic — no manual DNS changes needed.

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

Scenario 11: DynamoDB Global Tables for Multi-Region HA

Scenario: A mobile gaming application needs its player data readable and writable with low latency from both us-east-1 and ap-southeast-1. A single-region DynamoDB table causes high latency for Asian users. Solution: Enable DynamoDB Global Tables. Global Tables automatically replicate data across specified Regions using multi-master replication — any Region can accept writes. Asian users write to and read from the ap-southeast-1 replica with local latency (~5ms). Global Tables handles conflict resolution using a 'last-writer-wins' strategy based on timestamps. RTO for a full regional failure is near zero — traffic simply routes to the surviving region.

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

Quick Check

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

Lesson Recap

In this lesson you worked through scenarios covering: Multi-AZ ASG and RDS for within-Region HA, Route 53 failover routing for cross-Region DR, SQS DLQ to isolate failed messages without blocking queues, and Aurora Global Database for cross-Region read scaling and sub-minute RTO failover. Next up we tackle high-performance and cost-optimised architecture scenarios.

Frequently asked questions

Is the “Resilient and Highly Available Architecture Scenarios” lesson free?

Yes — the full text of “Resilient and Highly Available Architecture Scenarios” is free to read here on the web, and the AWS Solutions Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AWS Solutions Architect course, upgrade to CoddyKit PRO.

What will I learn in “Resilient and Highly Available Architecture Scenarios”?

Tackle multi-AZ database failover, auto scaling under burst traffic, and Route 53 health-check failover scenarios to solidify reliability concepts. You practise AWS Solutions Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start AWS Solutions Architect?

No prior experience is required. AWS Solutions Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Resilient and Highly Available Architecture Scenarios” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this AWS Solutions Architect lesson?

Yes. Every AWS Solutions Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Secure Architecture Scenarios
  2. Resilient and Highly Available Architecture Scenarios
  3. High-Performance and Cost-Optimised Scenarios
  4. Mixed Domain Full-Length Mini Exam
← Back to AWS Solutions Architect