Study guide
6.4 Disaster Recovery Patterns & Multi-Region Resilience
AWS Certified CloudOps Engineer – Associate SOA-C03
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Monitoring & Observability Infrastructure
1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms
2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation
2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda
3 Chapter 3: Performance Optimization for Compute, Storage & Databases
3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance
4 Chapter 4: Compute & Database Scalability and Elasticity
4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB
5 Chapter 5: High Availability, Fault Tolerance & Load Balancing
5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments
6 Chapter 6: Backup, Data Protection & Disaster Recovery
6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience
7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK
7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures
8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC
8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows
9 Chapter 9: Systems Manager & Event-Driven Operations Automation
9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation
10 Chapter 10: Identity, Access Management & Governance
10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs
11 Chapter 11: Data Security, Encryption & Vulnerability Management
11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings
12 Chapter 12: VPC Architecture, Endpoints & Network Protection
12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing
13 Chapter 13: DNS, Route 53 Routing & Content Delivery
13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator
14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity
14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting
6.4 Disaster Recovery Patterns & Multi-Region Resilience
Key Takeaways Explain This Topic AI
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).
Last updated: September 2026
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.