18. Disaster Recovery Strategies
The general four-tier concept (Backup & Restore → Pilot Light → Warm Standby → Multi-Site Active/Active, trading cost for RTO/RPO) isn't AWS-specific — see Disaster Recovery Strategies for the vendor-neutral concept, tradeoffs, and when-to-use guidance. What follows here is only the AWS service mapping for each tier, since that's the exam-specific part.
Backup and Restore
AWS implementation: AWS Backup, RDS/EBS snapshots copied to the DR Region; no standing compute. Exam signal: "Lowest cost," "acceptable downtime of hours."
Pilot Light
AWS implementation: A replicating RDS/Aurora read replica (or continuous DB replication) in the DR Region; AMIs/launch templates staged but no running EC2/ASG capacity until failover. Exam signal: "Core database always on," everything else scaled to zero.
Warm Standby
AWS implementation: A scaled-down ALB + Auto Scaling group + Multi-AZ RDS running continuously in the DR Region, sized up via Auto Scaling on failover. Exam signal: RTO around 30 minutes, explicitly rules out replicating the full production-sized architecture (ruling out active/active), and the secondary Region shouldn't serve live traffic unless necessary (also ruling out active/active) — the standard "budget-constrained but not Pilot-Light-slow" answer.
Multi-Site Active/Active
AWS implementation: Full Region-to-Region duplication with Route 53 (latency or weighted routing across both Regions), Aurora Global Database or DynamoDB Global Tables for active-active data, both Regions serving live traffic simultaneously. Exam signal: "Near-zero downtime," "active in both Regions," cost is explicitly not the constraint.
Comparison Summary
| Strategy | Cost | RTO (Recovery Time) | RPO (Data Loss) | Standing Compute? |
|---|---|---|---|---|
| Backup & Restore | Lowest | Hours/Days | Hours/Days | No |
| Pilot Light | Low | Minutes/Hours | Minutes/Hours | DB only |
| Warm Standby | Medium | Minutes | Minutes | Scaled-down |
| Multi-Site | Highest | Near-Zero | Near-Zero | Full duplication |
RTO vs. RPO, defined precisely (exam-critical — the two terms get swapped constantly):
- RTO (Recovery Time Objective) — How long the business can tolerate being down after a disaster before service is restored. A question stating "the application must be back online within 1 hour" is describing an RTO requirement.
- RPO (Recovery Point Objective) — How much data the business can afford to lose, measured as time since the last valid backup/replication point. A question stating "no more than 5 minutes of transaction data can be lost" is describing an RPO requirement.
- The tell: RTO is about downtime duration; RPO is about data-loss window. A tight RPO (near-zero data loss) pushes you toward continuous replication (Warm Standby/Multi-Site); a tight RTO (near-zero downtime) pushes you toward having compute already running (Warm Standby/Multi-Site) rather than provisioning from scratch (Pilot Light/Backup & Restore).
Exam Example (SAA-C03 pattern): "A company's disaster recovery plan requires an RTO of 30 minutes and an RPO of 5 minutes, while keeping costs as low as possible. Which DR strategy best meets these requirements?" Answer choices: Backup and Restore / Pilot Light / Warm Standby / Multi-Site Active/Active.
- Correct Answer: Warm Standby — A scaled-down but running environment can be sized up within ~30 minutes, and continuous replication keeps data loss to minutes — satisfying both objectives without paying for full production-scale duplication in the DR Region.
- Why not Backup and Restore or Pilot Light? — Both have RTOs measured in hours (provisioning/restoring compute from scratch), failing the 30-minute RTO requirement.
- Why not Multi-Site Active/Active? — Meets the RTO/RPO easily, but at the highest cost — the question explicitly asks to minimize cost, so it's over-engineered for the stated requirement.