Key takeaway: Genuine multi-cloud — one workload portable across providers — is rare and expensive to build. What most organisations have is several single-cloud systems that happen to sit on different providers, which is a different and more manageable thing.
The Aspiration Versus the Reality
The pitch for multi-cloud is straightforward: avoid lock-in, negotiate better pricing, run each workload on whichever provider suits it best. The reality inside most organisations is an acquisition that came with its own AWS account, a data science team that standardised on a provider for its ML tooling, and a legacy system nobody wants to touch that still runs where it was first deployed.
That arrangement is not the deliberate multi-cloud the pitch describes, and it is a completely reasonable state to be in. Confusing it with true portability is where things go wrong — teams start architecting for a portability they do not actually need and pay a real tax for it.
The Actual Cost of Portability
Building a workload that runs identically on two providers means avoiding every provider-specific service that would make the job easier. No managed queue with provider-specific semantics, no proprietary database, no serverless platform tied to one ecosystem — because using any of them breaks the portability the effort was meant to buy.
| Approach | Cost | What you actually gain |
|---|---|---|
| Single cloud, use native services | Low | Fast delivery, deep integration |
| Single cloud per workload, multiple providers overall | Moderate | Best-fit tooling per team |
| Genuinely portable single workload | Very high | Negotiating leverage, disaster recovery |
Genuine portability is worth its cost in narrow cases: a regulatory requirement for provider diversity, or a single workload valuable enough that provider outage risk justifies the engineering tax. It is rarely worth it as a blanket policy applied everywhere.
What to Do With What You Actually Have
If the honest situation is several single-cloud systems on different providers, the useful work is not forcing portability — it is making the boundary between them clean.
Standardise identity and access at the organisational level so a person’s credentials work consistently regardless of which provider a given system runs on. Standardise observability export so logs and metrics land in one place even when the source infrastructure differs. Standardise how secrets are managed and rotated, since this is the control most likely to be inconsistent and most costly when it is.
None of that requires the underlying workloads to be portable. It requires the operational layer around them to be consistent, which is a substantially smaller and more achievable goal.
Negotiating Without True Portability
The pricing leverage argument for multi-cloud assumes a provider believes you could actually leave. A workload deeply integrated with one provider’s proprietary services is not a credible threat to migrate, and providers know the difference between a customer who could move a workload in a quarter and one for whom migration would take two years.
Real leverage comes from workloads that are genuinely portable, even if that is a small fraction of total spend. Concentrate portability effort there rather than spreading it thin across everything.
The Bottom Line
Distinguish honestly between systems that happen to run on different providers and a workload engineered for true portability. Standardise the operational layer — identity, observability, secrets — across whatever you actually have, and reserve the real cost of provider-agnostic architecture for the specific workloads where it earns its keep.
