Multi-cloud gets sold as the ultimate insurance policy and bought far more often than the risk justifies. The pitch is seductive: if one provider goes down, you fail over to another and sleep soundly. The reality is that multi-cloud imposes a permanent tax (you build against the lowest common denominator of two clouds, forever) to buy protection against a failure class that most teams could survive far more cheaply. This framework grades the resilience tiers by the failures each one survives and the cost each one imposes, so you can climb exactly as high as your risk justifies and no higher.
Start with RTO and RPO, not topology
The mistake is choosing a topology first. The right starting point is two numbers, per workload, with the business signing off:
- RTO (recovery time objective): how long you can be down before it hurts.
- RPO (recovery point objective): how much data, measured in time, you can afford to lose.
A four-hour RTO and a one-hour RPO describe a very different (and much cheaper) system than a two-minute RTO and a zero RPO. Set these numbers first and the topology falls out of them, instead of buying a topology and hoping it fits.
The resilience ladder
| Tier | Survives | RTO range | Relative cost |
|---|---|---|---|
| Single-AZ | Nothing beyond a host | Hours to days | 1x |
| Multi-AZ | Zone or data-center loss | Seconds to minutes | ~1.5x |
| Multi-region (warm) | Whole-region and regional control-plane loss | Minutes | ~2x |
| Multi-region (active-active) | Region loss with no failover step | Near zero | ~3x |
| Multi-cloud | Provider-wide or account-level loss | Varies | 4x and up, permanently |
The costs are directional, but the shape is the point: each rung buys a rarer failure at a steeper price, and the jump to multi-cloud is not one rung, it is a different category of cost that never goes away.
Multi-AZ: the floor, not a strategy
Running across availability zones survives the single most common infrastructure failure (the loss of a data center) for very little extra cost. It is table stakes for any customer-facing workload and should be assumed, not celebrated. But multi-AZ does nothing for a whole-region event, and it does nothing at all for a control-plane failure, because the control plane is usually regional or global and does not care how many zones you span.
Multi-region: the highest-leverage rung
For most organizations, this is where the real decision lives. Multi-region survives the events that cause the longest, most damaging outages: regional control-plane failures, regional network partitions, and correlated zone failures. Our analysis of outage duration shows these regional and global control-plane events are precisely the ones that run for hours, so the rung that survives them buys down your worst case.
Warm standby versus active-active
- Warm standby: a scaled-down copy of the stack runs in a second region and scales up on failover. Cheaper, but the failover itself is a step that must be tested (an untested failover is a hope, not a plan). It fits a minutes-scale RTO.
- Active-active: both regions serve live traffic, so a region loss is absorbed with no failover step and near-zero RTO. More expensive and it forces you to solve data consistency across regions, which is the genuinely hard part.
The dividing line is your RTO and whether you can tolerate a failover step. Most teams overreach here by demanding active-active for workloads whose real RTO would be met by a well-tested warm standby.
Multi-cloud: the narrow case
Multi-cloud only pays off against risks that multi-region cannot cover: a provider-wide failure across all regions, an account-level event (a billing lockout or a compromised account), or a hard regulatory requirement for provider diversity. These are real but rare. The tax is not: every team now builds against the intersection of two clouds' features, operates two sets of tooling, and pays egress to keep data in sync. Reserve it for the handful of workloads where a total provider loss is an existential, board-level risk, and even then apply it only to those workloads rather than the whole estate. This is the Level 5 independence case, and it belongs somewhere, not everywhere.
Making the decision
Set RTO and RPO per workload, find the lowest tier that meets them, and stop there. Contain what you can before you replicate what you cannot: the blast-radius framework often removes the need for a higher tier by shrinking the failure in the first place, and the SLO framework tells you whether your reliability numbers even justify the spend. When a provider event does breach your SLA, the failover you built does not recover the money: that is a claim, and our incident data, the corpus methodology, the provider record at awsdown.com, and the credit mechanics at cloudslacredit.com and cloud-credits.com cover how much of it, per the credit gap, typically goes uncollected.
Resilience spending is easy to overdo and expensive to reverse. Our monitoring sponsor, Next Signal, watches provider status feeds across clouds so you can size your resilience to the failures that actually happen to you, rather than to the ones a vendor deck told you to fear.