AWS Resiliency: Multi-AZ and Multi-Region Architectures

This guide covers the architectural patterns and implementation strategies for high availability (HA) and disaster recovery (DR) on AWS, focusing on the compute and data layers as required for the DOP-C02 exam.

Learning Objectives

By the end of this guide, you should be able to:

• Differentiate between Multi-AZ for high availability and Multi-Region for disaster recovery.
• Configure compute layers (EC2, ECS, Lambda) for cross-AZ resilience.
• Implement data layer replication strategies for RDS, Aurora, and DynamoDB.
• Translate business requirements (SLAs, RTO, RPO) into technical architectures.
• Identify and remediate single points of failure (SPOF) in existing workloads.

Key Terms & Glossary

• Availability Zone (AZ): One or more discrete data centers with redundant power, networking, and connectivity in an AWS Region.
• Region: A physical location around the world where AWS clusters data centers.
• RTO (Recovery Time Objective): The maximum acceptable delay between the interruption of service and restoration of service.
• RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time.
• Synchronous Replication: Data is written to the primary and secondary locations simultaneously before the write is acknowledged.
• Asynchronous Replication: Data is written to the primary location first, then copied to the secondary; there is a slight lag.

The "Big Idea"

Resiliency is not a binary state but a spectrum. High Availability (Multi-AZ) focuses on automatic failover within a single geographic area to maintain service during localized failures. Disaster Recovery (Multi-Region) focuses on business continuity against catastrophic events or for providing low-latency access to a global user base. The DevOps Engineer's role is to balance the cost of these architectures against the business's risk tolerance.

Formula / Concept Box

Hierarchical Outline

1. Compute Layer Resiliency
   • Auto Scaling Groups (ASG): Spanning multiple AZs to ensure instance replacement.
   • Elastic Load Balancing (ELB): Cross-zone load balancing to distribute traffic evenly.
   • Serverless (Lambda/Fargate): Inherently Multi-AZ by design; requires VPC subnet configuration for private resources.
2. Data Layer Resiliency
   • Amazon RDS: Multi-AZ (synchronous) for HA vs. Read Replicas (asynchronous) for scaling and DR.
   • Amazon Aurora: Six-way replication across three AZs by default; Global Databases for cross-region.
   • DynamoDB: Global Tables for multi-active, multi-region synchronization.
   • Amazon S3: Cross-Region Replication (CRR) for data durability across continents.
3. Network & Traffic Management
   • Route 53: Health checks and failover routing (Active-Active or Active-Passive).
   • CloudFront: Global edge distribution to reduce latency and provide static failover (S3 Origin Groups).

Visual Anchors

Multi-AZ High Availability Flow

RTO vs. RPO Timeline

Definition-Example Pairs

• Pilot Light (DR Strategy): Keeping a minimal version of the environment (like the database) always running, while other parts (like compute) are only provisioned during a disaster.
  • Example: An RDS Read Replica stays active in Region B, but the EC2 Auto Scaling Group has a DesiredCapacity of 0 until a failover is triggered.
• Warm Standby (DR Strategy): A scaled-down but fully functional version of the environment is always running in a second region.
  • Example: A small t3.micro instance fleet is running behind an ALB in the secondary region, ready to scale up instantly if the primary region fails.
• Cross-Region Read Replica: An asynchronous copy of a database in a different geographic region.
  • Example: Using an RDS MySQL Read Replica in eu-central-1 to serve local European users and provide a DR target for the primary us-east-1 DB.

Worked Examples

Scenario: Remediating a Single Point of Failure

Current State: A PHP application runs on a single EC2 instance with a local MySQL database. The user reports that whenever the instance is patched, the site goes down.

Step 1: Decouple the Data Layer Move the local MySQL database to Amazon RDS Multi-AZ.

• Result: This provides synchronous replication to a standby in a different AZ. If AZ-A fails, RDS automatically updates DNS to point to the standby in AZ-B.

Step 2: Implement Compute Scalability Place the EC2 instance into an Auto Scaling Group (ASG) across at least two AZs and put an Application Load Balancer (ALB) in front.

• Result: If one instance or AZ fails, the ALB stops sending traffic to the unhealthy node, and the ASG launches a replacement.

Step 3: Enable Global Resilience Create an RDS Read Replica in a secondary region. Use Route 53 Failover Routing to point to a static S3 maintenance page or a Pilot Light environment in the second region.

Comparison Tables

Checkpoint Questions

1. Which replication type is used by RDS Multi-AZ to ensure no data loss during a failover?
2. You need to provide a global application with an RTO of near-zero and an RPO of near-zero. Which DynamoDB feature should you use?
3. True or False: An ALB can load balance traffic to targets in different AWS Regions.
4. What is the main difference between Pilot Light and Warm Standby DR strategies?

▶Click to see Answers

1. Synchronous Replication.
2. DynamoDB Global Tables (Multi-active).
3. False (ALBs are regional; use Route 53 or Global Accelerator for cross-region).
4. Pilot Light only keeps data/core services running; Warm Standby keeps a scaled-down version of the entire functional stack running.

Muddy Points & Cross-Refs

• Aurora vs. RDS Replication: Students often confuse standard RDS Multi-AZ (1 standby) with Aurora (6 copies). Remember: Aurora storage is shared across AZs, making failover much faster (often <30 seconds).
• S3 Consistency: While S3 is regional, its replication (CRR) is asynchronous. This means your RPO for S3 data in a disaster is the replication lag (usually seconds).
• Further Study: Review the AWS Well-Architected Framework: Reliability Pillar and the Route 53 Routing Policies documentation for more complex traffic patterns.