RPO and RTO on AWS: how to define them without guessing
When you ask how much data loss a business can tolerate, the first answer is almost always “none.” Once you show what that answer costs, a second, much more nuanced one shows up. This article explains how to get straight to the second: what RPO and RTO mean, how to derive them from your operation instead of making them up, and which AWS architecture each level requires.
The two questions behind the acronyms
They are two different measures and get confused constantly. One is about data, the other about time.
RPO — Recovery Point Objective
How much data can you afford to lose? It is measured backward from the incident. An RPO of 4 hours means that, in the worst case, you lose the last 4 hours of work.
RTO — Recovery Time Objective
How long can the service stay down? It is measured forward. An RTO of 2 hours means you must be back in operation within 2 hours of the incident.
They can combine in ways that look contradictory and are not. An accounting system might tolerate being down an entire afternoon (high RTO) but not lose a single entry (RPO near zero). A content platform can be the opposite: it has to stay up all the time, but losing the latest comments is not a big deal.
The most expensive mistake: confusing backup with recovery
Having backups configured and having recovery capability are not the same thing, and the difference only surfaces on the day of the incident.
A backup answers “does a copy exist?” Recovery answers “how long until I am operating again with that copy?” Between the two sits a whole chain of things that can fail:
- The snapshot exists, but nobody documented the order in which the dependent services need to start.
- The database restores fine, but the application points to an endpoint that no longer exists.
- The copy lives in the same region that went down.
- Whoever knew the procedure no longer works at the company.
- The restore works, but it takes six hours and the committed RTO was one.
That is why an RPO and RTO are only real once they have been tested end to end. A target that has never been executed start to finish is an intention, not a commitment.
How to derive your numbers from the business
They are not picked in a technical meeting. They are calculated by asking four things to whoever knows the operation, system by system — because not every system deserves the same level.
1. What stops being possible if this system is down?
Billing, shipping, treating patients, teaching a class. If the answer is “nothing urgent,” you already know it does not need the most expensive level.
2. What does every hour without that system cost?
Add up unbilled revenue, idle staff, contractual penalties, and the cost of redoing the work manually. That number is the ceiling of what it makes sense to invest in avoiding it.
3. Can what was lost be rebuilt from another source?
If the transactions also live in the customer's email or a bank's system, your real RPO is looser than it looks. If the data only lives there, there is no margin.
4. Is anything forcing your hand from outside?
An SLA contract, an industry requirement, or a demand from your own client can set the number for you, non-negotiably.
The four recovery patterns on AWS
AWS organizes recovery strategies into four patterns. Each one reaches a different range of RPO and RTO, and costs proportionally. The choice is not which one is best, but which one matches the numbers you worked out above.
| Pattern | RPO | RTO | Cost |
|---|---|---|---|
| Backup and restore | Hours | Hours to days | The lowest |
| Pilot light | Minutes | Tens of minutes | Low |
| Warm standby | Seconds | Minutes | Medium to high |
| Multi-site active-active | Near zero | Near zero | The highest |
Backup and restore
Periodic copies with AWS Backup to S3, and manual restore when needed. Nothing runs at the backup site.
When it applies: Internal systems, development environments, or workloads where losing half a day of work is annoying but not critical.
Pilot light
Data replicates continuously, but compute stays off. On an incident, instances are turned on and scaled up.
When it applies: The operation can pause for a while, but losing transactions is not acceptable.
Warm standby
A scaled-down copy of the environment runs permanently and serves a fraction of the traffic. On a failure, it scales up and takes everything.
When it applies: E-commerce, platforms with concurrent users, systems that bill while they are up.
Multi-site active-active
Two regions serve traffic at the same time. If one goes down, the other absorbs it with no intervention.
When it applies: Financial services, critical healthcare, or when the cost of a minute of downtime clearly exceeds that of duplicated infrastructure.
What AWS gives you out of the box, and what you have to build
A good chunk of the work is already solved by managed services. It is worth knowing what RPO each one reaches before designing something by hand.
- RDS with point-in-time recovery: lets you go back to any second within the configured retention period. It is one of the cheapest ways to lower RPO.
- RDS Multi-AZ: synchronous replica in another availability zone with automatic failover. Covers the loss of one zone, not a full region.
- S3 with cross-region replication: copies objects to another region asynchronously. It is the foundation for a viable multi-region plan.
- AWS Backup: centralizes copy and retention policies across several services in one place, instead of scattered rules per resource.
- Infrastructure as code: what usually stretches out RTO is not restoring the data, it is rebuilding the environment. Describing infrastructure in code turns hours of manual work into a single execution.
Testing it, the part almost nobody does
A recovery plan that has never been rehearsed is a hypothesis. The test does not have to be dramatic: pick a system, define the scenario, and run the procedure with a stopwatch.
Measure the real time, not the estimated one
From the moment the incident is declared until the service is serving users again. Include the time spent deciding, finding the document, and someone picking up the phone — in a real incident, those count too.
Have someone who did not write it run it
If the procedure only works with the person who wrote it, it is not a procedure: it is knowledge trapped in one head, which is exactly the dependency a recovery plan should eliminate.
Write down the gap and adjust
If the committed RTO was 2 hours and the test took 5, there are two honest paths: invest to lower it, or correct the commitment. Writing it down as if nothing happened is the only bad option.
Where to start if you have nothing today
You do not have to solve everything at once. The order that creates the least friction is this:
- List your systems and rank them by the cost of each hour without them.
- Assign RPO and RTO only to the top three. The rest can wait.
- Check what pattern your current setup already covers — you are often already in “backup and restore” without having decided to be.
- Run a real test on the most critical system and measure the time.
- Only then decide whether to move up a pattern, with a measured number instead of a hunch.
If you want to know what RPO and RTO your current AWS setup actually allows — before committing to a number in front of a client — we can review it.
Request a resilience review