Your RTO and RPO are guesses until someone outside your team has restored from them

Written by Formiga, an independent AWS consultancy. This page contains no product, nothing to buy on it, and no capability claim about any tool. It is the checklist we use ourselves.

1. The two numbers, and the thing most documents get wrong about them

RTO (recovery time objective) is how long the workload may be down. RPO (recovery point objective) is how much data you may lose, measured in time. Both are usually written as targets during a compliance exercise, agreed in a meeting, and then never exercised.

An RTO that has never been measured is not an objective. It is an estimate of an operation nobody has performed. The distinction matters because the failure mode is asymmetric: an untested RTO is discovered to be wrong at exactly the moment it is being relied on.

2. AWS publishes four strategies, and they are the honest vocabulary

AWS's own disaster-recovery whitepaper categorises recovery in the cloud into four approaches, which it describes as "ranging from the low cost and low complexity of making backups to more complex strategies using multiple active Regions":

The first three are active/passive: an active site serves traffic and a passive site exists for recovery. Naming which of the four you are actually running is the cheapest clarifying step available, because a document that says "we replicate to another Region" describes at least three of them and commits to none.

Source: AWS, Disaster Recovery of Workloads on AWS: Recovery in the Cloud, "Disaster recovery options in the cloud". Read at source 2026-08-21. We do not quote RTO or RPO figures from it, because the published guidance deliberately does not attach fixed numbers to the four strategies — your numbers come from your estate, not from a table.

3. Seven things that make a written RTO false without anyone noticing

These are the divergences we find most often between a DR document and the estate it describes. None of them require an outage to detect. All of them require someone to go and look.

  1. The backup exists and the restore path does not. Snapshots are verified as present. Presence is not restorability, and the two are checked by different operations.
  2. The recovery Region is missing a dependency the primary acquired later. A parameter, a secret, a certificate, an image, a quota. DR configuration is written once; estates keep changing.
  3. Service quotas in the recovery Region are the defaults. Quotas are per-Region. A failover that needs to launch at production scale into default limits fails at the worst moment, and it fails quietly at first.
  4. The RPO is stated per workload but the data has more than one store. A database replicating continuously and an object store syncing nightly do not share an RPO. The true RPO is the worst one, not the headline one.
  5. DNS or certificate TTLs are longer than the RTO. If the plan is to repoint traffic, the repointing time is part of the recovery time, and it is frequently larger than the compute recovery it is added to.
  6. The runbook names people rather than roles, and assumes access that only those people hold. Test the runbook with whoever is actually on call.
  7. Nobody has timed it. If there is no recorded duration from a real restore, the RTO in the document is a target, not a measurement, and it should be labelled as one.

4. Why the test has to be run by someone outside the team that built it

This is the part that is uncomfortable and it is the whole reason this page exists.

The engineer who designed the recovery path is the worst available person to validate it, not because of competence but because of information. They know which console to open, which parameter is actually required, which step is skippable and which alarm is noise. That knowledge is exactly what a real incident does not guarantee will be present — it may be on holiday, or have left, or be the person the incident woke at 04:00.

A restore performed by someone with only the runbook and standing access measures the artifact you actually own. A restore performed by its author measures the author. If the two produce different times, the difference is your real risk, and it is invisible to every internal exercise.

5. The smallest honest exercise

You do not need a full failover to stop guessing. In ascending order of cost:

  1. Restore one production-representative database into an isolated account. Record the wall-clock duration. That number is a floor, not the RTO, and a floor is already more than most documents have.
  2. Have someone who did not write the runbook follow it, unaided, and write down every point where they had to ask. Each question is a gap in the artifact.
  3. Compare the timestamp of the newest restored record against the moment you took the copy. That interval is your measured RPO for that store.
  4. Repeat for the store with the weakest replication, not the strongest.

Write the measured numbers next to the target numbers in the same document. Where they disagree, the measured one is the true one, and saying so in writing is worth more than closing the gap quietly.

What this page does not claim

It does not claim your estate has any of these problems — we have not seen it. It quotes no RTO or RPO figures from AWS, because AWS does not publish fixed figures for the four strategies. It is not legal, audit or compliance advice, and it is not a statement about what any specific certification or regulation requires of you; confirm those with your auditor. The four strategy names are AWS's, read at source on the date given above; everything else on this page is our own operational opinion, offered as opinion.

If you want the outside-team restore run against your estate, that is the work we do: what we do and what it costs. There is a form on the front page and a person reads it. Related: four AWS line items that look like waste and are usually a decision — one of which is the meter on the multi-AZ resilience this page is about.