Design Resilient Architectures
Study cheat sheet · SAA-C03)
Key Concepts
- Resilient architecture = systems that remain available and recover quickly from failures
- High Availability (HA) = minimizing downtime; system stays up even if components fail
- Fault Tolerance = system continues operating without degradation even during failure (stricter than HA)
- Disaster Recovery (DR) = ability to recover from catastrophic failure; measured by RTO (how fast you recover) and RPO (how much data you can afford to lose)
- Multi-AZ = deploy resources across multiple Availability Zones for HA within a region
- Multi-Region = deploy across regions for DR and global resilience
- Elastic Load Balancer (ELB) = distributes traffic; automatically removes unhealthy instances
- Auto Scaling Groups (ASG) = automatically replace failed instances, scale out under load
- S3 = 99.999999999% (11 9s) durability; replicated across ≥3 AZs by default
- RDS Multi-AZ = synchronous replication to standby; automatic failover (~1-2 min)
- RDS Read Replicas = asynchronous; used for read scaling, NOT automatic failover
- Aurora = 6 copies of data across 3 AZs; self-healing; up to 15 read replicas
- Aurora Global Database = replication across regions with <1 second lag; used for DR
- Route 53 = DNS-based routing with health checks; supports failover, latency, weighted routing
- SQS = decouples components; messages persisted during downstream failures (resilience buffer)
- DR Strategies (cheapest → fastest recovery):
- Backup & Restore → high RTO/RPO, lowest cost
- Pilot Light → core services running, scale up on disaster
- Warm Standby → scaled-down but fully functional environment running
- Multi-Site Active/Active → full duplicate running; lowest RTO/RPO, highest cost
How It Works
Resilience is layered: 1. Data layer → Multi-AZ RDS, S3 versioning, DynamoDB global tables 2. Compute layer → ASG replaces unhealthy EC2; Lambda is inherently HA 3. Network layer → ELB health checks route away from failures; Route 53 DNS failover 4. Application layer → SQS/SNS decouple services so one failure doesn't cascade
Failover flow (RDS Multi-AZ): - Primary fails → Route 53 CNAME flips to standby automatically → no manual intervention needed
Route 53 Health Checks: - Can trigger DNS failover to another region or endpoint if primary becomes unhealthy - Combine with Latency, Failover, or Weighted routing policies for resilience
Key Values to Remember
| Service | Key Metric |
|---|---|
| S3 Standard | 99.99% availability, 11 9s durability |
| RDS Multi-AZ Failover | ~1–2 minutes |
| Aurora replicas | Up to 15 read replicas |
| Aurora Global DB replication lag | < 1 second |
| SQS message retention | Up to 14 days |
| ELB health check interval | Default 30 seconds |
| DynamoDB Global Tables | Active-active multi-region |
| ASG health check grace period | Default 300 seconds |
Exam Gotchas
-
Read Replicas ≠ Failover — RDS Read Replicas are for read scaling, not automatic failover. Only Multi-AZ provides automatic failover. Exam questions love to swap these.
-
Pilot Light ≠ Warm Standby — Pilot Light has only the absolute core (e.g., DB) running. Warm Standby has a fully functional scaled-down system. Know the distinction when matching cost vs. RTO.
-
Single-AZ = Single point of failure — Any answer with a single AZ deployment is almost always wrong when the question asks about high availability or resilience.
-
**Aurora vs