Multi-cloud strategy

Multi-cloud strategy is the deliberate choice to run workloads on more than one public cloud provider. It is not hybrid cloud, which mixes private and public, and it is not a migration plan; it is a standing choice you fund every year.

Most firms arrive at it by accident first — an acquisition brings a second provider, a team picks a managed service only one vendor offers, and the estate spans two clouds before anybody writes a plan.

A strategy turns that into a decision. You name which workloads sit where, what has to stay portable, and what you are content to let a single provider own outright.

Set the rule before the next workload lands. A default provider, a short list of reasons to deviate, and a named approver is what stops an estate growing a third cloud through drift.

Key takeaways

• Multi-cloud means two or more public providers; hybrid means private plus public.
• Most estates become multi-cloud by accident, then need a strategy written after the fact.
• The cost lands on people and tooling long before it shows up in the invoice.
• Portability and managed services pull against each other, so pick the trade per workload.

How it works

A multi-cloud strategy answers three questions: which workloads go where, what must stay portable between providers, and who pays for the duplication. Everything else is implementation detail that follows from those three answers.

The reference definition is older than the trend. The National Institute of Standards and Technology (NIST) describes cloud computing as on-demand network access to a shared pool of configurable computing resources, in a publication dated September 2011.

That NIST document names five essential characteristics, three service models and four deployment models. It does not prescribe how many providers you use, because provider count is a procurement decision layered on top of the model.

Google Cloud’s hybrid and multicloud architecture guide, last reviewed in October 2024, makes the vendor argument plainly: adding public cloud services to what you already run lets you avoid committing yourself to a single cloud vendor.

The bill for this is real — every added provider means another identity model, another network design and another rota, which is why cloud managed services and infrastructure outsourcing grew in step with it.

Design work lands with a cloud architect, who decides what gets abstracted and what does not. Abstract everything to stay portable and you lose the managed services that made each cloud worth buying.

Portability is a spectrum rather than a switch. Containers and open table formats move compute and data with modest pain, while identity, networking and managed databases are where providers differ most and lock in really bites.

Skills are the quiet constraint — a team fluent on one provider is competent, not expert, on the second, and that gap shows itself during an incident rather than during a planned migration.

Placement is the other half. Workloads with strict residency or control requirements often go to private cloud outsourcing, while elastic public services sit in public cloud outsourcing arrangements where capacity is cheap.

Examples

Three settings show the strategy being chosen rather than inherited: regulated banking, retailers competing with a cloud provider, and public bodies bound by rules about where data may physically sit. Each one starts from a constraint, not a preference.

Banking supervisors have pressed firms on concentration risk since the late 2010s, asking what happens when one provider fails. A second cloud, with tested failover for the critical services, is the usual answer.

Retail has a commercial reason rather than a technical one — large chains have long avoided putting core systems on a cloud run by a direct competitor, which pushes them toward a second or third provider.

Public sector buyers in the European Union split estates by jurisdiction. Where rules require data to stay inside a member state, the provider with a region there wins that workload, whatever runs everywhere else.

Software vendors face a customer requirement rather than a preference. Buyers in regulated sectors increasingly ask which cloud a product runs on, so vendors build a second deployment target purely to stay eligible for those contracts.

Related terms

• Multi sourcing model: splitting one function across several suppliers, of which clouds are a single case.
• Cloud engineer: builds and runs what the architect designed, on each provider in the estate.
• Cloud architect: owns the placement and portability calls this strategy turns into standing rules.
• Cloud managed services: the outsourced run function that keeps a multi provider estate supportable.
• Infrastructure outsourcing: hands the hardware and platform layer to a partner, on one cloud or several.

FAQ

Is multi-cloud the same as hybrid cloud?

No. Hybrid mixes private infrastructure with public cloud, while multi-cloud means two or more public providers, whether or not any private estate exists.

Does a multi-cloud strategy reduce outage risk?

Only where you have tested failover for the service in question. Running two providers without a rehearsed switch gives you two things to monitor and no extra resilience.

What does it actually cost?

Expect duplicated tooling, duplicated skills and charges when data crosses between providers. Budget for the people well before the licences, because the second estate needs the same coverage as the first.

When is one cloud enough?

When you have no residency conflict, no competitor problem, and no regulator asking about concentration risk. Plenty of smaller firms sit comfortably here, and a single provider run well beats two run badly.

Can a partner run it for us?

Yes, and a managed provider can hold the run function across every provider in the estate. Keep architecture decisions and contract terms with your own team.

Compare vetted cloud and infrastructure partners in the Outsource Accelerator directory before you add a second provider.