Multi-Cloud vs Single-Cloud: The Honest Cost-of-Switching Math
Multi-cloud is sold as resilience. The honest math says it is sometimes that, often expensive insurance, occasionally the right call.
The four hidden costs
Vendor discount erosion. Single-cloud commitments unlock 30-50% off list. Splitting workloads splits the discount.
Engineering overhead. Two operating models, two security postures, two billing systems.
Data egress between clouds. Cross-cloud bandwidth costs add fast at any meaningful scale.
Talent dilution. Engineers expert in two clouds are rarer than experts in one.
When multi-cloud actually pays
- Regulatory data residency. A region or country only one cloud serves.
- Acquired company on the other cloud. Migration cost > multi-cloud cost.
- One workload type with a 10x better fit. ML on Google, Windows on Azure, the canonical examples.
The abstraction tax
Portable code is expensive. Cloud-agnostic abstractions cost 10-20% engineering velocity to maintain. Pay it only for the workloads that actually need to move.
Most teams should accept lock-in for 80% of workloads and abstract only the critical 20%.
A pragmatic posture
Single-cloud as default. Multi-cloud where regulation, acquisition, or extreme workload-fit demands it. Document the ‘why this is multi-cloud’ per workload so the next refactor remembers.
Antipatterns
- Multi-cloud as resilience theatre. Most teams cannot fail over fast enough for it to matter.
- Multi-cloud Kubernetes as the answer. The k8s layer abstracts compute; data egress and managed services do not abstract.
- No exit plan when locked in. Even single-cloud, document what migration would look like.
What to do this week
Three moves. (1) Pick the most exposed instance of the pattern in your environment. (2) Apply the lightest fix and measure for one week. (3) Schedule a quarterly review so the discipline does not rot.