Across the 40 enterprise environments we operate, the split isn't as even as cloud vendors would like you to believe. Most organizations run one primary cloud for the large majority of workloads, and a second cloud for one specific, nameable reason — not because someone drew up a "multi-cloud strategy" on a whiteboard and decided two providers is inherently safer than one.
The Pattern: Primary-Secondary, Not 50/50
The vendor pitch for multi-cloud is usually framed as risk diversification — spread workloads evenly, avoid lock-in, keep negotiating leverage. In practice, we almost never see an even split. What we see instead is a primary-secondary model: 70–90% of workloads on one cloud, with a second provider carrying a specific, bounded slice of the environment. The primary cloud is chosen the way you'd expect — existing team expertise, migration history, or the platform a founding engineer happened to know best. The second cloud shows up later, for a reason someone can actually name.
The Four Reasons We Actually See for a Second Cloud
When we scope a multi-cloud environment, the second provider is almost always there for one of four reasons:
Data residency requirements. Certain data — financial records, health data, government contracts — has to stay within jurisdictional boundaries the primary cloud's regional footprint doesn't fully cover.
A specific managed service the primary cloud doesn't match. A team standardized on one provider for general compute and storage, then needed a managed service — a particular database engine, an ML platform, a regional edge product — that a different provider does better.
Disaster recovery and business continuity. The second cloud exists purely as a failover target, often running a fraction of production capacity until it's needed.
Inherited infrastructure from an acquisition. The acquired company was already running on a different cloud, and unifying onto one platform wasn't worth the migration risk in year one.
Notice what's missing: "avoiding vendor lock-in" as a standalone reason. It shows up in vendor slide decks far more often than it shows up in actual architecture decisions.
What a Second Cloud Actually Costs You
The part that rarely makes it into the multi-cloud pitch is the operational tax. Every additional provider means a second identity and access management model to govern, a second set of monitoring and alerting tooling — or a third-party layer to unify them — engineers who need genuine fluency in two platforms instead of expertise in one, and often the biggest surprise: egress costs for any data that has to move between environments. None of this is a reason to avoid multi-cloud. It's a reason to make sure the second cloud is solving a real, specific problem, because you'll pay an ongoing tax for it either way.
The Question to Ask Instead of "Which Two Providers"
If you're evaluating a multi-cloud strategy, the question isn't "which two providers should we pick." It's: what specific capability, regulatory requirement, or risk are we solving for that a single provider genuinely can't cover? If you can name it in one sentence, multi-cloud is probably right, scoped narrowly around that reason. If the honest answer is "just in case," a single well-architected cloud with a solid disaster recovery plan usually delivers more resilience per dollar than a second full environment maintained "just in case."
A short checklist before you commit:
- Can you name the specific reason for a second cloud in one sentence?
- Have you priced the ongoing operational overhead, not just the migration cost?
- Does your team have — or can you build — genuine fluency in both platforms?
- Would a stronger DR plan on your existing cloud solve the same problem for less?
FAQ
Is multi-cloud more expensive than single-cloud? Almost always, yes — in operational overhead if not in raw compute pricing. The question isn't whether it costs more, it's whether the specific problem it solves is worth that ongoing cost.
Do I need a second cloud provider for disaster recovery? Not necessarily. Many DR requirements can be met with multi-region redundancy within a single cloud. A second provider is usually justified when you need protection against a full provider-level outage or a specific regulatory requirement for provider diversity.
What's the most common multi-cloud mistake you see? Standing up a second cloud "for flexibility" without a named workload or requirement driving it — then discovering a year later that nobody's using it for anything specific, but the team is still maintaining two sets of tooling.