Design Resilient Architectures
This domain accounts for 26% of the AWS SAA-C03 exam — the single largest domain. It tests your ability to select services and configurations that keep workloads running during failures, scale under load, and recover within defined time objectives. Expect 13–17 questions that present a broken or under-designed architecture and ask you to fix it, or give you RTO/RPO requirements and ask you to match them to a strategy. You must know exact defaults, limits, and behavioral differences between similar services.
Multi-AZ and Multi-Region Patterns, RTO/RPO Trade-offs
RTO (Recovery Time Objective) is the maximum acceptable downtime after a failure. RPO (Recovery Point Objective) is the maximum acceptable data loss measured in time. Lower RTO/RPO = higher cost and complexity.
| Pattern | Typical RTO | Typical RPO | Cost | Notes |
|---|---|---|---|---|
| Backup and Restore | Hours | Hours | Lowest | Data restored from S3/Glacier |
| Pilot Light | 10–30 min | Minutes | Low | Core services running, scale on failover |
| Warm Standby | Minutes | Seconds–minutes | Medium | Scaled-down but live environment |
| Active-Active (Multi-Region) | Near zero | Near zero | Highest | Traffic split across regions |
Multi-AZ protects against a single data-center failure within a region. Multi-Region protects against a regional outage or supports low-latency global users.
Common traps:
- Confusing multi-AZ with high availability vs. multi-Region with disaster recovery — the exam distinguishes them.
- Assuming "Multi-AZ" RDS always has zero RPO — a brief lag exists during synchronous commit acknowledgment.
- Pilot light requires pre-provisioned AMIs and DNS changes; it does NOT auto-scale on failure without automation.
- Warm standby is already running (just small) — do not confuse with pilot light where compute is off.
Worked scenario: A company needs RTO < 15 minutes and RPO < 1 minute for a database tier, and budget is moderate. → Warm standby with RDS Multi-AZ (synchronous replication, automatic failover ~1–2 min) plus cross-region snapshots for broader DR.
ELB Types and Health Checks, Auto Scaling Groups and Policies
Elastic Load Balancing Types
| Feature | ALB | NLB | GWLB |
|---|---|---|---|
| Layer | 7 (HTTP/HTTPS/gRPC) | 4 (TCP/UDP/TLS) | 3 (IP packets) |
| Use case | Web apps, path/host routing | Low-latency, static IP, gaming | Inline virtual appliances |
| Sticky sessions | Yes (cookie-based) | Yes (source IP) | N/A |
| WebSockets | Yes | Yes | N/A |
| TLS termination | Yes | Yes (passthrough option) | No |
| IP type | Dynamic | Static / Elastic IP | — |
| Health check protocols | HTTP, HTTPS, gRPC | TCP, HTTP, HTTPS | TCP, HTTP, HTTPS |
Health checks: ELB marks an instance InService only after a defined number of consecutive successful checks (healthy threshold, default 2–3 depending on type). Instances failing the unhealthy threshold (default 2–3) are removed from rotation. Health checks are independent of Auto Scaling health checks unless you enable ELB health checks on the ASG.
Auto Scaling Groups (ASG)
Scaling policies:
| Policy Type | How it works | Best for |
|---|---|---|
| Target Tracking | Maintains a metric at a target value (e.g., CPU = 50%) | Steady predictable load |
| Step Scaling | Adds/removes capacity in steps based on alarm thresholds | Variable bursty load |
| Simple Scaling | One action per alarm, then cooldown | Legacy; rarely best answer |
| Scheduled Scaling | Scale at known times | Predictable time-based patterns |
| Predictive Scaling | ML-based forecast + proactive scale-out | Cyclical patterns |
Key defaults/limits:
- Default cooldown: 300 seconds (simple scaling only).
- Warm-up period (instance warm-up): time before a new instance contributes to CloudWatch metrics; prevents premature scale-in.
- Desired, Min, Max capacity: ASG will not go below Min or above Max.
- Launch template is preferred over launch configuration (supports versioning, mixed instance types).
- ASG termination policy default: oldest launch configuration, then closest to billing hour.
Common traps:
- Enabling ELB health checks on the ASG is not automatic — you must configure it; without it, terminated EC2s stay in the ASG as healthy.
- Target tracking creates and manages CloudWatch alarms automatically — do not create manual alarms for it.
- Cooldown does not apply to target tracking or step scaling (only simple scaling).
- "Unhealthy" in ELB ≠ "Unhealthy" in EC2 status checks unless ELB health checks are enabled on the ASG.
Unlock with a paid plan
10 more sections (about 2,725 words) continue below. Every paid plan unlocks all SAA-C03 study guides, the full question bank and mock exams, from $4.97/month.