Multi-cloud is often presented as a binary choice: do it or don't. In reality, the question is far more nuanced. Over seven landing zone engagements in the last three years, we've seen organisations adopt multi-cloud for the right reasons, the wrong reasons, and reasons they didn't fully understand at the start.
This article presents the decision framework we use to help clients evaluate whether multi-cloud is right for them — and if so, how to architect it without creating operational complexity that outweighs the benefits.
The Four Legitimate Reasons for Multi-Cloud
From our engagements, we've identified four legitimate motivations for multi-cloud — and one common illegitimate one.
1. Acquisition-driven heterogeneity: The most common. A company acquires a business that's already on a different cloud. The cost and risk of migration exceeds the benefit of standardisation. Multi-cloud becomes a fact, not a choice.
2. Best-of-breed service requirements: Specific workloads have genuine best-fit on a particular cloud — typically ML/AI (GCP Vertex, AWS SageMaker), or specific SaaS integrations that have native connectors to one cloud.
3. Data sovereignty and residency: Some regulated industries require data to remain in specific geographic regions, and not all clouds have equivalent region coverage in all geographies.
4. Negotiation leverage: Large enterprises sometimes use a second-cloud footprint as leverage in enterprise agreement negotiations. This is legitimate if the footprint is real and maintained.
The illegitimate reason: "vendor lock-in avoidance" as an abstract principle. Lock-in is real, but the cost of true cloud portability (avoiding cloud-native services, maintaining dual infrastructure, cross-cloud networking costs) almost always exceeds the lock-in risk for all but the largest organisations.
Landing Zone Topology: Three Patterns
For clients who proceed with multi-cloud, we've converged on three topology patterns based on workload coupling:
- Parallel islands: Each cloud hosts independent workloads. No cross-cloud data flows in the critical path. Simplest to operate, highest cost duplication.
- Primary + secondary: One cloud hosts the majority of workloads; the second hosts specific services (e.g., ML training on GCP, everything else on Azure). Cross-cloud flows are non-critical-path.
- Active-active distributed: Workloads are deliberately distributed across clouds for resilience or data locality. Highest complexity, justified only for tier-1 workloads with extreme availability requirements.
The Operational Cost Most Organisations Underestimate
The biggest surprise in our engagements is consistently the operational overhead. Two separate landing zones means two separate sets of: IAM policies, network topology, security tooling, monitoring stacks, cost management frameworks, and runbooks. Skill requirements double.
We recommend budgeting at least 40% additional platform team capacity for multi-cloud versus single-cloud at equivalent workload scale. If that capacity doesn't exist, the second cloud becomes an unmanaged liability.
- Start from business requirements, not technology preferences
- Acquisition-driven heterogeneity is the most common legitimate multi-cloud driver
- "Vendor lock-in avoidance" rarely justifies the operational cost
- Parallel islands topology is simplest to start with — evolve only when needed
- Budget 40% additional platform team capacity for multi-cloud operations