3.1.1.1. Multi-AZ and Multi-Region Deployments (Compute, Data Layer)
3.1.1.1. Multi-AZ and Multi-Region Deployments (Compute, Data Layer)
Multi-AZ protects against single datacenter failures. Multi-Region protects against entire region outages and reduces latency for global users. The exam expects you to know which services support each pattern and the trade-offs involved.
Compute layer HA patterns:
| Pattern | Mechanism | Failover Time |
|---|---|---|
| EC2 + ASG across AZs | ASG replaces failed instances in healthy AZs | Minutes |
| ECS/EKS across AZs | Scheduler places tasks in available AZs | Seconds |
| Lambda | Automatically multi-AZ within a region | Seamless |
| EC2 Multi-Region | Separate ASGs per region + Route 53 failover | Minutes |
Data layer HA patterns:
| Service | Multi-AZ | Multi-Region |
|---|---|---|
| RDS | Synchronous standby, automatic failover (1-2 min) | Read replicas, manual promotion |
| Aurora | Up to 15 read replicas across AZs, auto failover (30s) | Global Database, <1s replication lag |
| DynamoDB | Automatic across 3 AZs | Global Tables (active-active, seconds lag) |
| ElastiCache Redis | Multi-AZ with auto-failover | Global Datastore (cross-region read replicas) |
| S3 | Automatic across ≥3 AZs | Cross-Region Replication (CRR) |
Exam Trap: RDS Multi-AZ is not a read scaling solution — the standby is for failover only and cannot serve read traffic. For read scaling, use read replicas. Aurora is different: its read replicas do serve read traffic AND participate in failover. If the exam asks about both read scaling and HA, Aurora read replicas are the answer.
Designing Multi-AZ capacity (N+1 AZ sizing): size each AZ so that the AZs left after one fails can still carry peak load plus any required headroom. Example: peak needs 4 instances across 3 AZs → 2 per AZ leaves exactly 4 after an AZ loss (no spare); if one spare is also required, you need 3 per AZ (6 survive). Pair this with load balancer health checks that route around a failed AZ and stateless instances (state in ElastiCache, DynamoDB or S3). A cluster placement group packs instances into a single AZ — the opposite of this goal.
High availability vs. fault tolerance: HA minimizes downtime through redundancy and automatic failover, accepting a brief interruption (e.g., an RDS Multi-AZ failover). Fault tolerance eliminates the interruption: redundant components are already serving, so a failure is absorbed with no user-visible outage. Fault tolerance costs more.
