What RPO and RTO actually buy
Two numbers define a recovery capability, and NIST SP 800-34 gives them their standard definitions. The recovery point objective is how much data you can afford to lose, measured in time: an RPO of one hour means an event may destroy up to an hour of transactions. The recovery time objective is how long service may be unavailable before it is restored. They are independent — you can have a four-hour RTO with a one-minute RPO, or the reverse — and they are bought with different things.
RPO is bought with replication. Getting from a nightly backup to a one-hour recovery point means shipping changes continuously rather than in a batch, which costs transfer and a replication service. RTO is bought with standing capacity. Getting from a day to an hour means having compute already provisioned in the recovery region, and that capacity costs whether or not it is ever used.
Because they are bought separately but usually sold together, the industry has settled on four postures that combine them at sensible points. AWS names them backup and restore, pilot light, warm standby, and multi-site active/active, and this calculator prices all four. The capability figures attached to each — how much production capacity it keeps warm, and what RPO and RTO it can reach — come from that taxonomy.
The decision this calculator makes explicit is that a recovery posture has two costs, not one. There is the money you spend every month whether or not anything happens, and there is the money you lose when something does. Adding the second as an expected value — probability times consequence — puts both on the same annual footing, which is the only way to compare a posture that costs $1,000 a month and loses $888,000 per event against one that costs $42,000 a month and loses $6,450.
How each posture is priced
Running cost has three parts. Standing capacity is production monthly cost multiplied by the posture's capacity fraction: nothing for backup and restore, a tenth for pilot light, half for warm standby, a full copy for multi-site. Backup storage is paid by every posture, because even an active/active pair needs point-in-time backups to recover from a logical error that replicates perfectly to both sides. Replication is paid by every posture except backup and restore, which by definition ships nothing between backups.
Event cost has two parts, and they map one to one onto the two objectives. Data loss is the recovery point in hours multiplied by what an hour of transactions is worth to rebuild or write off. Outage loss is the recovery time in hours multiplied by the revenue the service carries per hour. Both scale linearly, which is why halving an objective halves that half of the loss but does nothing to the other half — a fact that decides which objective is worth tightening first.
Multiplying the per-event loss by the expected event rate converts a rare, large number into an annual one. Two events per decade is 0.2 events per year, so an $888,000 event contributes $177,600 a year of expected loss. That figure is not a prediction of what any single year will cost; it is the amount you would have to put aside annually to be indifferent to the risk over a long enough period.
The calculator then does two separate things with those numbers. It picks the cheapest posture whose capability meets both of your stated targets, which is the compliance answer. And it finds the posture with the lowest total of running cost plus expected loss, which is the economic answer. When those disagree, the gap between them is exactly what your stated objectives cost above what the risk arithmetic alone would justify — and that is a number worth taking to whoever set the objectives.
Worked example: a $40,000-a-month production estate
Take the defaults: $40,000 a month of production infrastructure, $1,200 of backup storage, $900 of replication, nightly backups, an RPO target of one hour and an RTO target of four hours, $25,000 of revenue per hour, $12,000 per hour of lost data, and two events expected per decade.
- Find the posture that meets the targets. Backup and restore offers a 24-hour RPO and a 24-hour RTO — it fails both. Pilot light offers one hour and four hours, which meets both exactly, so it is selected.
- Price its standing capacity. $40,000 × 10% = $4,000 a month.
- Add the always-on costs. $4,000 + $1,200 + $900 = $6,100 a month, or $73,200 a year.
- Price the data loss. 1 h × $12,000 = $12,000.
- Price the outage. 4 h × $25,000 = $100,000.
- Total one event. $12,000 + $100,000 = $112,000.
- Annualise it. 2 ÷ 10 = 0.2 events a year, so 0.2 × $112,000 = $22,400.
- Add the two. $73,200 + $22,400 = $95,600 a year, all in.
Now compare that against the alternatives at the same inputs. Backup and restore costs $14,400 a year to run but loses $888,000 per event, giving $177,600 of expected loss and $192,000 in total. Warm standby costs $265,200 to run and loses $28,000 per event, totalling $270,800. Multi-site costs $505,200 to run and loses $6,450 per event, totalling $506,490. Pilot light's $95,600 is the lowest of the four, so here the compliance answer and the economic answer agree — which is not always the case, and the calculator says so when they diverge.
How to read the comparison
Start with the gap between the two answers. If the posture meeting your targets is also the lowest-total posture, your objectives are economically self-justifying and the conversation is over. If it is not, the difference is the annual price of holding an objective the arithmetic does not support on its own. That price is often worth paying — for a contractual commitment, a regulatory requirement, or a brand risk this model cannot see — but it should be paid knowingly.
Check which half of the event loss dominates. In the worked example the outage costs $100,000 and the data loss $12,000, so RTO is where the money is and tightening RPO further would buy almost nothing. Reverse the two input rates and the conclusion reverses with them. Tighten the objective that dominates; the other one is close to free to leave where it is.
Treat the event rate as the widest uncertainty. Everything else in this model is a price you can look up. The number of region-level failures or ransomware events you will suffer in a decade is a judgement. Run the case at half and double your estimate: if the recommended posture is the same at both, the decision is robust, and if it changes, you have found the argument that actually needs settling.
Expected value is not the whole risk story. A posture with a low expected annual cost can still expose you to a single event large enough to be existential. If the per-event loss is a material fraction of annual revenue, the right frame is survivability rather than expectation, and you should buy down RTO past the point this calculator recommends. Expected value is the correct tool for risks you will face many times, not for the one that ends the company.
Loss in a single event by RPO and RTO
| RTO | 24 h RPO | 4 h RPO | 1 h RPO | 15 min RPO |
|---|---|---|---|---|
| 24 h | $888,000 | $648,000 | $612,000 | $603,000 |
| 8 h | $488,000 | $248,000 | $212,000 | $203,000 |
| 4 h | $388,000 | $148,000 | $112,000 | $103,000 |
| 1 h | $313,000 | $73,000 | $37,000 | $28,000 |
| 15 min | $294,250 | $54,250 | $18,250 | $9,250 |
The 4-hour RTO, 1-hour RPO cell is the worked example's $112,000. Read across a row to see what tightening RPO alone buys, and down a column to see what tightening RTO alone buys; at these two rates the columns move the total far less than the rows do.
Assumptions this model makes, and where they break
- Recovery region capacity is priced as a fraction of production. In practice a pilot light environment is often not a clean tenth — databases must be sized for the full data set even when compute is minimal. If your recovery region is priced differently, override the production cost input with a figure that reproduces the right capacity cost for your posture.
- Loss is assumed linear in time. Real outages are not: the first fifteen minutes may cost little and the fourth hour may trigger contractual penalties, press coverage and churn. Linear is the right default and it understates long outages.
- The recovery is assumed to work. An untested runbook has an effective RTO of "unknown", not four hours. Recovery testing is the cost line most often missing from a DR budget, and it belongs in the running cost, not in the event cost.
- Backups are assumed recoverable. Ransomware that encrypts or deletes backups collapses every posture at once. Immutable or air-gapped copies are a separate control that this model does not price, and they are the reason backup storage stays on the bill even for active/active.
- Events are assumed independent and rare. Expected value is a poor guide when one event can end the business, and a poor guide when failures are correlated across the primary and recovery region.
- Data loss and outage are priced separately but land together. A real event imposes both at once, plus incident response effort this calculator does not include. Price that part in the incident response cost calculator and add it.
Where these definitions come from
RPO and RTO are defined in NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems, which remains the standard reference for the terms regardless of which cloud you run on. The four-posture ladder used here — backup and restore, pilot light, warm standby, multi-site active/active — is the taxonomy set out in the AWS whitepaper Disaster Recovery of Workloads on AWS: Recovery in the Cloud. Other providers use different names for the same ladder; the capability tiers map across closely enough that the arithmetic holds.
How DR spend relates to everything else on the reliability budget
Disaster recovery covers the rare, large failure. Day-to-day availability covers the frequent, small one, and they are funded differently. If you are deciding how much ordinary redundancy to buy, the cost of additional nines calculator prices that ladder, and the uptime and downtime calculator converts any availability percentage into minutes. A common and expensive mistake is buying a multi-site DR posture to fix a problem that is really about deployment quality, where the same money spent on testing and rollout control would remove far more downtime.
On the vendor side, remember that a service credit is not compensation. The SLA credit versus actual loss calculator shows how small the credit usually is relative to the loss it nominally covers, which is the argument for owning your own recovery capability rather than relying on a provider's promise.
Two cost inputs here deserve their own workings. Backup storage is dominated by retention policy and tier choice, and the object storage tier cost calculator shows how a cold tier that looks cheap becomes expensive the moment you restore from it — which is precisely what a DR event does. And if this estate is mid-migration, fold the DR cost into the cloud column of the cloud migration payback calculator, because a business case that omits recovery is comparing a protected data centre against an unprotected cloud.
Key terms
- Recovery point objective (RPO)
- The maximum acceptable data loss, expressed as a period of time. Determined by how frequently data is copied off the primary site.
- Recovery time objective (RTO)
- The maximum acceptable time to restore service after an event. Determined by how much capacity is already standing in the recovery region.
- Pilot light
- A posture where data is replicated continuously but only a minimal core of infrastructure runs. Compute is scaled up during recovery.
- Warm standby
- A scaled-down but fully functional copy of the environment, running continuously and able to take traffic after a scale-up.
- Expected annual loss
- Per-event loss multiplied by the expected number of events per year. An annualised risk figure, not a forecast for any particular year.