Multi-Cloud Is a Negotiating Position, Not a Resilience Strategy
After every major cloud outage the same question reaches the board: should we be multi-cloud? It arrives with the force of common sense. If one provider can go down, surely two providers are safer than one. Regulators in financial services have sharpened the question by naming the largest cloud providers as critical to the system. Surely the prudent answer is to run on more than one.
It usually is not, at least not in the way the question implies. Running the same workload live across two cloud providers is rarely worth what it costs, and it protects against a narrower set of failures than boards assume. The genuine value of a second cloud is elsewhere: in commercial leverage over the primary provider, and in credible evidence that the firm could leave if it had to, which is what regulators actually ask for. Treat multi-cloud as a resilience strategy and it becomes an expensive engineering programme that makes the estate more fragile. Treat it as a negotiating position and an exit capability, and it becomes one of the cheaper sources of leverage in the technology budget.
Three Things "Multi-Cloud" Means
Most bad multi-cloud decisions start with one word covering three different things.
Different workloads on different clouds. Analytics on one provider, the core platform on another, a productivity suite from a third. This is the normal state of a large enterprise. Flexera's annual State of the Cloud survey has found for years that most organisations already use more than one provider. It happens through acquisitions, team preference and best-of-breed buying, and it costs little beyond some duplicated skills. It does almost nothing for resilience, because each workload still depends on one provider.
Portability kept as an option. A workload built so it could move to another provider in a defined time, with its data exportable, its infrastructure defined as code, and its dependence on proprietary services deliberately limited. Nothing runs twice. The firm pays an option premium in engineering discipline and in some managed services forgone, in exchange for a credible exit.
Active-active across providers. The same workload running live on two clouds, with traffic balanced between them and data replicated so either can carry the full load if the other fails. This is what boards picture when they hear "multi-cloud resilience". It is also what almost nobody runs well, for reasons that are structural rather than a lack of effort.
| Pattern | Cost | What it protects against | Who should do it |
|---|---|---|---|
| Different workloads on different clouds | Low: some duplicated skills and tooling | Almost nothing for any single workload; spreads commercial dependence | Most large firms already do; no special justification needed |
| Portability kept as an option | Moderate: engineering discipline, some managed services forgone, periodic exit tests | Provider failure, commercial abuse or regulatory exit orders, over weeks or months rather than minutes | Firms with a few genuinely critical workloads and a regulator asking for exit plans |
| Active-passive across providers (warm standby) | High: a second environment kept current, replication, regular failover tests | A prolonged full-provider failure for the protected workload | A very small number of workloads where hours of outage are existential |
| Active-active across providers | Very high: lowest-common-denominator architecture, duplicated operations, continuous replication and egress | A total provider failure, with near-zero interruption, if it works | Almost nobody; the cost and complexity usually exceed the risk removed |
The distinction matters because the benefits people attribute to the fourth row are usually available far more cheaply from the second, or from staying on one provider and using it properly. The rest of this piece is about why.
This is a Premium Article
Sign up for a Premium membership to read this article and get full access to strategic intelligence on technology and business.
Already a member? Sign in
Related Articles
Why Banks Still Run Mainframes, and What Replacing One Actually Costs
Why banks still run mainframes, the real cost of COBOL estates, and which modernization paths work: rehost, refactor, strangler or full core replacement.
Your SaaS Vendor Is Not Protecting Your Data the Way You Think
SaaS vendors keep the service up. Keeping your records recoverable is usually your job. The shared-responsibility gap, and how boards should close it.
Passkeys in the Enterprise: What Replacing Passwords Actually Takes
Passkeys remove phishable passwords, but enterprise rollout hinges on synced vs device-bound keys and account recovery. A phased plan by user population.