6.4 Disaster Recovery Patterns & Multi-Region Resilience
Key Takeaways
- The four AWS Disaster Recovery strategies—Backup & Restore, Pilot Light, Warm Standby, and Multi-Site Active/Active—represent a progressive spectrum trading cost and complexity for reduced RTO and RPO.
- Backup & Restore offers the lowest cost with RTO of 24+ hours and RPO in hours; Multi-Site Active/Active achieves near-zero RTO and RPO by serving traffic actively across multiple Regions.
- Pilot Light maintains continuously synchronized core datastores while keeping compute dormant until failover, whereas Warm Standby runs a scaled-down, functional mirror 24/7 that scales rapidly to full capacity upon a disaster declaration.
- Amazon Aurora Global Database provides dedicated storage-level cross-Region replication with sub-second latency, supporting managed planned switchovers and unplanned failover in under 1 minute without data loss.
- AWS Resilience Hub evaluates workload architectures against the AWS Well-Architected Framework, tracks resilience posture against RTO/RPO targets, and generates chaos experiments for AWS Fault Injection Service (FIS).
6.4 Disaster Recovery Patterns & Multi-Region Resilience
CloudOps Blueprint Focus: Architecting for disaster resilience across AWS Regions requires evaluating trade-offs between business downtime tolerance and infrastructure expenditure. On the AWS Certified CloudOps Engineer – Associate (SOA-C03) exam, you must classify the four standard disaster recovery (DR) strategies, orchestrate failover mechanisms using Amazon Aurora Global Database, and implement resilience assessments with AWS Resilience Hub and AWS Fault Injection Service (FIS).
The Four AWS Disaster Recovery Strategies Spectrum
AWS defines four foundational disaster recovery patterns representing a continuous spectrum. As an organization shifts from Backup and Restore toward Multi-Site Active/Active, Recovery Time Objective (RTO) and Recovery Point Objective (RPO) decrease from days to near-zero, while operational complexity and infrastructure costs increase correspondingly.
1. Backup and Restore (Cold Standby)
- Architecture: The most cost-effective DR strategy. Workload data is backed up regularly using Amazon S3 Cross-Region Replication or AWS Backup and stored in a secondary Region. No compute or database instances run in the DR Region during normal operations.
- Failover Execution: When disaster strikes, automation scripts or CloudFormation provision networking, databases from backups, and compute fleets before redirecting Route 53 DNS.
- Operational Profile: RPO is hours; RTO is 24+ hours. Best suited for non-critical internal workloads where extended downtime carries minimal business impact.
2. Pilot Light
- Architecture: Core data is continuously synchronized to the secondary Region (e.g., RDS read replica, Aurora Global Database secondary, or DynamoDB Global Table). Compute infrastructure remains dormant as pre-baked AMIs and CloudFormation templates.
- Failover Execution: Teams promote the secondary database, launch application fleets from AMIs via Auto Scaling, and redirect Route 53 DNS.
- Operational Profile: RPO is minutes; RTO is 10s of minutes. Ideal for core applications requiring quick recovery while avoiding idle compute costs.
3. Warm Standby
- Architecture: Runs a scaled-down, fully functional mirror of the production stack 24/7 in the secondary Region (e.g., an Auto Scaling group running 2 instances compared to 20 in production) capable of handling internal or canary traffic.
- Failover Execution: Auto Scaling groups rapidly scale up to full capacity, the secondary database is promoted, and Route 53 or AWS Global Accelerator shifts 100% of user traffic.
- Operational Profile: RPO is seconds to minutes; RTO is minutes. Best for business-critical applications requiring fast cutover without full redundancy costs.
4. Multi-Site Active/Active (Hot Standby)
- Architecture: Full-capacity, production-grade infrastructure runs simultaneously across multiple Regions, actively serving traffic balanced by Route 53 or AWS Global Accelerator.
- Failover Execution: Automated health checks detect regional failure and immediately steer traffic to healthy Regions without provisioning or scaling delays.
- Operational Profile: Near-zero RPO and near-zero RTO. Essential for mission-critical banking, healthcare, and e-commerce platforms where any downtime causes severe losses.
| DR Strategy | Typical RPO | Typical RTO | Relative Cost | Data Layer State | Compute State in DR Region |
|---|---|---|---|---|---|
| Backup & Restore | Hours | 24+ Hours | $ (Lowest) | Cold backup copies in S3 | Off (0 instances) |
| Pilot Light | Minutes | 10s of Minutes | $$ (Low) | Continuously synchronized | Off (0 instances, AMIs pre-staged) |
| Warm Standby | Seconds / Minutes | Minutes | $$$ (Medium) | Continuously synchronized | Scaled down (minimal running fleet) |
| Multi-Site Active/Active | Near Zero | Near Zero | $$$$ (Highest) | Active multi-region read/write | Full production capacity running 24/7 |
Amazon Aurora Global Database Architecture & Failover
For relational workloads demanding minimal RTO and RPO, Amazon Aurora Global Database spans multiple AWS Regions with dedicated storage-level replication:
- Storage-Level Replication: Dedicated storage nodes replicate redo logs directly across Regions over AWS network backbones in under 1 second, bypassing compute instances with zero impact on primary database write performance.
- Topology: Supports one primary read/write cluster and up to 5 secondary read-only clusters across Regions, each hosting up to 16 read replicas.
Aurora Global Database provides two failover mechanisms:
- Planned Switchover: Used for disaster drills or maintenance. It synchronizes secondary storage, promotes the secondary cluster with zero data loss, and converts the former primary into a read-only secondary in under 1 minute.
- Unplanned Failover: Used during catastrophic outages. Teams detach and promote a secondary cluster to standalone read/write status in under 1 minute, with RPO governed by storage replication lag (typically sub-second).
AWS Resilience Hub & Chaos Engineering with AWS FIS
Operational readiness requires continuous assessment and automated validation:
- AWS Resilience Hub: A centralized service that evaluates application architectures against defined RTO and RPO targets. Resilience Hub imports architectures from CloudFormation, Terraform, or Resource Groups, benchmarks them against the AWS Well-Architected Framework, flags single points of failure, and produces actionable remediation guidance and runbooks.
- AWS Fault Injection Service (FIS) Integration: To empirically prove failover readiness, Resilience Hub automatically generates chaos experiment templates for AWS Fault Injection Service (FIS). Teams execute controlled fault injections—such as database failovers, AZ packet drops, or CPU stress—to verify automated recovery before real outages occur.
An e-commerce company requires a disaster recovery strategy for its core checkout application. The business requires an RTO of less than 15 minutes and an RPO of less than 2 minutes. The company wants to minimize ongoing cloud infrastructure costs and avoid paying for idle full-scale compute capacity in the secondary Region, but cannot tolerate the multi-hour provisioning delays of a cold backup restore. Which disaster recovery strategy should the CloudOps engineer recommend?
An enterprise uses Amazon Aurora Global Database across us-east-1 (primary) and us-west-2 (secondary). During a routine disaster recovery drill, the operations team needs to rotate primary operations to us-west-2 with zero data loss and minimal operational disruption. Which action should the CloudOps engineer execute?
A financial services company needs to systematically assess whether its mission-critical AWS workloads meet enterprise RTO and RPO objectives, identify single points of failure in their CloudFormation stacks, and automatically generate chaos engineering experiments to validate failover readiness. Which AWS service fulfills these operational governance requirements?