Multi-cloud is a consulting engagement, not an architecture pattern.
I can say this because I’ve been on both sides. I consult for large enterprises. Some of them run workloads across two or three cloud providers. Every single one wishes they didn’t. The ones that are happy with multi-cloud are happy because a specific regulatory or customer requirement forced their hand, not because they chose it for technical elegance.
The rest got there by accident. Different teams picked different clouds. An acquisition brought in a second platform. Someone in leadership read a Gartner report. Now they have two sets of IAM policies, two networking models, two monitoring stacks, and a platform team that’s permanently underwater.
The pitch vs. the reality
The multi-cloud pitch goes like this: avoid vendor lock-in, leverage best-of-breed services from each provider, improve resilience through provider redundancy.
Here’s what actually happens.
“Avoid lock-in” – You’re not avoiding lock-in. You’re doubling it. Now you’re locked into two vendors instead of one, and you’re also locked into whatever abstraction layer you built to make them look the same. That abstraction layer is its own maintenance burden. It lags behind both providers’ features. And when it breaks, nobody outside your platform team knows how to fix it.
“Best-of-breed” – This sounds rational until you try to integrate BigQuery with an application running on AWS. Cross-cloud data movement is slow, expensive, and architecturally painful. Data has gravity. Once it lives somewhere, everything that touches it wants to live there too. Picking services from multiple providers means fighting data gravity constantly.
“Provider redundancy” – This is the one that really gets me. How many organizations have actually tested a full provider failover? I’ve asked this question dozens of times. The answer is almost always no. They have multi-cloud on a slide deck. They don’t have a tested failover runbook. If AWS goes down, their “redundant” GCP deployment hasn’t been exercised under real load and will probably fall over for entirely different reasons.
When it actually makes sense
I’m not saying multi-cloud is never justified. There are real reasons.
Regulatory or data residency requirements can force specific workloads into specific regions that only one provider serves well. Mergers and acquisitions bring in existing infrastructure that you can’t migrate overnight. Some customers contractually require their data to run on a specific platform.
Those are constraints. You respond to constraints. That’s different from choosing multi-cloud because it feels like good architecture.
What I actually recommend
Default to one cloud. Pick the one your team knows best. Go deep on it. Use its managed services. Learn its IAM model properly. Build in multiple regions for resilience. That covers 95% of failure scenarios with a fraction of the operational complexity.
Design for portability at clear boundaries. Containers and Kubernetes give you a portable compute layer, and that’s real. But Kubernetes doesn’t abstract away networking, storage, IAM, DNS, load balancing, or any of the managed data services. Treat Kubernetes as a helpful layer, not a magic portal between clouds.
Keep data in one place unless you have a specific, measured reason to replicate it. Cross-cloud data synchronization is a beast. Latency, consistency, cost, and operational complexity all increase dramatically. I’ve seen teams spend more engineering hours managing cross-cloud data replication than they spent building the features that use the data.
Have an exit plan even if you’re single-cloud. Know how to export your data. Understand which services are proprietary and which have open equivalents. Negotiate contracts with exit timelines. This is smart vendor management. It doesn’t require running production workloads on two platforms.
The uncomfortable truth
Multi-cloud is mostly sold by people who benefit from the complexity it creates. Cloud vendors sell multi-cloud management tools. Consulting firms sell multi-cloud strategy projects. Platform vendors sell abstraction layers.
The teams who actually run the infrastructure? They’re drowning in operational overhead and wondering why everything takes twice as long.
If someone proposes multi-cloud at your organization, ask one question: what specific problem does a second cloud provider solve that multi-region on our current provider doesn’t? If the answer is vague, you have your answer.