Based on the SAP-C02 exam guideReport an error
On August 14, 2003, the Northeast Blackout struck the northeastern US and Canada, leaving 50 million people without power. Many companies depending solely on their own datacenters stopped operations—but financial institutions with geographically distant DR sites survived. This event embedded "DR is not IT's insurance but the core of Business Continuity" across the industry. Twenty years later, AWS commoditized DR by replacing what would cost hundreds of millions in on-premises building a second datacenter with a few API calls.
In SAP-C02 exams, understanding DR as "turning on backups" stays at SAA level. Pro's core is the decision-making skill: choosing a strategy that precisely meets RTO (Recovery Time Objective) and RPO (Recovery Point Objective)—two numbers defined by business—while minimizing cost. Today we decompose why the four DR strategies organize into this spectrum, how sync/async replication obeys physical law, and how cloud inverted DR's economics.
DR design starts with two time metrics. RTO (Recovery Time Objective) is "maximum time allowed from failure to service recovery," and RPO (Recovery Point Objective) is "time span of data loss tolerable during failure." RTO points to the future after failure on the timeline, while RPO points to the past before failure. RTO 1 hour + RPO 5 minutes means "recover within 1 hour, but up to 5 minutes of data loss is acceptable."
These two numbers aren't set arbitrarily by IT but are outputs of BIA (Business Impact Analysis). Only when business specifies "loss per minute of downtime," can you justify spending 10x more to achieve RTO of 1 minute instead of 10 minutes.
💡 Related Theory: RTO/RPO are formally defined in ISO 22301 (Business Continuity Management System standard). ISO 22301 mandates deriving MTPD (Maximum Tolerable Period of Disruption) through BIA, then setting RTO within it. NIST SP 800-34 (Federal IT Emergency Planning Guide) uses the same RTO/RPO/WRT framework. WA Framework's Reliability pillar question (REL13: "how do you plan disaster recovery?") borrows these standard terms. In exams, "data loss business tolerates" immediately maps to RPO; "service recovery time" maps to RTO.
🔍 Deeper Dive: RTO and RPO are independent. A system can have RPO≈0 (can't lose any transaction) but RTO of hours (okay to recover slowly)—e.g., nighttime batch accounting settlement must preserve every trade (RPO≈0) but only needs recovery by next business morning (RTO hours). Conversely, catalog reads prioritize RTO≈0 (must be instant) but tolerate RPO of minutes (re-sync price changes). Exams separate these two numbers to create traps. When "RPO 0" appears, think sync replication or Active-Active; when "RTO hours allowed," think cost-saving room (Backup & Restore).
The 2021 AWS DR whitepaper organizes DR into four tiers. The essence is simple: how much infrastructure does the DR region keep running normally? The percentage (0% to 100%) determines both cost and RTO simultaneously.
| Strategy | RTO | RPO | Cost | DR Region State | Suitable Workloads |
|---|---|---|---|---|---|
| Backup & Restore | Hours to days | Hours | ★ | 0%(data only) | Dev, staging, non-critical |
| Pilot Light | 10 min–hours | Minutes | ★★ | DB only active, apps cold | Medium importance |
| Warm Standby | Minutes–30 min | Seconds–minutes | ★★★ | Scaled-down full stack always running | Mission-critical |
| Multi-Site Active-Active | 0–seconds | 0–seconds | ★★★★ | 100%, both process traffic | Finance, payments, gaming |
🔍 Deeper Dive: Don't memorize the four—understand this one sentence: "capacity and RTO are inversely proportional; capacity and cost are proportional." Backup & Restore keeps 0% compute in DR region, cheapest but RTO longest (infrastructure built from scratch). Multi-Site runs 100%, cost nearly 2x but RTO approaches 0 (traffic already flowing). The critical difference between Pilot Light and Warm Standby is "whether app servers run"—Pilot Light keeps only DB hot, apps cold (AMI prepared); Warm Standby keeps a reduced app stack always up. Warm Standby only "scales out," but Pilot Light must "start apps," yielding longer RTO.
Regular snapshots (EBS, RDS) and S3 Cross-Region Replication send only data to the DR region; on failure, rebuild entire infrastructure via IaC (CloudFormation, Terraform). Cost is essentially storage only, but infrastructure provisioning plus data recovery takes hours.
📚 Case Study: The February 28, 2017 AWS S3 us-east-1 massive outage (4 hours) started when an engineer mistyped a command, causing mass removal of S3 billing subsystem servers. Countless services (Trello, Quora, Slack partial) depending solely on single-region S3 backup went down simultaneously. Lesson is clear: backups must be isolated to different regions (or accounts). Same-region backup disappears with the region. In exams, "guard against region-wide failure" signals Cross-Region requirement.
Named after airplane pilot light—a small flame keeping the engine ready. DR region keeps DB (Aurora Global Reader, DDB Global Table) always on continuously replicating data, but app servers exist only as AMI/Launch Template (not running). On failure, raise ASG min capacity to start apps and Route 53 switches traffic.
DR region runs the entire stack at reduced capacity always. App servers already run, so on failure, scale out ASG to production level—RTO is just the scaling time.
Both regions process production traffic. Aurora Global (write forwarding) or DDB Global Tables keep data bidirectional sync, Route 53 Latency/Weighted or Global Accelerator distributes traffic. One region dies, the other already processes traffic—RTO approaches 0. Trade-off: data consistency design complexity (conflict resolution) and nearly 2x cost.
🎯 Scenario: "A global payment company promises 99.99% SLA (annual downtime ~53 minutes). What DR strategy?" — Answer: Multi-Site Active-Active + Aurora Global (or DDB Global) + Route 53. 4 nines leave only ~53 minutes annual downtime, so Pilot Light or Warm Standby needing minutes to tens of minutes recovery is practically impossible. 2x cost justified since payment minute-downtime loss exceeds it. In exams, "99.99%+ SLA + global" signals Multi-Site.
DR strategy RPO ultimately depends on data replication method. Replication method is bound by the physics of light speed.
Synchronous replication waits until write reaches primary and all copies, receives confirmation (ack), then returns success to client. RPO becomes 0 but round-trip latency (RTT) to copies adds to every write. Asynchronous replication returns success immediately after primary write, sending copies later. Writes are fast but if primary dies, unsent data is lost—RPO > 0.
The key is distance. us-east-1 (Virginia) and us-west-2 (Oregon) are ~4,000km apart; light round-trip through fiber takes physically ~40ms alone. Sync replication across regions adds this 40ms to every write, collapsing throughput. Therefore sync replication is only practical across AZs (few km, 1-2ms latency); cross-region is almost always async.
💡 Related Theory: This is the physical root of CAP Theorem and PACELC trade-offs. CAP says "during partition (P), choose Consistency (C) or Availability (A)." PACELC goes further: "even without partition (Else), choose between Latency (L) and Consistency (C)." Cross-region sync replication chooses strong Consistency (C), tolerating Latency (L). Async trades latency for Consistency (eventual). Aurora uses cross-region async (storage-level) and within-region sync specifically because of this latency-consistency balance. In exams, "cross-region RPO 0" is nearly impossible or hides massive latency cost.
⚠️ Pitfall: Don't memorize "RPO 0 = always sync replication." DDB Global Tables are async Active-Active but operationally RPO approaches 0—all regions accept writes, so one region dying means data already written elsewhere. Aurora Global's secondary is read-only (single-region writes), RPO usually sub-1-second (not zero). In exams, "RPO 0 + dual-region writes" is DDB Global Tables; "RPO 1 second + global SQL" is Aurora Global.
On-premises, DR meant building a second datacenter. It buried hundreds of millions in "insurance" on buildings, servers, cooling, staff that never saw production traffic—only large enterprises and finance could afford genuine DR. Cloud fundamentally changed this.
| Aspect | On-Premises DR | Cloud DR |
|---|---|---|
| Initial Investment | Build second datacenter (CAPEX) | Zero (provision when needed) |
| Idle Cost | 100% resource cost always | Pilot Light only DB cost |
| DR Testing | Can't validate without real failure | FIS, Game Days regularly |
| Scaling | Limited to pre-purchased capacity | Auto Scaling unlimited on failure |
| Shorten RTO | Buy more hardware | Change to Warm/Multi-Site (config) |
The core: "Stop guessing capacity" (WA general principle) shines brightest in DR. On-premises had to pre-buy entire production capacity for DR region, but cloud runs Pilot Light—DB on, apps off—then Auto Scales explosively only on failure—near-zero idle cost while meeting RTO.
🔍 Deeper Dive: This economic shift enables cloud DR to recycle DR sites as cost-saving opportunity. E.g., Warm Standby's reduced DR stack normally runs batch/analytics, or Multi-Site's dual regions via Latency Routing serve users from the nearer region simultaneously achieving DR and performance optimization. Impossible on-premises: "dual-use of DR resources." In exams, "use DR region normally for cost efficiency" signals Active-Active.
DR's final puzzle: "detect failure and route traffic to DR." AWS standard is Route 53 Failover Routing + Health Check. Attach Health Check to primary record; when unhealthy, DNS automatically switches to Secondary (DR).
⚠️ Pitfall: DNS Failover has hidden TTL delay trap. Even if Route 53 changes record, clients and intermediate resolvers cache the old IP for TTL duration—switching isn't instant. RTO requiring seconds needs more than DNS Failover alone; Global Accelerator (anycast IP, fixed endpoint bypassing DNS cache) or Active-Active needed. In exams, "RTO 0–seconds + bypass DNS cache" signals Global Accelerator; "RTO minutes acceptable" signals Route 53 Failover.
DR is business defines RTO/RPO → choose one of four strategies meeting both at lowest cost → implement via Route 53 and replication. Four strategies (Backup & Restore, Pilot Light, Warm Standby, Multi-Site) spectrum is "how much infrastructure stays on"; capacity and RTO inversely proportional, cost proportional. RPO determined by sync (within-AZ, RPO 0) or async (cross-region, RPO>0) replication, rooted in light-speed physics and CAP/PACELC.
SAP exam frequent mappings: (1) "RTO 24hrs, minimize cost" → Backup & Restore, (2) "DB always replicate, apps stopped" → Pilot Light, (3) "Reduced stack always, minutes RTO" → Warm Standby, (4) "99.99% SLA, dual-region traffic" → Multi-Site Active-Active, (5) "RPO 0 + dual-region writes" → DDB Global Tables, (6) "Global SQL, RPO 1 second" → Aurora Global, (7) "Auto-switch DR traffic" → Route 53 Failover + Health Check, (8) "RTO seconds, bypass DNS cache" → Global Accelerator. Next day digs into backup infrastructure (AWS Backup, Vault Lock, Cross-Region Copy) to tool level.
Click a choice to reveal the answer and explanation.
Question 1
A development team is designing DR for a staging environment. The business SLA is very lenient, with an RTO of 24 hours and an RPO of 12 hours, and the team has been told to minimize cost. What is the most appropriate strategy?
Question 2
A company tried to set up synchronous cross-Region replication (RPO 0) for a database between the DR Region us-west-2 and the production Region us-east-1, and write throughput dropped sharply. What is the most accurate cause?
Question 3
A media company wants to always run the same full stack as production in the DR Region at reduced capacity and recover within minutes by scaling out with Auto Scaling during a failure. What is this strategy?
Question 4
A global gaming company requires 99.99% availability and simultaneous writes in both Regions for its matchmaking service. What is the most appropriate DR and data configuration?
Question 5
A company configured DR failover with Route 53 Failover Routing, but during an actual failure some users still connected to the dead primary for several minutes. What is the most accurate cause and the solution that reduces RTO to seconds?
Question 6
To reduce cost, a company does not want to leave its DR Region idle during normal operation and wants to use it to serve user traffic as well. What is the most appropriate approach?
Question 7
What is the most accurate description of the relationship between RTO and RPO?