AWS disaster recovery strategies: RTO/RPO explained with a worked example
Most AWS SAA study guides list the same four disaster recovery strategies — backup and restore, pilot light, warm standby, multi-site active/active — and stop at a one-line description of each. The exam rarely tests the names; it tests whether you can take a business's stated RTO and RPO and work out which strategy is the cheapest one that actually meets it, or read a backup timeline and correctly compute what RTO and RPO happened. Below are both calculations worked through with real numbers, plus the mechanical distinction (pilot light vs. warm standby) that catches the most people out.
RTO and RPO, precisely
The AWS Well-Architected Framework's Reliability Pillar defines both terms exactly:
- Recovery Time Objective (RTO) — "the maximum acceptable delay between the interruption of service and restoration of service."
- Recovery Point Objective (RPO) — "the maximum acceptable amount of time since the last data recovery point."
RTO is about downtime. RPO is about data loss, measured backwards from the moment the interruption began. They are targets an organization sets, not measurements of what a particular AWS service happens to deliver — a strategy either can or can't meet the target you set it.
Worked example: reading RTO and RPO off a timeline
A workload takes an automated backup every 6 hours. The most recent one completes at 09:00. A Regional outage begins at 12:40. The team restores service from the 09:00 backup, and traffic resumes at 13:55. What are the actual RTO and RPO for this event?
| Step | Time | What it means |
|---|---|---|
| Last good recovery point | 09:00 | The most recent backup that can be restored from |
| Outage begins | 12:40 | Anything written after 09:00 and before this point is at risk |
| Service resumes | 13:55 | The workload is back and serving traffic |
RPO is the gap between the last recovery point and the outage: 09:00 to 12:40, so up to 3 hours 40 minutes of writes are gone once the team restores from the 09:00 backup — even though the backup itself finished hours before anything went wrong. RTO is the gap between the outage and restoration: 12:40 to 13:55, so 1 hour 15 minutes of downtime. Notice RPO isn't "how long since the backup ran" in isolation — it's bounded by how long the outage takes to start, which is why an unlucky outage timed right before the next scheduled backup produces the worst-case RPO a strategy can deliver.
The four strategies, compared
AWS's Disaster Recovery whitepaper describes these as ranging "from the low cost and low complexity of making backups to more complex strategies using multiple active Regions":
| Strategy | What's always running in the DR Region | What happens at failover | Relative cost |
|---|---|---|---|
| Backup and restore | Nothing — only stored backups (snapshots, AWS Backup, S3 replicas) | Redeploy infrastructure (ideally via IaC) and restore data from the backup | Lowest |
| Pilot light | Core data services only — databases and storage, continuously replicating | Deploy and "switch on" the application tier, then scale it out | Low–moderate |
| Warm standby | A scaled-down but fully functional, already-deployed copy of the whole stack | Scale the existing environment up to full capacity (e.g. raise Auto Scaling desired capacity) | Moderate–high |
| Multi-site active/active | A full production copy, actively serving live traffic already | Nothing to switch on — traffic is redirected away from the failed Region | Highest |
The whitepaper's own note on the two middle options is the single most exam-relevant sentence on this page: "pilot light cannot process requests without additional action taken first, whereas warm standby can handle traffic (at reduced capacity levels) immediately." Pilot light needs you to turn servers on and possibly deploy more infrastructure before it can serve a single request. Warm standby is already running — it just needs more of it.
Worked example: matching a target to the cheapest strategy that meets it
A compliance team sets a disaster recovery objective for a full Regional outage: RTO of 15 minutes, RPO of 5 minutes. Cost is a secondary concern, but they don't want to over-pay for headroom they don't need. Walking through each option in order of cost:
- Backup and restore fails both targets — infrastructure has to be redeployed from scratch and data restored from whatever backup last ran, which routinely takes hours, not minutes, on either axis.
- Pilot light can hit the 5-minute RPO, since its data services replicate continuously. It struggles with the 15-minute RTO: deploying and switching on an application tier that wasn't running a moment ago is exactly the kind of step that can land anywhere from tens of minutes to hours, not a number you can rely on.
- Warm standby meets both. The application tier is already deployed and already running at reduced capacity, so a failover is "redirect traffic, then scale up" rather than "deploy, then scale up" — the deployment step, which is what made pilot light unreliable, doesn't exist here.
- Multi-site active/active also meets both targets, comfortably, but at the highest cost of the four for no additional benefit once the 15-minute/5-minute bar is already cleared.
Warm standby is the answer: the cheapest strategy that reliably meets the stated objective. This is exactly the logic behind AWS's own framing — "use your RTO and RPO needs to help you choose between these approaches" — and it's the reasoning the exam is testing whenever a question states a specific RTO/RPO pair rather than just asking "which strategy is fastest."
Which AWS services implement each strategy
| Strategy | Typical services |
|---|---|
| Backup and restore | AWS Backup; EBS, RDS/Aurora, and DynamoDB snapshots; S3 Cross-Region Replication with versioning; CloudFormation/CDK to redeploy infrastructure |
| Pilot light | Aurora Global Database or DynamoDB global tables for continuous replication; AWS Elastic Disaster Recovery (which itself implements a pilot light pattern for server-hosted workloads); Route 53 or Application Recovery Controller for failover routing |
| Warm standby | Everything used for pilot light, plus EC2 Auto Scaling to raise desired capacity in the DR Region on failover |
| Multi-site active/active | Route 53 (geoproximity, weighted, or latency-based routing) or Global Accelerator traffic dials; Aurora Global Database or DynamoDB global tables configured for cross-Region writes |
The recurring theme across both worked examples: RPO is mostly a function of how your data replicates (periodic backup vs. continuous replication), and RTO is mostly a function of how much has to be provisioned or deployed from a cold start before traffic can flow again. Once you separate those two questions, matching a stated objective to a strategy — or reading RTO/RPO off a timeline — stops being a memorization exercise. To practice both patterns, try PassDrill's AWS SAA high availability & disaster recovery practice questions.
Source: AWS Well-Architected Framework, Reliability Pillar — Disaster Recovery (DR) objectives (RTO/RPO definitions); AWS Whitepapers, Disaster Recovery of Workloads on AWS: Recovery in the Cloud — Disaster recovery options in the cloud (the four strategies and their AWS services).