After spending the better part of a decade certifying across AWS, Azure, and GCP — and actually using all three in production — I get asked this question constantly:
“Should we go multi-cloud?”
The honest answer is: it depends, and usually not for the reasons you think.
The case people make for multi-cloud
The pitch usually goes something like this: vendor lock-in is bad, redundancy is good, and having multiple clouds means if one goes down, your system stays up.
That logic is reasonable on paper. In practice, it’s much messier.
What “going multi-cloud” actually means in production
When I architected the AI-powered data pipeline for a PE firm — running Python workloads across AWS Glue, Step Functions, and Textract — the choice to stay AWS-native wasn’t laziness. It was the right call. The managed services fit the problem precisely, the cost model was predictable, and the team was already fluent.
Introducing a second cloud just because would have meant:
- Double the IAM complexity — two identity systems, two permission models, two audit trails
- Latency at the seams — cross-cloud data transfer isn’t free, and it’s not fast
- Doubled operational knowledge requirements — not every engineer knows both platforms deeply
When multi-cloud is actually the right answer
Where I have genuinely reached for multi-cloud is when the problem demands it:
-
Client contractual requirements — some enterprise clients require you to avoid single-vendor dependency by policy. You don’t architect around this, you just solve for it cleanly.
-
Best-of-breed service selection — Azure’s Active Directory + AWS EKS is a real combination that makes sense for certain enterprise auth setups. GCP’s BigQuery + AWS for compute is another.
-
Geographic compliance — when data residency requirements mean one provider doesn’t have a region in the right country.
-
Acquired systems — M&A situations where you inherit a different cloud and the migration cost outweighs the unification benefit.
The hidden cost nobody talks about
The thing I’ve found consistently underestimated is team cognitive load. Each cloud has its own mental model, its own networking primitives, its own IAM philosophy. Asking your engineering team to be genuinely fluent across three clouds is asking a lot.
If you’re a 5-person startup: don’t do it. Pick one and go deep.
If you’re an enterprise with dedicated platform engineering capacity: multi-cloud can be a legitimate architectural choice, done carefully.
My rule of thumb
Use multi-cloud when the *business problem requires it, not when the architecture allows it. The best architecture is the simplest one that solves the actual problem.
Have a take on this? I’d love to hear it — reach out on LinkedIn.