Do you actually need multi-cloud?
For most organisations, no, and the reason is that the costs arrive immediately while the benefits arrive conditionally. A second provider means a second identity model, a second network, a second billing structure, a second set of on-call knowledge and a second security baseline, all of which are paid every month from the day you start. The benefits, resilience and bargaining power and optionality, are only realised in situations that may never occur. That trade is sometimes worth making, and it is worth being precise about when.
What counts as multi-cloud?
Running your own workloads on more than one provider's infrastructure, where both are load-bearing. That is a narrower definition than the word is usually given, and the narrowness matters, because most organisations described as multi-cloud do not meet it and do not carry its costs.
Using Salesforce, Workday, GitHub and Snowflake alongside AWS is not multi-cloud. Those are SaaS products, and where a vendor chose to host is not your operational problem. Neither is a marketing team with a Firebase project, a data science group with a BigQuery account, or one legacy application still on a provider you left. Those are separate estates that happen to be billed to the same company.
The distinction is about whether a request or a dataset crosses the boundary in normal operation. If nothing crosses, you have two estates and the correct strategy is usually to govern each on its own terms. If things cross, you have one system spanning two providers, and everything in this cluster applies.
What does a second provider cost before it runs anything?
A landing zone, an identity design, a network, a security baseline and a group of people who know the platform well enough to be woken up. None of that is optional and none of it is proportional to how much you run there. A single application on a second provider needs roughly the same foundation as fifty applications do.
The specific duplications are worth naming because they get omitted from business cases. Account or subscription structure and guardrails. Logging and its destination, with a different event schema on each side. Network address planning that does not overlap with the first provider. Certificate and secret management. Backup policy. Cost allocation and tagging conventions that produce comparable reports. Incident runbooks written for a different console. A second on-call rotation, or one rotation carrying twice the surface area.
There is also a commercial cost that surprises finance teams more than engineers. Committed spend agreements are priced on volume with one provider, so splitting an estate across two can move you into a worse discount tier on both, and the effective list-price uplift can exceed the infrastructure saving that motivated the split.
Does running on two providers make you more available?
Not by itself, and often the opposite in the first year. Availability comes from an architecture that can lose a component and keep serving, plus a failover path that has been rehearsed. A second provider adds a component: the link between them, the identity federation across them, and the DNS layer that decides where traffic goes. Each is a new way to fail, and each fails in ways your team has not seen before.
It also matters which failure you are actually worried about. Provider-wide outages are rare compared with regional events, and rarer still compared with the failures that cause most real downtime: a bad deployment, an expired certificate, a schema migration, a misconfigured permission, a saturated database. A second provider addresses none of those, and multi-region within one provider addresses regional events at a fraction of the cost.
The honest version of the resilience argument concerns correlated failures that are not regional: a global control plane or identity outage, an account suspension, or a provider-level security event. Those are real, they are the subject of the disaster recovery guide, and they justify a specific and usually small piece of cross-provider capability rather than a duplicated estate.
What do people usually mean when they ask for it?
Six things, and only two of them require a second provider. Sorting the request into the right row is most of the work, and it can be done in one meeting if someone is willing to ask what specifically goes wrong if the answer is no.
| Stated reason | What it usually means | Needs a second provider? | Cheaper answer |
|---|---|---|---|
| We cannot depend on one vendor | Nobody has priced an exit | No | Cost the exit annually, keep data in open formats |
| We need better uptime | A regional or deployment failure hurt us | Rarely | Multi-region and a rehearsed failover in one provider |
| We want a better negotiating position | Renewal is approaching | Sometimes | A credible costed migration plan, presented at renewal |
| A customer or regulator requires it | A clause exists somewhere | Yes, if the clause says so | Read the clause before designing anything |
| One provider has a capability we need | A specific model, region or service | Yes, for that workload only | Place that workload there, leave the rest alone |
| We already are, after an acquisition | An estate arrived with a company | Yes, temporarily | Inventory and contain first, decide consolidation later |
When is one provider clearly enough?
When your workloads have no placement constraint, your customers do not name a provider in contracts, your data has no residency requirement your current provider cannot meet, and your recovery objectives can be met across two regions. That describes the majority of businesses, including large ones.
It is also enough when the honest answer to "who would run the second one" is the same team that is already stretched. Multi-cloud is an operational commitment before it is an architectural one, and a platform team that cannot yet demonstrate consistent tagging, working infrastructure as code and a tested restore on one provider will not achieve those things faster across two.
One provider does not mean one region, one account or one blast radius. Most of the resilience people hope to buy with a second vendor is available inside a single one through account separation, multi-region data, and the discipline of being able to rebuild an environment from code. Those are the prerequisites for multi-cloud anyway, which makes them the right first spend regardless of the eventual answer.
How do you decide this afternoon?
Write the sentence "if we stay on one provider, the specific thing that happens is X". If X is a named contract clause, a named regulator, a named capability that exists nowhere else, or a named acquisition, you have a case and the rest of this cluster tells you what it costs. If X is a general feeling about risk or dependency, you have a preference, and preferences do not survive contact with a second on-call rotation.
Then run a second test on money. Ask your account team what your effective discount would be at sixty percent of current committed spend, and compare that with the list-price saving that motivated the split. Many multi-cloud cost cases are already negative at this step, before any engineering time is counted.
Finally, price the exit you are actually afraid of. Estimate what it would cost to move your largest workload to another provider today: data transfer, engineering months, dual running, and retraining. That number is the value of the option you are considering buying continuously. If it is smaller than a year of running a second platform, buy the option later, when you need it.
Common questions
- What is multi-cloud?
- Running your own workloads on more than one cloud provider, where both are load-bearing in normal operation. Using SaaS products hosted elsewhere does not count, because where a vendor chose to host is not your operational problem. Neither does a stray project on a second provider that nothing else depends on. The test is whether a request or a dataset crosses the boundary during normal running.
- Does multi-cloud improve uptime?
- Not on its own, and often it reduces uptime in the first year. Availability comes from an architecture that tolerates component loss plus a rehearsed failover path. A second provider adds components: the interconnect, the identity federation and the traffic steering layer, each a new failure mode. Most real downtime comes from deployments, certificates, migrations and permissions, none of which a second provider addresses.
- How much does adding a second cloud provider cost?
- The fixed foundation costs the same whether you run one workload there or fifty: account structure and guardrails, identity design, non-overlapping network addressing, logging with a different event schema, secrets, backup policy, tagging for comparable cost reports, and people who can be woken up for it. The commercial cost is often larger, because splitting committed spend can move you into a worse discount tier with both providers.
- Is multi-cloud worth it for avoiding vendor lock-in?
- Rarely as a first move, because running a second platform is a continuous payment for an option that is usually never exercised. The cheaper version is to price the exit: estimate what moving your largest workload would cost today in transfer, engineering months and dual running, and re-check that figure annually. If it is less than a year of operating a second platform, buy the option when you need it rather than in advance.
- When do you not need multi-cloud?
- When no workload has a placement constraint, no customer contract names a provider, your data residency needs are met by your current provider's regions, and your recovery objectives can be achieved across two regions. That covers most organisations. It is also the answer when the team that would operate the second platform cannot yet demonstrate consistent tagging, working infrastructure as code and a tested restore on the first one.
