Multi-cloud is often a strategy in search of a problem. Here are the scenarios where the operational overhead is genuinely justified.
The Honest Case Against Multi-Cloud by Default
Most companies that use two clouds do not benefit from either strategically — they are paying two sets of egress fees, managing two security configurations, maintaining two sets of IAM policies, and running two observability stacks. The operational overhead of multi-cloud is real and significant. Before adopting a multi-cloud strategy, the burden of proof should be on demonstrating a specific, quantifiable benefit — not vendor diversification as a general principle.
The Legitimate Use Cases
Multi-cloud makes sense when: a customer contractual requirement mandates a specific cloud for data residency or compliance; a specific service only exists on one platform (Azure OpenAI has no AWS equivalent for enterprise GPT-4 deployments); or your company grew through acquisition and inherited another cloud estate that would cost more to migrate away from than to operate. These are specific, defensible reasons. 'We do not want vendor lock-in' is not — the switching cost between well-architected workloads is lower than the ongoing operational overhead of managing two clouds poorly.
Abstractions That Reduce Operational Overhead
If you do operate multi-cloud, Kubernetes dramatically reduces platform-specific operational differences for containerised workloads. Terraform and Pulumi provide cloud-agnostic infrastructure-as-code. A unified SIEM and observability platform (Datadog, Splunk, or Microsoft Sentinel with AWS connectors) prevents the two-pane-of-glass problem. These tools do not eliminate multi-cloud complexity, but they reduce its cost.
The Data Gravity Problem Nobody Mentions Early Enough
Data has gravity — once large datasets live in one cloud's storage and analytics layer, moving them is expensive in egress fees and engineering time. A company that stores 500TB in S3 and analytics in Redshift does not actually have a multi-cloud option for that data without a significant migration project. If multi-cloud is a future goal, data architecture decisions made today need to account for portability — which often means accepting a less-optimised single-cloud solution now.
- Multi-cloud by default generates two-cloud operational overhead without two-cloud strategic benefit
- Legitimate multi-cloud justifications: contractual data residency, a specific service only on one platform, or inherited estate from acquisition
- Kubernetes, Terraform, and a unified SIEM reduce multi-cloud operational overhead but do not eliminate it
- Data gravity is a real constraint — large datasets in one cloud's storage layer are expensive to move later