Glossary
Multi-cloud
Multi-cloud is the use of services from more than one cloud provider, each chosen for a specific strength, such as analytics in one and machine learning in another. Whether it reduces dependence on any single provider depends less on the number of providers than on where the primary data sits.
Multi-cloud and hybrid cloud compared
| Multi-cloud | Hybrid cloud | |
|---|---|---|
| What it counts | Providers | Deployment models |
| Typical shape | Two or more public clouds, sometimes plus a private one | Owned infrastructure plus at least one public cloud |
| Main motive | Best service per workload, negotiating position | Keeping steady or regulated data owned while using public services |
| Main risk | Data duplicated across providers | Policies diverging between the two sides |
The two overlap: an estate with a private cloud and two public providers is both. The distinction matters because the risks differ. Hybrid cloud is mainly an integration problem, multi-cloud mainly a data-placement problem.
How two providers become two lock-ins
Compute moves easily: a container image runs in another cloud within minutes. Data does not, and each provider charges egress fees whenever it leaves. A team that adopts a second provider to avoid lock-in and then keeps its primary data in both ends up with two datasets to keep in step and two exit bills. Applications follow whichever provider holds the data they read, the pull described by data gravity.
Resilience claims deserve the same scrutiny. An application that has never run at the second provider against that provider's copy of the data cannot be assumed to fail over to it. Until that switch has been exercised, cross-cloud availability remains untested.
What makes the data portable
Two conditions turn portability from an assumption into a property. First, the exit is priced before entry: the cost of reading the full dataset out of each provider, using the scenarios under cloud migration. Second, primary data sits on a provider-neutral layer the organization controls, usually reached through the S3 API, so applications in any cloud read from one place and no proprietary storage interface sits between data and application. Cloud services then consume the data without owning it. The trade is latency: a service in one cloud reading from a neutral layer elsewhere crosses a network on every request, so the layer sits close to the clouds that read it most, often in a colocation facility with direct links to each provider.
Running several providers as one
Cost and identity are the first gaps. Each provider bills differently, and a single view of spend in cloud cost management needs consistent tags across all of them. One directory and one policy language prevent permissions from drifting apart. Security baselines are the third: encryption defaults, logging and public-access settings are configured differently at each provider, and an estate that relies on each team to translate them by hand ends up with as many baselines as providers. Expressing the baseline once, in code applied to every account, keeps the providers aligned.
Frequently asked questions
Is multi-cloud more expensive?
Often. Separate skills, duplicated tooling and transfer charges between providers add cost, so the reasons for using each provider need to be specific.