AWS Disaster Recovery Architecture — Overview
Disaster Recovery (DR) ensures business continuity when an entire region or infrastructure becomes unavailable. AWS offers four DR strategies with increasing cost and decreasing recovery time. Choosing the right strategy depends on your RTO (Recovery Time Objective) and RPO (Recovery Point Objective). This is heavily tested on SAP-C02 and DOP-C02.
Strategy Deep Dive
1. Backup & Restore
Approach: Data is backed up to a DR region. On disaster, restore data and rebuild infrastructure from templates.
- Data replication: S3 Cross-Region Replication, EBS snapshot copy, RDS automated backup copy, DynamoDB on-demand backup to another region
- Infrastructure: CloudFormation/CDK templates stored in S3 — deploy on failover
- Recovery process: Restore latest snapshot → Launch infrastructure from templates → Update DNS
- RTO: Hours (time to restore + launch + warm up)
- RPO: Hours (depends on backup frequency)
- Cost: Only storage costs in DR region during normal operation
2. Pilot Light
Approach: Core data layer is always replicated and running in DR. Compute and app tier are provisioned on failover.
- Always running: RDS Read Replica or Aurora Global Database secondary in DR region
- Ready to launch: AMIs pre-built, Launch Templates configured, ASG desired=0 (or minimal)
- Recovery process: Promote DB replica → Scale ASG to desired → Update DNS
- RTO: 10s of minutes (DB promotion + instance launch + health checks)
- RPO: Minutes (async replication lag)
- Key difference from Backup/Restore: Data is already there (no restore step)
3. Warm Standby
Approach: Full application stack runs in DR at reduced capacity. Scale up to production on failover.
- Always running: Full stack at minimum scale (e.g., 1 instance per tier instead of 10)
- DB: Aurora Global Database or RDS Multi-Region with synchronous or near-synchronous replication
- Recovery process: Scale up ASG/ECS → Promote DB (if needed) → Route 53 failover
- RTO: Minutes (just scaling, no provisioning from scratch)
- RPO: Seconds (continuous replication)
- Bonus: DR environment can serve read traffic or run batch jobs during normal ops (cost offset)
4. Multi-Site Active/Active
Approach: Full production capacity in multiple regions simultaneously serving traffic.
- Always running: Full production scale in 2+ regions
- Data: DynamoDB Global Tables (multi-master) or Aurora Global Database (single writer, fast failover)
- Routing: Route 53 latency-based or weighted routing distributes traffic across regions
- No failover: If one region fails, Route 53 health checks remove it — other region(s) absorb traffic
- RTO/RPO: Near zero — no recovery action needed
- Challenge: Data consistency, conflict resolution (DynamoDB uses last-writer-wins)
Key AWS Services for DR
| Service | DR Role | Strategies |
|---|---|---|
| Route 53 | DNS failover (health checks → automatic routing switch) | All strategies |
| Aurora Global Database | Cross-region replication (<1s lag), managed failover (<1min) | Pilot Light, Warm, Active/Active |
| DynamoDB Global Tables | Multi-region, multi-master replication | Active/Active |
| S3 Cross-Region Replication | Async object replication to DR region | All strategies |
| CloudFormation StackSets | Deploy infrastructure templates across regions/accounts | Backup/Restore, Pilot Light |
| AWS Elastic Disaster Recovery | Continuous block-level replication of servers to DR region | Pilot Light, Warm Standby |
| Global Accelerator | Static IPs with automatic failover to healthy endpoints | Warm, Active/Active |
| AWS Backup | Centralized backup management with cross-region copy rules | Backup/Restore |
Route 53 Failover Patterns
- Active-Passive (Failover): Primary record with health check → Secondary record (DR). Traffic goes to secondary only when primary fails. Used with Pilot Light/Warm Standby.
- Active-Active (Latency/Weighted): Both regions serve traffic simultaneously. Health checks remove unhealthy region. Used with Multi-Site.
- Health checks: HTTP/HTTPS endpoint checks, CloudWatch alarm-based checks, calculated checks (combine multiple)
RTO/RPO Selection Guide
| Requirement | Strategy | Typical Use Case |
|---|---|---|
| RTO: 24h, RPO: 24h | Backup & Restore | Non-critical internal apps, dev/test |
| RTO: 30min, RPO: 5min | Pilot Light | Important business apps, SLA-backed internal systems |
| RTO: 5min, RPO: 1min | Warm Standby | Customer-facing apps, e-commerce, SaaS platforms |
| RTO: 0, RPO: 0 | Multi-Site Active/Active | Mission-critical (financial, healthcare), global services |
DR Testing & Automation
- AWS Resilience Hub — Assess applications against RTO/RPO targets, identify gaps, generate recommendations
- AWS Fault Injection Service (FIS) — Simulate failures (AZ outage, instance termination) to validate DR readiness
- GameDay exercises — Regular scheduled failover drills to validate runbooks and team readiness
- Automated failover runbooks — Systems Manager Automation documents for repeatable DR procedures
Exam Tips by Certification
| Exam | Focus Areas |
|---|---|
| SAP-C02 | Strategy selection based on RTO/RPO/cost requirements, Aurora Global vs DynamoDB Global Tables, Route 53 failover configuration, multi-region architecture decisions, cost optimization of DR |
| DOP-C02 | Automated failover runbooks (SSM Automation), infrastructure-as-code for DR (StackSets), monitoring for failover triggers, testing DR with FIS, CI/CD across regions |
AWS Certification Exam Practice Questions
Question 1:
A company requires RTO of 15 minutes and RPO of 1 minute for their customer-facing application. They want to minimize costs while meeting these targets. Which DR strategy is MOST appropriate?
- Backup & Restore
- Pilot Light
- Warm Standby
- Multi-Site Active/Active
Show Answer
Answer: C – Warm Standby provides RTO of minutes and RPO of seconds (continuous replication). Pilot Light would have RTO of 10s of minutes (too slow for 15-min requirement when accounting for DB promotion + instance scaling). Multi-Site would exceed requirements and cost significantly more. Warm Standby is the minimum cost strategy meeting both targets.
Question 2:
An application uses Aurora MySQL as its primary database. The DR strategy requires the database to fail over to another region in under 1 minute with minimal data loss. Which Aurora feature provides this?
- Aurora Read Replica in another region with manual promotion
- Aurora Global Database with managed planned/unplanned failover
- RDS Multi-AZ with cross-region snapshot copy
- Aurora Serverless with multi-region configuration
Show Answer
Answer: B – Aurora Global Database replicates data across regions with <1 second lag using dedicated replication infrastructure. Managed failover promotes a secondary region to read-write in typically under 1 minute. Cross-region Read Replicas require manual promotion (slower and more error-prone). Multi-AZ is same-region only.
Question 3:
A global SaaS company needs zero-downtime even during a full region failure. Their application uses a NoSQL database. Users in multiple continents should always hit the closest region with read-write access. Which architecture achieves this?
- Aurora Global Database with Route 53 latency-based routing
- DynamoDB Global Tables with Route 53 latency-based routing
- ElastiCache Global Datastore with CloudFront
- RDS Multi-AZ in each region with cross-region read replicas
Show Answer
Answer: B – DynamoDB Global Tables provide multi-region, multi-master (active-active) replication. Users in any region get read-write access to their local table with sub-second replication to other regions. Route 53 latency routing sends users to the closest region. Aurora Global has only a single write region (not true active-active write).
Question 4:
A company’s DR plan uses Pilot Light strategy. During a failover drill, they find that recovering takes 45 minutes instead of the expected 15 minutes. Most time is spent waiting for EC2 instances to launch and pass health checks. How should they reduce RTO?
- Switch to Backup & Restore with faster snapshots
- Pre-warm the load balancer and use pre-baked AMIs with reduced health check grace periods
- Upgrade to Warm Standby with minimum-scale running instances
- Use larger instance types for faster boot time
Show Answer
Answer: C – If Pilot Light can’t meet the RTO target, upgrade to Warm Standby — instances are already running at minimum scale, so failover only requires scaling up (adding instances to existing ASG), not provisioning from scratch. This eliminates instance launch + configuration time. Pre-baked AMIs help but won’t achieve 15-min if the fundamental issue is launch time.
Question 5:
An architect wants to validate that their multi-region application can survive an AZ failure without manual intervention. Which AWS service allows them to safely simulate this in production?
- AWS Config with remediation actions
- AWS Fault Injection Service (FIS) with AZ disruption experiment
- CloudWatch Synthetics with failure injection
- AWS Systems Manager Automation with termination scripts
Show Answer
Answer: B – AWS Fault Injection Service (FIS) provides controlled chaos engineering experiments including AZ power disruption simulation. It safely tests resilience by injecting real failures with automatic stop conditions (guardrails) that halt the experiment if impact exceeds defined thresholds. This validates DR without risking uncontrolled damage.
Frequently Asked Questions
What is the difference between RTO and RPO?
RTO (Recovery Time Objective) is the maximum acceptable time to restore service after a disaster — “how long can we be down?” RPO (Recovery Point Objective) is the maximum acceptable data loss measured in time — “how much data can we lose?” Lower values for both cost more to achieve.
Can I use Multi-AZ instead of multi-region for DR?
Multi-AZ protects against single AZ failures (hardware, networking) but NOT against region-wide events (which are rare but possible). For true DR against region failure, you need multi-region. Multi-AZ is high availability (HA), not disaster recovery (DR). Most production workloads need both.
What is AWS Elastic Disaster Recovery?
AWS Elastic Disaster Recovery (DRS) continuously replicates servers (block-level) to a staging area in your DR region. On failover, it launches fully provisioned servers from the latest replication point within minutes. It’s ideal for lift-and-shift workloads and Pilot Light/Warm Standby strategies where you need rapid server recovery.