RTO vs RPO and the four AWS disaster recovery strategies

Every disaster recovery (DR) plan starts with two numbers, and AWS describes four ways to meet them. Exam questions give you the numbers and a budget, and ask which way fits. Once you know what each strategy keeps running before the disaster, picking one becomes straightforward.

Two numbers: RTO and RPO

• RTO, recovery time objective: how long the workload can be down. “We must be running again within 4 hours” is an RTO of 4 hours.
• RPO, recovery point objective: how much data you can afford to lose, measured in time. “We can lose at most 15 minutes of orders” is an RPO of 15 minutes.

A handy way to remember them: RTO looks forward from the disaster (time until you’re back), RPO looks backward (time since your last good copy of the data).

Both come from the business, not from IT. Smaller numbers cost more, so the right strategy is the cheapest one that still meets them.

High availability isn’t disaster recovery

Running across multiple Availability Zones (Multi-AZ) protects you from a data center failing. DR is about bigger events: a whole Region becoming unavailable, or data being deleted or corrupted. That’s why the strategies below involve another Region, and why backups still matter even with replication: replication faithfully copies a mistake too.

The four strategies

From cheapest and slowest to most expensive and fastest:

1. Backup and restore

Back up data (and keep the infrastructure as code) in the recovery Region. When disaster strikes, restore the data and rebuild everything.

• Running beforehand: nothing but backups.
• RPO and RTO: hours.
• Cost: lowest.
• On AWS: AWS Backup with cross-Region copies, S3 Cross-Region Replication, AMIs copied to the other Region, and CloudFormation or the AWS CDK to rebuild the infrastructure.

2. Pilot light

Keep the core running, usually the data, replicated live to the recovery Region, while the servers are defined but switched off (or scaled to zero). Like a gas heater’s pilot light: small, always on, ready to ignite the rest.

• Running beforehand: data stores, continuously replicated.
• RPO and RTO: tens of minutes, mostly the time to start and scale the servers.
• Cost: low.
• On AWS: database replication across Regions, such as an Aurora Global Database or a cross-Region read replica; AWS Elastic Disaster Recovery to keep servers replicated and ready to launch.

3. Warm standby

Run a scaled-down but fully working copy of production in the recovery Region. It can serve requests straight away; in a disaster you scale it up to full size.

• Running beforehand: everything, at reduced capacity.
• RPO and RTO: minutes.
• Cost: medium.
• The difference from pilot light: a warm standby can handle traffic immediately; a pilot light needs its servers started first.

4. Multi-site active-active

Run the full workload in two or more Regions at once, each serving real users. If one Region fails, the others carry on.

• Running beforehand: everything, at full capacity, everywhere.
• RPO and RTO: close to zero.
• Cost: highest, and the most complex, since data must stay in sync across Regions.
• On AWS: Route 53 to spread traffic and route around a failed Region (with health checks), and multi-Region data stores such as DynamoDB global tables or an Aurora Global Database.

Side by side

Making failover work

Whichever strategy you choose:

• Point traffic with DNS. Route 53 health checks and failover routing send users to the recovery Region when the primary stops answering.
• Raise service quotas in the recovery Region ahead of time, so you aren’t blocked from scaling up in the middle of an incident.
• Test it. A DR plan that has never been tried is a guess. Run failover drills and check that you actually meet your RTO and RPO.

Exam traps

• “RPO of 24 hours, RTO of 24 hours, lowest cost.” Backup and restore.
• “Core database must always be current in another Region; servers can be started when needed.” Pilot light.
• “Must serve traffic within minutes at reduced capacity, then scale up.” Warm standby.
• “Zero downtime, users in several Regions, cost is no concern.” Multi-site active-active.
• “How much data can we lose?” That’s the RPO. “How long can we be down?” That’s the RTO.
• “Multi-AZ is enough for DR.” Not for a Region-wide event: DR needs a second Region.
• “Replicate on-premises servers to AWS for fast recovery with minimal effort.” AWS Elastic Disaster Recovery.

For the full details, see the AWS whitepaper Disaster Recovery of Workloads on AWS, including its section on RTO and RPO, and the user guides for AWS Elastic Disaster Recovery, Aurora Global Database and S3 replication.