High Availability and Fault Tolerance: Multi-AZ and Multi-Region Strategies

This study guide focuses on the architectural patterns and AWS services used to ensure applications remain available and resilient in the face of infrastructure failures, ranging from a single server to an entire AWS Region.

Learning Objectives

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

• Translate business requirements (SLAs) into technical resiliency needs (RTO/RPO).
• Identify and remediate Single Points of Failure (SPOFs) in existing architectures.
• Configure Multi-AZ deployments for compute and data layers to achieve high availability.
• Design multi-Region solutions for disaster recovery and global scalability using services like DynamoDB and Route 53.
• Test failover mechanisms for stateful services to ensure minimal downtime during outages.

Key Terms & Glossary

• Availability Zone (AZ): One or more discrete data centers with redundant power, networking, and connectivity in an AWS Region.
• High Availability (HA): A system design protocol that ensures a certain level of operational performance, usually uptime, for a higher than normal period.
• RTO (Recovery Time Objective): The maximum acceptable amount of time since a service interruption until the service is restored.
• RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time (e.g., "we can lose 5 minutes of data").
• SLA (Service Level Agreement): A commitment between a service provider and a client regarding service availability (e.g., 99.99%).

The "Big Idea"

Resiliency in the cloud is not an accidental outcome; it is a deliberate design choice. High Availability (HA) focuses on surviving local failures (like a disk or a data center) within a single Region using Multi-AZ patterns. Disaster Recovery (DR) focuses on surviving catastrophic failures (like an entire Region becoming unavailable) using Multi-Region patterns. The trade-off is always between Cost, Complexity, and the Uptime required by the business.

Formula / Concept Box

Hierarchical Outline

1. High Availability (Multi-AZ)
   • Compute Layer: Use Auto Scaling Groups (ASG) spanning multiple AZs behind an Application Load Balancer (ALB).
   • Data Layer: RDS Multi-AZ (Synchronous replication to a standby) vs. Aurora (6 copies of data across 3 AZs).
2. Disaster Recovery (Multi-Region)
   • Strategies: Pilot Light (minimal core), Warm Standby (scaled-down version), Multi-Site (Active-Active).
   • Data Replication: DynamoDB Global Tables (Last-writer-wins) and RDS Read Replicas (Asynchronous).
3. Global Traffic Management
   • Route 53: Health checks and failover routing policies.
   • CloudFront: Edge caching and Origin Failover to provide high availability for static and dynamic content.

Visual Anchors

Multi-AZ Failover Flow

Global Multi-Region Architecture

Definition-Example Pairs

• Synchronous Replication: Data is written to the primary and standby simultaneously before a "success" is returned.
  • Example: RDS Multi-AZ deployment ensures that if the primary AZ fails, no data is lost because the standby was already up-to-date.
• Asynchronous Replication: Data is written to the primary first, then copied to the replica with a slight delay.
  • Example: RDS Cross-Region Read Replicas provide lower latency for local users in a second region but may have a non-zero RPO during failover.
• Loose Coupling: Designing components so they have little or no knowledge of the internal workings of other components.
  • Example: Using Amazon SQS between a web tier and a processing tier so that if the processor fails, messages stay in the queue until the service recovers.

Worked Examples

Problem: Converting a Single-AZ Application to Multi-AZ

Scenario: A company has a legacy app on a single EC2 instance with an RDS database in us-east-1a. They need to reach 99.95% availability.

Step 1: Compute Layer

• Create an AMI of the existing EC2 instance.
• Configure an Auto Scaling Group (ASG) with a desired capacity of 2.
• Select multiple subnets across us-east-1a, us-east-1b, and us-east-1c.

Step 2: Load Balancing

• Deploy an Application Load Balancer (ALB).
• Register the ASG as the target group. The ALB automatically performs health checks and routes traffic away from failed instances.

Step 3: Data Layer

• Modify the RDS instance to enable the Multi-AZ setting.
• Result: AWS automatically provisions a standby in a different AZ and begins synchronous replication. In a failure, the DNS record for the DB endpoint automatically updates to point to the standby.

Checkpoint Questions

1. What is the main difference between RDS Multi-AZ and RDS Read Replicas regarding replication type?
2. Which DR strategy has the lowest RTO: Pilot Light or Warm Standby?
3. How does Amazon Route 53 determine when to failover to a secondary region?
4. True or False: In an Aurora cluster, all instances can be active for reads across multiple AZs.

Muddy Points & Cross-Refs

[!TIP] Common Confusion: Multi-AZ vs. Multi-Region

• Multi-AZ is for High Availability (Automatic failover, low latency, synchronous for RDS).
• Multi-Region is for Disaster Recovery (Manual or DNS-based failover, higher latency, asynchronous replication).

Performance Impact: Using Synchronous replication (Multi-AZ) can slightly increase write latency because the data must be committed in two locations. Always test application performance after enabling Multi-AZ.

Comparison Tables

Deployment Comparison