Based on the DOP-C02 exam guideReport an error
A common pitfall in designing Disaster Recovery for the first time is the ambition: "make recovery as fast as possible." But applying RTO=0 (instant recovery) to every workload explodes costs—you'd need identical infrastructure running in two regions permanently. The real skill in DR isn't "how fast" but "if this workload stops, how much do we lose per minute?", then weighing that against cost to pick the right point. A payments system might lose millions per minute, making RTO=0 worth buying; an internal analytics dashboard down for half a day is just a postponed meeting, so the cheapest backup-restore strategy suffices.
AWS standardized this tradeoff into four strategies: Backup & Restore, Pilot Light, Warm Standby, Multi-Site Active-Active. These four are points on three axes—RTO (how fast), RPO (how little data lost), and cost—and moving left-to-right, you get faster and safer but pricier. Today we examine what economic logic each strategy rests on, which AWS service implements it, and how to make backups themselves immutable to even stop ransomware.
DR strategy appears in almost every DOP exam—"RTO 5 min, RPO seconds, mid-range cost: which strategy?", "block ransomware from encrypting backups too?", "automate Pilot Light failover?" The key is reading scenario numbers (RTO/RPO) and cost constraints, mapping to one of the four points.
All DR discussion begins with two numbers. RTO (Recovery Time Objective) is "allowed time from failure to recovery complete"—how fast must we be back? RPO (Recovery Point Objective) is "time window of acceptable data loss"—how recent must the last backup/replica be?
Past ────────────────[Failure]──────────────→ Now
│←─ RPO ─→│ │←─ RTO ─→│
Last safe point Failure occurs Recovery complete
(acceptable data loss) (tolerable downtime)
RPO is determined by replication frequency (daily backup = 24h RPO; real-time replication = seconds RPO). RTO is determined by how much standby infrastructure you pre-run. Both shrink with cost—RPO shrinks by replicating more often/in real-time; RTO shrinks by pre-running more standby infrastructure.
💡 Related Theory: RTO/RPO originate from 1970s mainframe-era Business Continuity Planning (BCP), formally defined in ISO 22301 (Business Continuity Management standard). The core insight: "recovery objectives are set by Business Impact Analysis (BIA), not technology." First, ask "if this system stops, how much per hour do we lose, what regulatory/contract violations occur?", then set RTO/RPO and choose technology accordingly. Conversely, applying "the fastest technically possible recovery" to all systems without BIA is burning money—an anti-pattern. AWS's four strategies are a mapping table translating BIA results (workload tiers) into technology.
| Strategy | RTO | RPO | Relative Cost | Core Structure |
|---|---|---|---|---|
| Backup & Restore | Hours–days | Hours | Low | Only backups kept; provision new environment on failure |
| Pilot Light | 10–50 minutes | Minutes | Medium | Data layer always (DB read replica, AMI ready); app tier off |
| Warm Standby | Minutes | Seconds–minutes | High | Scaled-down replica always running; expand on failover |
| Multi-Site Active-Active | ~0 | ~0 | Highest | Both regions handle production traffic simultaneously |
One principle cuts through all rows: "how much you keep running normally determines both RTO and cost." Keep nothing running (Backup & Restore) = cheapest but slowest (must build everything on failure). Keep everything running (Active-Active) = instant recovery but expensive. Pilot Light and Warm Standby are two compromise points in between.
Simplest strategy. Regularly back up data (EBS snapshots, RDS backups, AWS Backup) and copy to another region. In the DR region, run zero infrastructure during normal times. On failure, provision the infrastructure (via IaC stack deployment) and restore data from backup.
🔍 Deeper: A modern twist: Backup & Restore is "slow but, if IaC is good, surprisingly fast." Historically, reconstructing DR environment manually took days. With CloudFormation/Terraform encoding the entire infrastructure, "stack deploy → backup restore" can automate to hours RTO. This is where IaC meets DR—infrastructure-as-code means "data + code" alone lets you rebuild anytime (immutable infrastructure philosophy). So in exams, "minimize cost while automating recovery via IaC" often makes Backup & Restore the right answer.
The name—Pilot Light, like a gas stove's ignition spark—explains the strategy. In the DR region, keep data layer alive always (DB read replica receiving continuous replication, AMI/Launch Template ready), but shut down app tier (ASG desired=0). On failure, "light the spark"—promote Read Replica to standalone primary, raise ASG desired capacity to spin up app servers, failover DNS.
# DR region: Read Replica always replicating (data spark)
aws rds create-db-cluster --replication-source-identifier arn:...:cluster:prod \
--db-cluster-identifier prod-dr
# App tier off (ASG desired=0)
aws autoscaling create-auto-scaling-group --auto-scaling-group-name prod-dr \
--min-size 0 --max-size 20 --desired-capacity 0 --launch-template ...
# --- Failover activation (automated Lambda) ---
aws rds promote-read-replica-db-cluster --db-cluster-identifier prod-dr # Light the spark
aws autoscaling set-desired-capacity --auto-scaling-group-name prod-dr --desired-capacity 4
# Route 53 failover (Day 2)⚠️ Pitfall: Pilot Light's hidden risk: "while the app tier is off, nobody verifies it can actually boot." Old AMI can't start, IAM permissions might be missing, security group misconfigured—all unknown until failure, when you first try to launch and it fails. So Pilot Light must be validated via regular DR drills (quarterly/monthly): "does the spark light?" Warm Standby is safer partly because "the scaled-down environment is always running, always validated."
Warm Standby keeps a scaled-down version of production in the DR region, always running (e.g., 1 ALB + 2 EC2 + DB Replica). Normally it takes no traffic or read-only traffic, but the infrastructure is alive and functioning. On failure, immediately shift traffic here and Auto Scale to full capacity.
💡 Related Theory: The Warm Standby vs. Pilot Light difference is clearest as "path validation" presence/absence. Software reliability has a maxim: "unused code paths rot"—failover paths never exercised silently break, then fail when needed. Warm Standby, though scaled down, always runs real traffic (health checks, partial reads), keeping failover paths "warm" and continually validated. This touches AWS Well-Architected's "static stability" principle: on failure, don't start new behavior—let already-validated state keep running. You pay more to reduce "it won't work when we need it" risk.
Most expensive, most instant strategy. Both regions handle production traffic at full capacity simultaneously. Replicate data across both regions via Aurora Global / DynamoDB Global Tables; distribute users with Route 53 Latency Routing. If one region dies—there's no separate "failover" operation. Traffic simply shifts to the living region.
🔍 Deeper: Active-Active's near-zero RTO is because "there's nothing to recover"—both are alive, so just remove the dead one from the pool. But the costs are three-fold. First, 2x cost (both regions at full capacity). Second, data conflicts (Day 2's multi-leader LWW issue—if both regions write, same-item simultaneous updates collide). Third, capacity planning trap—each region normally takes 50% traffic; if one dies, the survivor must take 100%. So each region must be sized for 100% traffic, not 50% (else the survivor cascades after failover). "Can half the system dying mean the rest absorbs all load?" is the core validation question for Active-Active design.
If each service backs up differently (EBS snapshots, RDS native backups, DynamoDB PITR...), management fragments. AWS Backup unifies them under one policy and vault. Define schedule, retention, and region-copy in a backup plan; select resources by tags.
aws backup create-backup-plan --backup-plan '{
"BackupPlanName":"prod-daily",
"Rules":[{
"RuleName":"DailyBackup",
"TargetBackupVaultName":"prod-vault",
"ScheduleExpression":"cron(0 5 * * ? *)",
"Lifecycle":{"DeleteAfterDays":30},
"CopyActions":[{
"DestinationBackupVaultArn":"arn:aws:backup:us-east-1:...:backup-vault:dr-vault",
"Lifecycle":{"DeleteAfterDays":90}
}]
}]
}'💡 Related Theory: AWS Backup's tag-based selection is policy-based management—not imperative "register each resource one-by-one," but declarative "back up anything tagged Backup=prod," applied instantly when a new resource gets that tag. Same philosophy as Kubernetes label selectors, IAM's tag-based ABAC. Governance becomes "cannot accidentally miss"—if developers forget backup registration, the tag policy is a safety net.
Backups are useless if attackers steal admin rights and delete or encrypt the backups too. Ransomware's playbook: "delete backups first, then encrypt the main system." Backup Vault Lock makes backups immutable—once locked, backups cannot be deleted or modified, not even by root, during the retention period.
aws backup put-backup-vault-lock-configuration \
--backup-vault-name prod-vault \
--min-retention-days 30 --max-retention-days 365 \
--changeable-for-days 3--changeable-for-days 3 is a cooling-off period: you can release the lock within 3 days to fix mistakes, but after that, Compliance Mode locks completely—no one can release it.
📚 Case Study: The 2021 Colonial Pipeline ransomware incident (DarkSide group) shut down about 45% of U.S. East Coast fuel supply for days; the company paid ~$4.4M ransom (some later recovered). One lesson: "if backups live in the same permission boundary, they fall together." WORM (Write Once Read Many)—write once, read many, no modify—based immutable backup is ransomware recovery's last resort. Vault Lock Compliance Mode implements exactly this (same philosophy as S3 Object Lock Compliance Mode, SEC 17a-4 compliance storage). Lesson: backups aren't "there" unless "attackers can't delete them."
🔍 Deeper: Vault Lock's two modes: Governance Mode lets certain IAM-privileged users bypass/delete the lock (mistake prevention level), while Compliance Mode makes it unbreakable even by root before retention expires (true immutability, regulatory defense). The distinction separates "prevent accidents" from "defend against regulation and ransomware." In exams, "regulate that backups never delete" = Compliance Mode; "let admins override after approval" = Governance Mode. This same distinction applies to S3 Object Lock.
Manual, console-driven DR activation is slow and error-prone. Encode the activation procedure in Step Functions workflows or SSM Automation Runbooks—"promote Read Replica → expand ASG → failover Route 53 → validate alert" in one execution. Coded this way, regular drills can repeatedly validate, preventing Pilot Light/Warm Standby's "path rot" risk.
DR Runbook (Step Functions)
├─ 1. Promote Read Replica → standalone primary
├─ 2. ASG set-desired-capacity (0 → N)
├─ 3. ALB health check pass wait
├─ 4. Route 53 ARC Routing Control switch
└─ 5. Slack/SNS notify + Resilience Hub validate
Four pictures emerge today. First, DR is not "how fast" but an economics problem: BIA defines RTO/RPO, weighed against cost (ISO 22301); the four strategies are a mapping table. Second, the four strategies are a spectrum of "keep running normally": Backup & Restore (nothing; cheapest/slowest, but IaC speeds it up) → Pilot Light (data only, app off) → Warm Standby (scaled-down replica always, path validated) → Active-Active (full capacity both, RTO≈0, expensive, conflict/capacity-planning challenges). Third, AWS Backup unifies backups via tag-based policy governance and Cross-Region/Account Copy defends against disaster AND account compromise. Fourth, Vault Lock Compliance Mode's WORM-immutable backups block ransomware's "delete backups first" tactic (Colonial Pipeline lesson); DR activation must be code-driven (Step Functions/SSM Runbooks) and periodically validated via drills.
Next, we verify these DR strategies actually work: Resilience Hub measures RTO/RPO, and FIS automates chaos engineering to test failover repeatedly.
Click a choice to reveal the answer and explanation.
Question 1
A workload requires "RTO 5 minutes, RPO seconds to minutes, medium cost acceptable." The environment must be running in normal times so the failover path is always validated. Which DR strategy fits best?
Question 2
What is the most common operational risk of the Pilot Light DR strategy, and how do you mitigate it?
Question 3
When designing Multi-Site Active-Active, two regions each handle 50% of normal traffic. What must you verify in capacity planning?
Question 4
A ransomware attacker has seized operational privileges and is trying to delete the backups too. For regulatory compliance, you need to make it impossible for even root to delete backups within the retention period. What do you do?
Question 5
You have a Tier 3 workload where cost must be minimized, and the entire infrastructure is codified in CloudFormation. Which DR strategy fits best, and what are its RTO characteristics?
Question 6
You want to automatically prevent newly created resources from being left out of the backup policy, without relying on people to remember. What is the standard method?
Question 7
You want the DR activation procedure (promote Read Replica → expand ASG → Route 53 failover) to be repeatedly verifiable rather than a manual console operation. Which is most appropriate?
Four pictures emerge from today. First, DR is not a question of "how fast" but an economics problem — set RTO/RPO through BIA (business impact analysis) and weigh them against cost (ISO 22301) — and the four strategies are that mapping table. Second, the four strategies are a spectrum of "how much you keep running in normal times": Backup & Restore (nothing running, cheapest and slowest, but IaC cuts it to an hour or two) → Pilot Light (data only, app off, unvalidated-path risk) → Warm Standby (scaled-down copy always on, path validated) → Active-Active (full capacity in both, RTO 0 but expensive, with conflicts and the "survive with all traffic when half dies" capacity planning requirement). Third, AWS Backup unifies backups through tag-based policy governance, and Cross-Region/Account Copy defends against both disaster and account compromise. Fourth, Vault Lock Compliance Mode's WORM-immutable backups are the last line of defense against ransomware's "delete the backups first" tactic (the Colonial Pipeline lesson), and DR activation must be codified with Step Functions/SSM Runbooks and verified through regular drills.