Every few months a client comes to us with a multi-cloud mandate handed down from procurement or leadership. "We can't be dependent on one vendor." Sometimes this is a reasonable risk management position. More often, it's a decision made without fully accounting for the operational cost.
When multi-cloud genuinely helps
Regulatory requirements that mandate geographic or vendor distribution. Specific workloads that need capabilities one provider does significantly better (ML training on GCP, then inference on AWS, for instance). Negotiating leverage — though this requires real commitment to execute, not just the threat of it.
When it mostly creates problems
The biggest cost of multi-cloud isn't the infrastructure — it's the cognitive overhead. Your team needs to be proficient in two (or more) security models, two sets of networking primitives, two billing systems, two sets of managed services with different APIs and failure modes. That proficiency is expensive to build and expensive to maintain.
We've seen teams spend 40% of their infrastructure engineering time managing cross-cloud networking and identity — time that would have been better spent on reliability, cost optimisation, or developer experience in a single well-operated environment.
The honest question to ask
What specific, quantified risk does multi-cloud mitigate? If the answer is "vendor lock-in" — ask what the actual scenario is. Cloud providers have been extraordinarily stable. If the answer is "regional outage" — ask whether your application is truly designed to fail over between clouds, or whether that's aspirational architecture that'd take 18 months to actually implement.
Multi-cloud done well is an engineering discipline, not a procurement strategy. If you're not treating it as the former, you're incurring the cost without the benefit.
