Most multi-cloud setups solve a problem the company does not have, at a cost it cannot see.
I have reviewed cloud architecture at a dozen European enterprises over the past four years — reinsurers, energy companies, industrial manufacturers, B2B SaaS. Companies with serious infrastructure. In that time, I have seen exactly two organisations where a genuine multi-cloud architecture delivered measurable, justified value. The rest were running multi-cloud because an architect wanted to put it on their CV, a procurement team negotiated leverage it would never use, or a board got spooked by an AWS outage it read about in the Financial Times.
This is not an argument against cloud diversity. It is an argument for honest accounting.
The Argument Everyone Makes for Multi-Cloud
It usually comes in one of three forms.
"We can't be locked in to a single vendor." This sounds strategic. It is usually fear dressed up as strategy. Lock-in is real, but its cost is almost always lower than the cost of the abstraction layer you build to avoid it. Kubernetes gives you portability at the compute layer. Terraform gives you portability at the infrastructure layer. Kafka and PostgreSQL run anywhere. The higher-value managed services — Azure OpenAI, AWS Bedrock, Google Vertex AI — are differentiated enough that you will use them anyway, and an abstraction layer over them negates the differentiation that justified the choice.
"We need 99.999% availability and one cloud cannot deliver it." For most companies, availability risk is at the availability-zone level, not the cloud-provider level. AWS us-east-1 going down for an hour is roughly a once-in-three-years event. A multi-region architecture on a single cloud gives you five-nines reliability at a fraction of the operational complexity of multi-cloud. If you genuinely need survivability against a complete cloud provider failure — critical financial infrastructure, regulated systems with specific recovery mandates — multi-cloud can be justified. But that is a narrow slice of workloads, not a default architecture.
"Negotiating leverage." Real in theory. In practice, your cloud bill needs to be north of €50M per year before you have genuine leverage in either contract negotiation. Below that, running workloads on two clouds to stay "negotiable" is a cost centre, not a strategy.
What Multi-Cloud Actually Costs
The true cost of multi-cloud is almost never captured in the business case that approves it.
| Cost Category | Single Cloud | Multi-Cloud | Notes |
|---|---|---|---|
| Platform engineering FTE | 2–3 | 4–6 | Each cloud needs specialists |
| Tooling standardisation | One stack | Parallel stacks | CI/CD, observability, security |
| Cross-cloud networking | Minimal | High | Egress fees compound fast |
| Training and certification | One vendor path | Two vendor paths | Talent is harder to find |
| Incident response | Single pane | Two consoles, two playbooks | MTTR increases measurably |
| Security policy management | One policy engine | Two with mappings | Drift is inevitable |
Platform engineering teams that are already stretched across IAM, networking, observability, and developer tooling for a single cloud do not magically absorb a second cloud with the same headcount. I have seen this assumption baked into migration business cases more times than I can count. The headcount appears 12 months later, as unplanned growth, after the performance reviews.
The abstraction layer trap
The most expensive version of multi-cloud is building an abstraction layer across both providers so developers don't need to know which cloud they're on. This "cloud-agnostic" layer starts as a thin wrapper and ends as a bespoke platform your team maintains forever. Every managed service capability that would have saved you engineer-weeks is now off-limits because it is "too provider-specific." You pay for cloud innovation but you cannot use it.
The Two Cases Where Multi-Cloud Actually Makes Sense
I said two organisations. Here is what set them apart.
Case 1: Regulated data residency with provider gaps. A large reinsurer needed workloads in a jurisdiction where their primary cloud provider had no region but a competitor did. The multi-cloud setup was narrow and deliberate — one workload category, one secondary provider, with a hard boundary. Not a general architecture posture. A targeted response to a specific regulatory constraint.
Case 2: Acquired company, different cloud. A post-merger integration where two organisations with incompatible cloud commitments needed to operate together for 18–24 months before consolidation. The multi-cloud "architecture" was a transitional state with a documented sunset date, not a permanent choice.
In both cases, multi-cloud was the answer to a specific, named problem. Not a hedge against hypothetical futures.
What to Do Instead
If you are considering multi-cloud for resilience, the right answer is almost always multi-region on a single cloud. If you are considering it for vendor leverage, the right answer is committed spend discounts and reserved instances — which paradoxically work better when consolidated. If you are considering it for flexibility, define what you mean by flexibility and price it.
Write one sentence: "We need multi-cloud because ___." If the blank is "it feels risky to be on one cloud," that is not a problem. If the blank is "we have a regulatory requirement for data residency in a jurisdiction our primary cloud does not serve," that is a problem. The architecture follows the problem, not the other way around.
Scope platform engineering headcount, duplicate tooling licenses, cross-cloud networking estimates, and training costs. Add them over three years. Compare that number to the probability-weighted cost of the risk you are mitigating. In most cases, the multi-cloud premium exceeds the expected loss from the risk it is designed to prevent.
Map your availability requirements to the architecture that satisfies them at minimum cost. Active-active multi-region on one cloud solves most enterprise resilience requirements. Multi-cloud solves a narrower class of problems at significantly higher cost. Be explicit about which requirement you are solving and which architecture is proportionate.
Cloud architecture decisions made at the team level, without executive visibility, drift towards complexity. The choice of cloud strategy — single cloud, multi-region, or genuine multi-cloud — should be an explicit executive decision with a named owner, a business justification, and a review cadence. Architects optimise for interesting problems. Executives should be optimising for outcomes.
The Resume-Driven Pattern and How to Spot It
Resume-driven architecture is not malicious. Talented engineers want to work on interesting problems with cutting-edge technology. Multi-cloud infrastructure is genuinely more interesting to design and operate than a well-tuned single-cloud deployment. The incentive to propose it is real, even when the business case is not.
The signals I look for in architecture reviews:
- The business case for multi-cloud cannot articulate a specific risk or constraint that single-cloud cannot address
- The architecture document cites cloud provider outages as the primary risk without quantifying likelihood or impact
- No one has modelled the operational overhead of the second cloud on current platform engineering headcount
- The team championing multi-cloud is the same team that will own the new platform capability
- "Avoiding vendor lock-in" appears as a primary objective without a definition of what lock-in would actually cost
None of these signals mean the architecture is wrong. They mean the decision-making process is not rigorous enough to justify the commitment.
What I see in enterprise architecture reviews
When I review cloud strategy at established European enterprises, the most common finding is not that the organisation is on the wrong cloud. It is that it is using its existing cloud at 40–60% of its capability — defaulting to lift-and-shift IaaS instead of managed platform services, running manual deployments instead of infrastructure-as-code, and treating the cloud bill as a fixed cost rather than an optimisation surface. Fixing that gap delivers more value than adding a second cloud.
The Honest Conversation
If your board is asking about multi-cloud because they read about a cloud outage, the right response is a resilience architecture review — not a multi-cloud strategy. If your CTO is proposing multi-cloud, ask them to model the three-year operational cost, not just the infrastructure bill. If your procurement team wants multi-cloud for leverage, ask them what spend level makes that leverage real.
The companies that get the most value from cloud infrastructure are the ones that go deep on a single provider — mastering its managed services, optimising its cost structure, building on its security primitives — rather than staying shallow across two.
Multi-cloud is sometimes the right answer. It is rarely the right default.
If you are evaluating cloud strategy or navigating a cloud migration decision — single cloud, multi-region, or multi-cloud — and want an experienced external perspective, let's talk. I offer a focused discovery call to assess your actual requirements and give you a straight answer about which architecture is proportionate to your situation.