What's changed: Covered in-scope services: Elastic Disaster Recovery, Resilience Hub, Compute Optimizer, FSx (4 types), Aurora Serverless v2, DocumentDB, MemoryDB for Redis, Redshift, EKS Distro, ROSA, DMS, Transit Gateway, PrivateLink, Client VPN, Site-to-Site VPN
3.3Backup and Disaster Recovery
Understand data protection and recovery—AWS Backup, snapshots, cross-region replication, and DR strategies (RTO/RPO). Recover reliably from failures and data loss.
Resilience requires data protection and recovery. Centralize backups with AWS Backup and pick a DR strategy by RTO/RPO.
3.3.1Backup and DR
- AWS Backup: centrally back up EBS/RDS/DynamoDB/EFS via policies with schedules and retention.
- Cross-region copy: replicate snapshots/data to another region for regional failures.
- DR strategy: by RTO/RPO, choose from backup & restore → pilot light → warm standby → multi-site.
- Automation: codify/automate backup and recovery for reliable, repeatable restores.
Common on DOP-C02: centralized backup = AWS Backup, regional protection = cross-region copy, choose DR by RTO/RPO (backup&restore < pilot light < warm standby < multi-site). Automate DR procedures and regularly test restores.
DOP-C02 centers on "which DR strategy and automation meet the RTO/RPO requirement." RPO (recovery point objective) is how much data loss is tolerable; RTO (recovery time objective) is how fast you must recover—the tighter both are, the costlier the strategy. Backup & restore is cheapest with RTO/RPO of hours-to-days; pilot light keeps only the core (e.g., a DB replica) always-on in another region with the rest dormant; warm standby keeps a scaled-down copy running for quick expansion; multi-site (active/active) runs production in both regions with near-zero RTO/RPO. AWS Backup centrally manages EBS/RDS/Aurora/DynamoDB/EFS/Storage Gateway via backup plans, with cross-region/cross-account copy and Backup Vault Lock (WORM) for resilience against ransomware and accidental deletion. For data replication, choose S3 CRR/SRR, Aurora Global Database (sub-second RPO, fast region promotion), or DynamoDB global tables (multi-active) per requirements. Codify DR procedures (IaC + SSM Automation / Step Functions) for repeatability, control switchover with Route 53 failover or Application Recovery Controller (routing controls), and validate effectiveness with periodic restore drills (game days).
| DR strategy | RTO/RPO | Cost and traits |
|---|---|---|
| Backup & restore | Hours–days | Cheapest; restore on failure |
| Pilot light | Tens of min–hours | Core always-on; rest dormant |
| Warm standby | Minutes–tens of min | Scaled-down always-on; expand fast |
| Multi-site (active/active) | Near-zero | Costliest; both regions serve prod |
Scenario: A core DB requires "almost no data loss (RPO seconds) and recovery within minutes even on a regional failure (RTO minutes)," with commensurate cost acceptable. → Replicate to another region with sub-second lag via Aurora Global Database, and promote the secondary on a regional failure. Keep the app tier as a warm standby (scaled-down, always-on) and switch over with Route 53 / Application Recovery Controller. Codify procedures in SSM Automation/Step Functions and validate with drills.
FAQ: Pilot light vs warm standby? Both pre-stage another region, but pilot light keeps only the core (mainly a DB replica) always-on, with the app tier stopped/unprovisioned and started/scaled at failover. Warm standby keeps a scaled-down app tier always running for a shorter RTO. Choose by the RTO-vs-cost trade-off.
Exam trap: Merely "taking backups" does not constitute DR. Without regularly testing restores, you may fail to recover or blow past RTO when it counts. Also, without configuring AWS Backup cross-region/cross-account copy, a regional outage or account compromise can take the backups down with it.
3.3.2AWS Elastic Disaster Recovery (AWS DRS)
Elastic Disaster Recovery (AWS DRS) continuously replicates servers—on-premises or in other clouds—to AWS at the block level, enabling failover with short RTO/RPO on a disaster (successor to CloudEndure Disaster Recovery). Install the replication agent on source servers; block-storage deltas are transferred continuously to a staging area. Only low-cost staging instances and storage run in the staging area during normal operations, minimizing cost. When disaster strikes, initiate failover (a few clicks or an API call) and EC2 instances boot from the most recent replicated state within minutes. RTO is on the order of minutes; RPO is on the order of seconds (back to the most recent replication point). Point-in-time (PITR) recovery to any past checkpoint is also available—e.g., reverting to a state before ransomware infected the system. After failover, once the original environment recovers you can fail back to on-premises, or cut over and stay on AWS. In a DevOps context, compared to manual warm standby or large-scale snapshot strategies, DRS delivers "continuous replication + rapid launch without manually pre-building infrastructure." Primary uses are DR to AWS for physical/virtual servers or other-cloud workloads, or workloads that cannot maintain a multi-region setup but need a short RTO.
- Continuous replication: block-level deltas transferred always; staging area waits at low cost.
- Short RTO/RPO: instances launch within minutes of initiating failover; RPO in seconds.
- PITR restore: recover to any past point in time (effective against ransomware, etc.).
- Failback / cutover: after recovery choose to fail back on-prem or cut over to AWS.
On DOP-C02: "continuously replicate on-prem servers to AWS and DR in minutes," "block-level replication + staging for low-cost standby," "successor to CloudEndure DR" = Elastic Disaster Recovery (AWS DRS). Distinguish from AWS Backup (snapshot-based, RTO in hours): DRS uses block replicas targeting sub-minute RPO and minute-range RTO—a more aggressive DR approach.
Exam trap: The DRS staging area is in a waiting state before production launch—the service is not yet running. EC2 instances only start when you "initiate" failover. This differs from a "warm standby that is always live." Also, when you use PITR to go back in time, data after that point is lost—confirm this is acceptable.
3.3.3Section summary
- Protection = AWS Backup + cross-region copy
- DR = strategy by RTO/RPO + automation/restore testing
- Continuous-replica DR = Elastic Disaster Recovery (AWS DRS) (block-level; RPO seconds; RTO minutes)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to centrally schedule and retain backups for EBS, RDS, and DynamoDB under common policies. What?
Q2. To prepare for a whole-region failure, you want snapshots also retained in another region. How?
Q3. Prioritizing low cost with RTO/RPO of hours acceptable, which DR strategy?