Name the risk before you price anything
"Should we be multi-cloud?" is three questions wearing one label, and each has a different cheapest answer.
The first is resilience. A region failing is a real event, and it is handled by running across zones and regions within one provider. A whole provider failing everywhere at once is rarer. Active-active across two clouds only helps if everything else in the request path is also independent: DNS, identity, the CI system, the payment gateway, and the SaaS tools your teams use. Many estates that claim provider independence still share one identity provider and one deployment pipeline.
The second is leverage. If you can never leave, your renewal is a formality for the vendor. Vendor lock-in is a commercial risk before it is a technical one, and what restores leverage is a credible exit, not a second live estate.
The third is regulation and residency. Financial-services regulators in several jurisdictions expect firms to manage concentration risk on critical technology providers. In the EU, the Digital Operational Resilience Act asks financial entities to hold exit strategies for ICT services supporting critical or important functions. Data-residency rules in some countries also decide which provider can serve a market at all. What any of this requires of your company is for compliance and legal to confirm, and it often asks for a documented, tested exit rather than dual running.
What each option costs, worked through
The table compares four postures for an illustrative company. Every figure is an assumption to show the reasoning, not a market rate; replace each with your own contract and payroll numbers.
Assumptions: annual cloud spend of 10.0m in your reporting currency. A loaded cost of 0.2m a year per platform engineer. A platform team of eight today. Your current contract gives a 15% commitment discount on the 60% of spend you have committed.
| Posture | What changes | Annual cost | Versus today |
|---|
| A. Single cloud, no deliberate seams | Baseline: 10.0m spend + 8 engineers (1.6m) | 11.6m | - |
| B. Single cloud, portable seams, tested exit | +1 engineer for seams and exit tooling (0.2m), +0.1m for an annual exit rehearsal | 11.9m | +0.3m (2.6%) |
| C. Multi-cloud by workload | 30% of spend (3.0m) moves to a second provider with no commitment yet; the discount on its committed portion is lost (3.0m × 60% × 15% = 0.27m); team grows to 12 for a second set of identity, networking and IaC skills (2.4m) | 12.67m | +1.07m (9.2%) |
| D. Active-active across two clouds | Each side must carry full load if the other fails, so the serving share of the bill, assumed 6.0m, is duplicated; cross-cloud replication traffic assumed at 0.4m; team grows to 16 (3.2m) | 19.6m | +8.0m (69%) |
Two things in that table matter more than the totals. Most of option D's premium is idle capacity held for a rare event, so the honest question for the board is whether a provider-wide outage costs you more than 8.0m a year in expected loss. Option D also leaves out the cost no spreadsheet captures well. Every feature now ships to two platforms, and teams give up the managed services that differ between them.
The lowest-common-denominator tax
Portability has a price that does not show on the invoice. To run the same workload on two clouds, you build on what both offer: containers, standard databases, your own queueing. That means giving up managed services that would have saved engineering time. The team then operates more infrastructure itself. That is option C and D's extra headcount, and it recurs every year.
So decide portability per layer, not for the whole estate, and accept some vendor lock-in where the managed service earns it. Compute packaged as containers and defined in infrastructure as code is cheap to keep portable. Your data in open formats, with your own identifiers, is cheap and is where exit actually lives. A proprietary serverless workflow engine or a provider-specific analytics database is expensive to keep portable. The rational move is often to use it, with a short exit note recording what leaving would take.
The engineering side of that judgement is in managed versus self-hosted, and executing a migration away from a coupled estate is covered in cloud provider exit strategy.
Realistic middle paths
Most organisations land between the extremes, and the defensible versions are deliberate rather than accidental.
One primary cloud with portable seams is option B. It buys back most of the leverage for a small premium, provided the exit plan is rehearsed. A plan that has never been exercised is a document, not an option.
Multi-cloud by workload means each system lives on one provider, but different systems use different ones. It is often where acquisitions leave you. It can be the right answer when a second provider is clearly better for one workload, or when residency forces it in one market. Do not mistake it for resilience, because no single system survives losing its provider.
A narrow recovery path on a second provider covers only the few capabilities that must survive a provider loss, such as a status page, customer communications, or a read-only view of accounts. This buys resilience where it matters at a fraction of option D's cost.
Where the answer shifts with company shape
A startup with a short runway should almost always pick one cloud and move fast, because operating overhead is its scarcest resource. A private-equity-owned company may value exit leverage at renewal highly and fund option B for that reason. A listed or regulated financial firm may need documented concentration analysis and exit testing to satisfy supervisors. A captive centre usually inherits the parent's provider decision and should focus on seams it controls. Say which of these you are in before you recommend anything.
Multi-cloud bought for the wrong failure
The weak answer treats multi-cloud as a resilience feature and buys option D to cover a provider-wide outage, while the request path still depends on one identity provider and one pipeline. The strong answer notices that the stated driver is usually leverage or regulation in disguise. Both are served better by a credible, rehearsed exit than by a second live estate. If the board genuinely wants provider-level survival, price it honestly and scope it to the few capabilities that need it.
Name the risk first. Leverage and regulation are usually bought more cheaply with a tested exit plan than with a second cloud, and active-active pays mostly for idle capacity held against a rare event.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).