“Multi-cloud” describes two very different things. One is cheap and frequently sensible. The other is expensive and rarely justified. Confusing them is why the term has a mixed reputation.
The two versions
Version one — different workloads on different providers. The application on a flat-rate VPS provider, object storage where it is cheapest, a managed model API from a hyperscaler, DNS and CDN from a specialist. Each component sits where it is best served.
Version two — the same workload running on two providers at once, able to fail over. This is genuine active-active multi-cloud, and it is a large, permanent engineering commitment.
Almost everybody who benefits from multi-provider is doing version one.
Why version one works
- Cost. Bandwidth-heavy serving on a provider with pooled transfer allowances, next to managed services from a provider that has them, is frequently far cheaper than either alone — see egress and bandwidth charges.
- Leverage. Knowing you can move a component is worth something at renewal, and it is only true if you have done it.
- Fit. No single provider is best at everything, and the differences are structural rather than marginal — the comparison pages set them out.
- Blast radius. A provider-level account problem does not take out everything you run.
What version one costs
- Traffic between providers is egress on the sending side, every time. Split along low-traffic seams.
- Latency between components in different networks, which rules out chatty coupling.
- Two consoles, two billing relationships, two support processes.
- Two sets of identity and access controls to keep consistent.
Manageable, as long as the split follows a seam that already exists rather than cutting through one.
Good seams
- Static assets and media — a CDN and object storage anywhere, since traffic is one-directional and cacheable.
- Backups — deliberately on a different provider from production, which is the single best multi-provider decision there is. See snapshots vs backups.
- Batch and training jobs — wherever the capacity is, with data staged in advance.
- Managed model APIs — consumed over the internet regardless of where the application runs.
- DNS — separate from everything, so a provider incident does not also prevent you from routing around it.
Why version two is usually not worth it
Running the same workload live on two providers means every stateful component must be replicated across networks, every deployment must be duplicated, every feature must work on both, and the whole thing must be tested regularly or it will not work when needed.
The cost is roughly double the infrastructure plus a permanent tax on every change. Set against that, most organisations get more availability, for far less, from tested backups, multiple zones, and a deployment process that does not break production. The exception is a genuine regulatory requirement — in which case it is a requirement, not a strategy.
A realistic view of lock-in
Lock-in is real and is not binary. Virtual machines, object storage and managed relational databases are broadly portable. Proprietary orchestration, event routing and identity integrations are not. You do not avoid lock-in by refusing managed services; you manage it by knowing which of your dependencies are load-bearing and what replacing each would take. Migrating between cloud providers is the exercise that makes the answer concrete.
Where to go next
Questions
Frequently asked
Is multi-cloud worth it?
Running different workloads on different providers usually is, for cost and fit. Running the same workload live on two providers rarely is, because it roughly doubles infrastructure and taxes every change.
Does using multiple providers improve availability?
Less than expected. For most organisations, tested backups, multiple availability zones and a safe deployment process buy more availability for far less money.
How do I avoid cloud lock-in?
By knowing which dependencies are load-bearing rather than by avoiding managed services. Virtual machines, object storage and relational databases are broadly portable; proprietary orchestration and identity integrations are not.