Two different things get called multi-cloud
The first is using different providers for different components: application servers here, email there, one managed service somewhere else. This is common, sensible and low-risk.
The second is running the same workload across two providers for redundancy or negotiating leverage. This is much harder and much less often worth it.
Conflating the two is why the topic generates so much bad advice.
Component-level multi-cloud is usually right
There is no reason to buy every capability from one vendor. Running compute on a developer cloud while sending email through a dedicated service and keeping one hyperscaler account for a managed service you cannot get elsewhere is straightforwardly good engineering.
It also isolates blast radius and makes cost attribution obvious, because each provider’s invoice maps to a clear part of the system.
Workload-level multi-cloud is genuinely hard
Running the same system on two providers means solving every problem twice, in two different vocabularies.
- Two identity models, two networking models, two sets of quotas
- Data synchronisation between clouds, plus egress charges on every byte that crosses
- Deployment tooling that has to abstract over both, usually to the level of the weaker one
- Two sets of on-call knowledge
- Loss of the managed services that made each provider attractive, because you can only use what both have
When it does make sense
- A regulatory requirement to demonstrate provider independence.
- A genuine, quantified availability requirement that a single provider’s SLA cannot meet.
- Serving regions where one provider has no meaningful presence.
- An acquisition that arrived with an existing estate.
- Specific capability that exists on one platform and nowhere else.
Notice that avoiding lock-in is not on that list. Portability bought by refusing every managed service is usually more expensive than the lock-in it prevents.
A pragmatic middle position
Keep the parts that are easy to move genuinely portable: containers rather than provider-specific runtimes, standard SQL rather than proprietary query languages, S3-compatible object storage.
Then use the managed services that save real time, and accept that moving those would be a project. That is a considered position rather than an accident.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Choosing a Cloud Region: Latency, Residency and Cost
- AWS vs DigitalOcean: Which Cloud Account Should You Buy?
- AWS vs Hetzner: Which Cloud Account Should You Buy?
- Running Client Work: One Account Per Client
Frequently asked questions
Only if implemented thoroughly, which is difficult. A partial implementation often adds failure modes rather than removing them.
By most definitions yes, and it is the version that usually makes sense.
Rarely on its own. It can, by letting you use the cheapest provider per component, but the coordination overhead offsets some of that.
