When a company designs its continuity plan, the conversation tends to jump straight to technology: what to replicate, which region to use, which tool to buy. That is the wrong order. Every continuity and disaster recovery plan rests on two numbers the business defines: RTO and RPO. Without those two values, any architecture decision is a gamble.
This article explains what they are, how they differ, and how they are set — in business language, because they are a business decision before a technical one.
What is RTO?
RTO (Recovery Time Objective) is the maximum acceptable time between the interruption of a service and its restoration. It answers a direct question: how long can we be down before the damage is unacceptable?
If your sales platform’s RTO is one hour, it means that, whatever happens, the business needs that service back in under sixty minutes. That objective drives everything else: the architecture, the level of recovery automation, and the budget that sustains it.
RTO is not a technical aspiration; it is a tolerance limit. The shorter it is, the more ready-to-go infrastructure and automation you need to meet it — and the more it costs to maintain.
What is RPO?
RPO (Recovery Point Objective) is the maximum amount of data the business can afford to lose, measured in time. It answers a different question: if we have to recover, how far back do we have to go?
An RPO of five minutes means that, after an incident, in the worst case the last five minutes of transactions are lost. To meet it, data must be copied or replicated at least that often. An RPO of twenty-four hours — a daily backup — is far cheaper to sustain, but it means accepting that a disaster can erase a full day of operations.
RPO turns an uncomfortable question into a concrete number: how much data are we willing to lose? The honest answer is almost never “none,” because the cost of a zero RPO is enormous. The right answer is the one that balances the value of that data against what it costs to protect it.
RTO and RPO: the difference that matters
It is the most common confusion. Both are recovery objectives, but they measure different things:
| Aspect | RTO | RPO |
|---|---|---|
| What it measures | Downtime | Data loss |
| Question it answers | How long can we be down? | How much data can we lose? |
| Expressed in | Time to restore the service | Time of data “backward” |
| What lowers it | Ready infrastructure and failover automation | More frequent data replication |
| Example | ”The core must return in 15 minutes" | "We cannot lose more than 1 minute of transactions” |
A single system can have a generous RTO and a demanding RPO, or the reverse. An analytical data store may tolerate being down for half a day (high RTO) but cannot lose accounting records (low RPO). An institutional website may tolerate losing its latest changes (high RPO) but needs to be back online fast (low RTO). Separating them is what lets you protect each thing for what it is really worth.
The business defines the numbers, not IT
The most expensive underlying mistake is treating RTO and RPO as technical parameters. They are not: they come from the cost the business incurs for each hour of downtime and each lost record.
That cost includes revenue that stops coming in, contractual penalties, reputational impact, and, in regulated sectors, exposure to the supervisor. It is a conversation for leadership, risk, and finance — IT later translates it into architecture, but does not originate it.
Hence a practical rule: define RTO and RPO per workload, not for the whole company. Classifying systems by criticality and assigning each group the objectives its value justifies avoids the twin error of over-protecting what does not need it and under-protecting what sustains the business.
A concrete example
A consumer-goods company with digital operations might classify its workloads like this:
- Sales and payments channel: every minute down is lost sales and frustrated customers. RTO in minutes, RPO close to zero. It justifies a robust, higher-cost recovery architecture.
- Back-office systems (billing, inventory): they tolerate a brief interruption but cannot lose records. RTO in tens of minutes, low RPO.
- Internal reporting and analytics: they can wait; their downtime does not stop operations or sales. RTO in hours, RPO in hours. A backup-and-restore scheme is enough.
Three business profiles, three RTO/RPO pairs, three strategies. Forcing them all to the sales-channel standard would inflate cost without adding value; forcing them to the reporting standard would put operations at risk. The discipline is in assigning each workload what it deserves.
Common mistakes when defining RTO and RPO
- Asking for “zero and zero” by default. Zero RTO and zero RPO are technically possible, but their cost is rarely justified outside the most critical workloads. The useful question is not “do we want to lose data?” but “what is it worth to avoid losing it?”.
- Defining them once and filing them away. Each system’s value changes with the business. Recovery objectives are reviewed periodically, not set forever.
- Confusing having backups with having a plan. A backup protects data (it helps RPO), but it does not guarantee RTO: without infrastructure to restore into and a tested procedure, getting back to operations can take far longer than tolerable.
- Not testing recovery. An RTO and an RPO in a document are a promise; only a real drill proves the architecture actually meets them.
From the numbers to the strategy
Once the RTO and RPO of each workload are set, the next question is which architecture meets them at the lowest cost. AWS defines four official recovery strategies — backup & restore, pilot light, warm standby, and multi-site active-active — ordered precisely by the RTO and RPO they achieve and by their relative cost.
The detail on how to choose between them is in our decision guide: disaster recovery on AWS: how to choose among the 4 official strategies. And when the RTO/RPO demand leads to operating in more than one region, that parity is designed and sustained with multi-region architecture and infrastructure as code.
How to get started
The first step is not buying technology: it is knowing what RTO and RPO your architecture can meet today, and how far that is from what the business needs. A Well-Architected review on the reliability pillar delivers exactly that diagnosis: the prioritized risks and the gap between the written plan and the real capability.
At Caleidos we help translate the value of each system into concrete recovery objectives, and build the architecture that meets them on AWS. Let’s talk about your business continuity and we will tell you, with evidence, what RTO and RPO your current operation can meet.
