When is multi-cloud genuinely forced on you?
Less often than it is claimed, and the difference matters because a forced constraint and a strong preference produce very different architectures. A genuine constraint can be pointed at: a clause, a regulation, a region that does not exist, a capability with no equivalent. Everything else is a decision, and decisions can be revisited when the operating cost becomes clear. When the constraint is real, the useful goal is not a balanced estate but the smallest possible footprint on the second provider.
Which constraints actually force a second provider?
Six, and each can be verified by a document or a fact rather than a judgement. Customer contract terms, regulatory concentration rules, data residency where your provider has no region, a capability that exists on one platform only, a software vendor that ships to one cloud, and an acquisition that arrived with an estate. If your reason is not on this list, it is worth testing hard before committing.
The common thread is that someone outside your engineering organisation has made the decision. That is what makes the constraint durable: it does not dissolve when a new platform lead arrives with a preference, and it does not evaporate when the operating cost turns out to be higher than expected.
It follows that the first task on a forced multi-cloud programme is documentary rather than technical. Obtain the clause, the regulation or the vendor statement, read the actual wording, and identify precisely which systems and which data it covers. That scope, and not the shape of your platform, determines how much of a second provider you have to build.
| Constraint | How to verify it | What it actually forces |
|---|---|---|
| Customer contract names a provider | The signed clause and the schedule it references | That customer's data plane only, often one tenant |
| Regulator requires exit or concentration planning | The supervisory text and your own registers | A tested exit capability, not a duplicated estate |
| Data must stay in a country with no region | Provider region list against the legal requirement | Storage and processing of that dataset in that country |
| A capability exists on one platform only | A working comparison, not a feature grid | The workload that uses it, and its data path |
| Vendor software ships to one cloud | The vendor's supported deployment options | That product and its integrations |
| An acquisition arrived with an estate | An inventory of accounts, spend and owners | A containment perimeter now, a decision later |
What does a customer contract actually require?
Usually far less than the sales conversation implied. Enterprise and public sector buyers frequently ask where data is processed, who the subprocessors are, and whether an exit is possible. Those questions are answered with documentation. A clause that genuinely names a provider and forbids alternatives is less common, and when it exists it typically covers that customer's data rather than your entire product.
The distinction changes the architecture completely. If the requirement is per customer, the answer is a deployment model that can place one tenant's data plane on a nominated provider, with your control plane staying where it is. If the requirement is that your whole service runs there, you are being asked to relocate, and that should be priced as a migration with a commercial return attached to it.
It is worth negotiating before building. Many such clauses were written by procurement teams applying a template, and a specific technical answer covering residency, encryption, access control and exit will often satisfy the underlying concern. The cost of asking is one conversation. The cost of not asking is a permanent second platform.
Do regulators require multi-cloud?
Generally they require the ability to leave, not the act of running everywhere. Financial services supervision in particular focuses on concentration risk, documented exit strategies, and the demonstrated capability to move or restore a critical service within a stated period. Those obligations are satisfied by evidence and rehearsal rather than by parallel infrastructure.
That matters because a duplicated estate is an expensive way to fail the actual test. A regulator asking for an exit plan wants to see the dependency register, the identified critical functions, the documented steps, the estimated timeline, and evidence that some part of it has been exercised. An organisation with workloads on two providers and no tested exit path has spent the money and still has nothing to show.
The cases where supervision does push towards genuine multi-provider capability are narrower: services designated as critical where an inability to restore within hours would harm customers or markets. Even there, the requirement is usually a substitutable path for the critical function, which is a much smaller thing than the whole estate.
When does data residency force it?
When the law requires the data to remain within a country, and your provider does not operate a region there. This is the cleanest forcing function in the list, because it is checked against a public region list and cannot be argued away. It arises most often in specific national markets, in public sector work, and in sectors with local supervisory rules for health, financial or citizen data.
Read the requirement carefully before accepting it, because residency has several meanings and they cost different amounts. Storage at rest in the country is the narrowest. Processing in the country adds compute. Restricting operational access to nationals or to staff physically located there adds support and on-call arrangements that are usually more disruptive than the infrastructure itself. Sovereignty requirements can add a demand that the operator be legally insulated from foreign jurisdiction, which some providers address with dedicated partner-operated regions.
The design consequence is a split, not a duplication. The regulated dataset and the processing that touches it live in the required jurisdiction, and everything else stays where it is, with a deliberately narrow interface between them. The residency guidance for hybrid estates applies here in the same way.
Is a capability gap ever a real reason?
Yes, and it is the fastest growing one, but it needs testing rather than asserting. Providers differ genuinely in a few areas: available machine learning accelerators and their supply, specific hosted models and their terms, certain data and analytics products, and regional availability of both. A workload that depends on one of these has a real reason to sit where the capability is.
The test is whether the alternative was tried. Feature comparison grids overstate differences because every provider ships something with a similar name, and understate them because the differences that matter are quotas, regional availability, throughput limits and commercial terms rather than function lists. Run the workload on both for a week with your own data before concluding that only one platform can do it.
When the gap is real, place the workload and nothing else. A model inference service on a second provider does not require your identity platform, your data warehouse or your CI system to move. The interface is an API call and a data path, and keeping it that narrow is the difference between a placement decision and a second estate.
How small can the forced footprint be?
Usually much smaller than the first proposal. The pattern that works is a single-purpose landing zone on the second provider: one account or subscription structure, one network, workload identity federated from your existing directory, logs shipped to your existing destination, and no new tooling. The second provider becomes a place where a defined workload runs, not a second home for your platform.
Decide deliberately what does not follow the workload across. The default answer for CI, secret management, observability, cost reporting and access review is that they stay central and reach across, because duplicating them is where multi-cloud operating costs actually accumulate. Data replication should be one direction and one dataset, defined explicitly, rather than a general connection between environments.
Then write down the condition under which the footprint would be removed. If the constraint is a customer contract, the condition is that contract ending. If it is a capability gap, it is your primary provider shipping an equivalent you have tested. Constraints expire, and estates built without an expiry note tend to outlive the reason they exist by several years.
Common questions
- What are legitimate reasons to run on two cloud providers?
- Six can be verified rather than argued: a customer contract that names a provider, regulatory concentration or exit obligations, data residency in a country where your provider has no region, a capability that genuinely exists on one platform only, a software vendor that ships to one cloud, and an acquisition that arrived with an existing estate. Each is decided by someone outside engineering, which is what makes it durable.
- Do financial regulators require multi-cloud?
- Generally they require a demonstrated ability to exit or restore a critical service, not parallel infrastructure. Supervisors ask for a dependency register, identified critical functions, a documented exit plan with timelines, and evidence that it has been exercised. An organisation running on two providers with no tested exit path has spent the money and still cannot answer the question, which makes rehearsal the cheaper route to compliance.
- Does data residency require a second cloud provider?
- Only when the law requires data to remain in a country where your provider has no region. Check the wording first, because residency has tiers that cost very differently: storage at rest in country, processing in country, operational access restricted to local staff, and sovereignty requirements that the operator be insulated from foreign jurisdiction. The result should be a narrow split for the regulated dataset rather than a duplicated estate.
- Is a missing feature a good reason to add a cloud provider?
- Sometimes, once it has been tested rather than read from a comparison grid. Real differences tend to be quotas, accelerator supply, regional availability, throughput limits and commercial terms rather than the presence or absence of a service. Run the workload on both platforms with your own data for a week before concluding. If the gap holds, move that workload alone and keep the interface to an API call and a defined data path.
- How do you keep forced multi-cloud from spreading?
- Build a single-purpose landing zone rather than a second platform: one account structure, one network, workload identity federated from the existing directory, and logs shipped to the existing destination. Keep CI, secrets, observability and cost reporting central and reaching across, since duplicating those is where operating cost accumulates. Then record the condition that would end the footprint, because constraints expire and undocumented estates outlive their reasons.
