Ask a CTO why their company runs three clouds and the answer is usually some version of flexibility, resilience, or avoiding lock-in.
Ask how it actually happened, and the answer is usually different. An acquisition brought Azure. A data science team preferred GCP. Someone signed an AWS commit in 2021. Nobody ever made a decision — the estate accumulated, and the strategy was written afterwards to explain it.
That is not a criticism. It is how most infrastructure ends up looking the way it does. But it matters, because a strategy chosen deliberately and an estate inherited accidentally require completely different next steps — and the industry mostly writes advice for the first while nearly everyone is living in the second.
Single cloud — one public provider. Simplest to operate, deepest use of managed services, most exposure to one vendor's pricing and outages. Multi-cloud — two or more public providers. Flexibility and negotiating leverage, at the cost of duplicated tooling and expertise. Hybrid — public cloud plus private or on-premises infrastructure. Usually driven by data residency, latency, or workloads that were never economical to move.
The Most Common Reason Is Usually the Wrong One
Flexera's 2026 survey found the top three motivations for multi-cloud: avoiding vendor lock-in (67%), optimal price-performance per workload (54%), and compliance with data locality requirements (48%).
The second and third are sound. The first deserves scrutiny.
True portability between clouds means avoiding anything proprietary — which means avoiding managed databases, managed queues, managed identity, serverless runtimes, and most of what makes a cloud worth paying for. You end up running Kubernetes everywhere with your own Postgres, your own Kafka, your own observability stack, so that in theory you could move.
You have not avoided lock-in. You have traded vendor lock-in for complexity lock-in — and complexity is harder to leave, because it lives in your team's heads rather than in a contract you can renegotiate.
Ask how many times your organisation has actually migrated a production workload between cloud providers. For most companies the answer is zero, or once, painfully. Now weigh the engineering cost of five years of lowest-common-denominator architecture against a migration you have never performed and probably never will. Lock-in is a real risk. It is rarely the biggest one on the list.
Gartner's own warning points the same way: more than 50% of organisations will fail to achieve the results they expected from multi-cloud by 2029 unless they address interoperability seriously — which most do not, because it requires exactly the mature tooling and skilled team that the lock-in argument assumed they could avoid needing.
What the 2026 Data Actually Shows
The waste figure is the one worth sitting with. Nearly a third of cloud spend is wasted regardless of which model you run. A team arguing about multi-cloud versus single cloud while wasting 29% of the bill is optimising the wrong variable — the savings available from right-sizing, scheduling and removing orphaned resources usually dwarf anything the architecture choice delivers.
The Repatriation Story Is Widely Misread
You will have seen the headline that 86% of CIOs are moving workloads back from the cloud. It is a real figure and it does not mean what it is usually used to mean.
It refers to CIOs moving some workloads back — not companies exiting the cloud. IDC's data puts the number planning full repatriation at 8% to 9%. Around 14% have moved at least one major workload back, driven by cost (42%) and compliance (38%).
Meanwhile public cloud spending keeps climbing, with IaaS the fastest-growing segment. Both things are true at once, and the useful distinction is this:
- · A workload was moved to cloud and it did not work out
- · Usually cost, sometimes performance or compliance
- · Reactive — you are undoing a decision
- · 8–9% of enterprises plan this fully
- · Often follows a lift-and-shift that was never optimised
- · Workloads placed where they run best, from the outset
- · Steady-state predictable load on owned hardware
- · Variable and bursty load on public cloud
- · Deliberate — you are making a placement decision
- · This is what most hybrid estates should be
Repatriation is a correction. Reallocation is a strategy. Most of what gets reported as the former is actually organisations discovering the latter.
A Decision Framework
Five questions, answered honestly, resolve this for most organisations.
| Question | If yes | Why |
|---|---|---|
| Do you have a hard data residency requirement in a region your primary provider does not serve? | Multi-cloud or hybrid | This is a constraint, not a preference. It decides for you. |
| Do you run a steady-state workload at consistently high utilisation? | Hybrid | Predictable load on owned hardware is usually cheaper than on-demand cloud, often substantially. |
| Does a second provider have a service with no real equivalent that you genuinely need? | Multi-cloud, scoped | Use it for that workload only. Do not architect the whole estate around one service. |
| Is your platform team large enough to run two clouds properly? | If no — single cloud | Two clouds means two sets of IAM, networking, monitoring, cost tooling and on-call expertise. |
| Is "avoiding lock-in" the main reason on your list? | Reconsider | You are likely to pay for portability you never exercise, in complexity you carry daily. |
For a company under a few hundred engineers with no hard residency constraint, single cloud used deeply is usually the right answer — and it is the one consultants rarely recommend, because it is not much of an engagement. Going deep on one provider's managed services means less infrastructure to operate, a smaller surface to secure, and engineers who know one platform properly rather than three superficially.
What Each Model Actually Costs You
| Single cloud | Multi-cloud | Hybrid | |
|---|---|---|---|
| Operational complexity | Lowest | Highest | High |
| Use of managed services | Deepest | Limited by portability goals | Mixed |
| Negotiating leverage | Weakest | Strongest | Moderate |
| Blast radius of an outage | Whole estate | Contained, if designed for it | Depends on the split |
| Data egress exposure | Minimal | Significant | Significant |
| Platform team size needed | Smallest | Largest | Large |
| Compliance flexibility | Limited by provider regions | High | Highest |
Notice that egress appears on two of three. Moving data between providers runs $0.08–$0.12 per GB on hyperscalers, and in multi-cloud architectures with chatty cross-provider traffic it can quietly exceed the compute bill. It is the cost most multi-cloud business cases omit entirely.
If You Already Have an Accidental Multi-Cloud Estate
Inventory what runs where, and why
Every workload, its provider, and the actual reason it is there. Distinguish deliberate placement from historical accident. Most estates have more of the second than anyone expects, and those are the candidates for consolidation.
Week 1–2Fix the 29% waste before touching architecture
Right-sizing, scheduling non-production environments off overnight, deleting orphaned volumes and idle load balancers. This typically recovers more than any architectural change and takes weeks rather than quarters.
Week 2–6Name a primary provider
Even if you stay multi-cloud, one provider should be the default for new workloads. Without a default, every new service becomes a debate and the estate keeps fragmenting. Anything going elsewhere needs a stated reason.
Week 4Map and price cross-provider data flows
Find every place data crosses a provider boundary and price the egress. This is where accidental multi-cloud quietly bleeds money, and where a small amount of re-architecture often pays back immediately.
Week 5–6Unify identity, networking and observability first
If you are staying multi-cloud, these three are where the operational pain concentrates. Consistent IAM, a coherent network topology, and one place to look when something breaks. Not glamorous, and it is the difference between multi-cloud working and not.
Week 6–12Consolidate the accidental, keep the deliberate
Move workloads that ended up on a second provider by accident. Keep the ones with a real reason — residency, a genuinely unique service, a specific price-performance advantage. The aim is an estate you chose, not a smaller one for its own sake.
OngoingFrequently Asked Questions
Inherited a Cloud Estate Nobody Designed?
We do AWS architecture, cloud cost optimisation and DR/BCP for production systems. Book a free 30-minute call — we'll look at what you have and tell you honestly whether consolidating, staying, or doing nothing is the right call.