Based on the SAP-C02 exam guideReport an error
If you understand DR (Disaster Recovery) as "taking backups," that is SAA level. At the Pro level, the business defines the RTO (Recovery Time Objective) and the RPO (Recovery Point Objective, the tolerable window of data loss), and you must design a cost-effective DR strategy that fits those numbers. For this, AWS provides 4 strategies (Backup/Restore, Pilot Light, Warm Standby, Multi-Site) and automated verification tools (Resilience Hub, FIS, DRS, Route 53 ARC). Today we pull together all of the DR we saw in Week 14 into one scenario.
| Strategy | RTO | RPO | Cost | Suitable workloads |
|---|---|---|---|---|
| Backup & Restore | Hours to days | Hours | ★ (cheapest) | Non-critical systems, dev/staging |
| Pilot Light | 10 minutes to 1 hour | Minutes | ★★ | Medium importance |
| Warm Standby | Minutes to 30 minutes | Seconds to minutes | ★★★ | Mission-critical |
| Multi-Site Active-Active | 0 to seconds | 0 to seconds | ★★★★ (most expensive) | Finance, payments, game matchmaking |
The 4 strategies are in essence a spectrum of "how many resources you keep running in the DR environment during normal times." Backup/Restore keeps 0% running, Multi-Site keeps 100% running. Pilot Light keeps only the DB running and leaves the app off (started on failover), and Warm Standby is always running at reduced capacity (scaled up on failover). Cost is proportional to capacity, and RTO is inversely proportional to capacity.
Gartner's RTO/RPO matrix is a deliverable of Business Impact Analysis (BIA). The difference between an RTO of 1 minute and 1 hour can cost tens of times more, so a reasonable design is possible only if the business units state "the loss per minute of downtime." AWS includes this in the Reliability Pillar questions of the WA Tool, having you state it when you register a workload. The terms RTO/RPO themselves are standards formally defined in ISO 22301 (business continuity) and NIST SP 800-34 (contingency planning guide).
(Hypothetical case) A small SaaS runs production in us-east-1 and sends only backups to us-west-2 S3 with CRR (Cross-Region Replication). On a Region failure, it recreates the infrastructure in us-west-2 with CloudFormation → a 6-hour RTO. The business SLA is 24 hours, so that is sufficient. The legitimacy of this pattern was proven by the major 2017 S3 us-east-1 outage (4 hours): had the backups been in the same Region only, they would have disappeared along with that Region's failure. Backups must always be isolated in a different Region and account.
🎯 Scenario: "A global payments company promises a 99.99% SLA (52 minutes of downtime per year). What is the DR strategy?" The answer: Multi-Site Active-Active + Aurora Global + DDB Global + Route 53 ARC Routing Control. A four-nines SLA is virtually impossible with anything other than Multi-Site. The cost is double, but 1 minute of downtime = a loss of tens of millions of won, so it is justified.
⚠️ Pitfall: "A shorter RTO is always better" is a trap. Pro-level thinking is to choose the cheapest strategy that meets the business RTO/RPO. If the SLA is 24 hours and you choose Multi-Site, that is over-engineering that wastes double the cost on an RTO you do not need to meet. In the exam, when "cost-effective + meets the RTO" appear together, you must choose the lowest-cost strategy that satisfies the RTO.
| Mode | Can it be changed? | Use |
|---|---|---|
| Governance | Yes, with IAM permission | General use, preventing mistakes |
| Compliance | Not with any permission | Regulation (7-year retention) |
Once Compliance mode is enabled, even the AWS headquarters root user cannot change it. It legally guarantees that backups are never permanently deleted or altered. It satisfies WORM (Write Once Read Many) requirements such as the financial industry's SEC Rule 17a-4 and FINRA 4511. It has the same philosophy as S3 Object Lock Compliance mode.
In the 2021 Colonial Pipeline ransomware incident, the company paid a ransom of about 4.4 million dollars. If all of its backups had been isolated in a separate account on immutable storage (Compliance Lock), recovery would have been possible without paying the ransom. After this incident, immutable backup was elevated from "nice to have" to "essential in the age of ransomware." When a healthcare company keeps patient backups for 7 years for HIPAA compliance, it also blocks both intentional and accidental deletion with a Backup Vault Compliance Lock + Cross-Region Copy, and proves compliance to the auditor with a printout of the policy.
Chaos Engineering is a paradigm Netflix introduced in 2010. Under the assumption that "production is always partially broken," it regularly injects deliberate failures to verify that the system degrades gracefully. AWS turned it into a managed service as FIS in 2021. The Stop Condition is the key differentiator: it provides an automatic safety stop (fail-safe) so that a deliberate failure does not spill over into a real incident. After the major Netflix outage on Christmas Eve 2012 (a us-east-1 ELB failure), Netflix even built "Chaos Kong," which kills an entire Region, and verified regularly: failover works in a real crisis only as well as you practiced it in normal times.
| Service | Purpose | Behavior |
|---|---|---|
| MGN | One-time migration | Ends after moving from on-premises → AWS |
| DRS | Continuous DR | Continuously replicates from on-premises/other clouds → AWS |
🎯 Scenario: "Permanently move 100 on-premises VMs to AWS (Rehost of the 7 Rs)." → MGN. "Keep the on-premises VMs as they are while maintaining a 24-hour DR environment on AWS." → DRS. The two branched off the same replication engine (formerly CloudEndure), but their purposes are the exact opposite.
During the major AWS us-east-1 outage on December 7, 2021 (about 7 hours), some companies suffered from automatic health checks flipping between healthy and unhealthy, making traffic jump around unstably. The data plane of ARC Routing Control is distributed across 5 Regions and works even if us-east-1 dies, so an operator can explicitly decide "switch to us-west-2 now." This outage left the lesson to design so that "even if the control plane dies, the data plane survives."
| Mode | Failover | Replica use |
|---|---|---|
| Multi-AZ Instance | 60-120 seconds | The replica is a standby and cannot take traffic |
| Multi-AZ Cluster | 35 seconds | Read traffic is possible on the 2 replicas |
Multi-AZ Cluster launched in 2022. Where the old Multi-AZ Instance was "1 primary + 1 standby (cannot take traffic)," the Cluster evolved into "1 primary + 2 readable replicas." With semi-synchronous replication, the primary sends the commit ack after confirming that data has reached 1 of the 2 replicas (a quorum) → a lower risk of data loss than asynchronous replication, and faster than fully synchronous.
⚠️ Pitfall: Aurora Global secondaries are read-only, but DDB Global Tables accept writes in every Region. When you see the keyword "writes in both Regions," think DDB Global Tables, or Aurora Global's write forwarding (automatically forwards writes to the primary Region, at the cost of latency). DDB's Last Writer Wins has the limitation that on concurrent writes one side silently disappears (a lost update), so the best practice is to design the write keys partitioned by Region.
Every choice in data-layer DR ultimately reduces to the latency-consistency trade-off of the PACELC theorem (an extension of CAP). Between AZs the distance is several km (1-2 ms), so synchronous replication (RPO 0) is possible, but between Regions it is thousands of km (40 ms+), so it is almost always asynchronous (RPO > 0). If "RPO 0 across Regions" is required, suspect either a large latency cost or impossibility.
| Keyword | Answer |
|---|---|
| "RPO 0 + Active-Active writes in both Regions" | DDB Global Tables |
| "Global SQL DB + RPO of 1 second" | Aurora Global |
| "RDS failover 30 seconds" | Multi-AZ Cluster |
| "Permanent on-premises → AWS move" | MGN |
| "On-premises + continuous DR on AWS" | DRS |
| "S3 multi-Region single endpoint" | MRAP |
| "Backups immutable for 7 years (even for root)" | Backup Vault Compliance Lock |
| "Deliberate failure in operation + automatic stop" | FIS + Stop Condition |
| "Automatic DR gap identification + recommendations" | Resilience Hub |
| "Remove only an AZ from traffic immediately" | Route 53 ARC Zonal Shift |
| "A person explicitly decides the failover" | Route 53 ARC Routing Control |
| "Automatic evaluation of backup policy compliance" | Backup Audit Manager |
| "Meets RTO + minimum cost" | The lowest-cost strategy that meets it |
DR is a workflow of defining the business RTO/RPO → choosing among the 4 strategies → automating verification. Cost, RTO, and RPO trade off against one another, so you must not blindly choose Multi-Site; you must set the appropriate level with a business impact analysis. Combining AWS Backup, Resilience Hub, FIS, DRS, and Route 53 ARC to automate the whole lifecycle of "define → implement → verify" is Pro-level design.
Next week (Week 15) is the integrated scenarios. We will work through integrated cases for each industry: large enterprise, startup, finance, media, and government/healthcare.
Click a choice to reveal the answer and explanation.
Question 1
You need an RTO of 5 minutes, an RPO of 1 second, and a global SQL DB.
Question 2
"Deliberate failure injection in operation + automatic stop on an alarm."
Question 3
Regulatory requirement: retain backups for 7 years + immediately immutable against change or deletion (even for AWS root).
Question 4
A global DB that accepts writes in both Regions.
Question 5
Immediately remove only the AZ that has a problem from traffic.
Question 6
Maintain a 24-hour DR environment on AWS for 200 on-premises VMs.
Question 7
Achieve RDS failover within 30 seconds and also spread read traffic to the standby.
Question 8
Automatically identify DR gaps, get concrete improvement recommendations, and integrate them into CI/CD.
Question 9
Expose multi-Region S3 buckets as a single global endpoint.
Question 10
A person explicitly makes the decision and triggers the failover (avoiding false positives from automatic health checks).
Question 11
A company wants to design DR for a staging environment with a 24-hour RTO SLA at minimum cost. Which strategy is the most suitable?
Question 12
A company wants to protect its backups so that they remain recoverable even if the workload account is taken over by ransomware. What is the most robust configuration?