The question this answers
What concrete business requirement would justify running this system on more than one cloud provider?
A board member read that a large provider had a multi-hour outage and asked why the company is "dependent on one vendor". Nobody in the room has yet stated a requirement — only a fear.
When it is genuinely warranted: independence from one provider's control plane, contractual or regulatory coverage, or access to one managed service that only exists in one place. When it is not warranted, it provides a second of everything to operate.
Start with the requirement, or do not start
Multi-cloud is the clearest case in this domain of infrastructure chosen for a feeling rather than a requirement. So the lesson begins with the test: write down, in one sentence, the business requirement that a single provider cannot satisfy. If the sentence is "we do not want to be locked in", that is not a requirement — it is an anxiety, and the next section prices it. If the sentence names a regulator, a signed contract, an acquisition or a specific service, you have a real reason and the rest of this lesson is about doing it properly.
The honest reasons do exist and they are not rare. A public-sector or financial customer contractually requires a second provider or a documented exit plan. A regulator requires that a workload run in a jurisdiction where your primary provider has no presence. An acquisition brought you a production system on another provider, and rewriting it is not worth the money. One managed service — a specific database, a specific ML platform, a specific compliance certification — genuinely exists only in one place, and the workload that needs it is small and separable. Each of those is a defensible answer, and each produces a *bounded* multi-cloud footprint rather than a duplicated platform.
What is much rarer than people believe is the reliability argument. Two providers do not make one system more available unless the system can actually run on either at the moment of failure, with current data, and someone has tested it. What teams usually build instead is a system that depends on *both* — a service here, a database there, traffic crossing between them — which multiplies the failure surface rather than dividing it. Most large outages, in any case, are caused by a bad configuration change or an expired certificate propagated by the team, and a second provider does nothing about either. See High Availability and Failure Domains for what actually buys availability.
| Stated reason | Honest? | What it really requires | What it costs |
|---|---|---|---|
| A regulator requires a second jurisdiction our provider does not serve | Yes | One workload, one region, on a second provider | Bounded — a separate deployment, not a portable platform |
| A signed customer contract requires a documented second provider | Yes | A tested exit or standby plan, possibly not live traffic | Moderate — a rehearsal cadence and an owner |
| An acquisition brought a production system on another provider | Yes | Two estates run in parallel, deliberately, with a sunset date or none | Two on-call surfaces, two bills, two IAM models |
| One managed service we genuinely need exists in one place | Yes | One service consumed across a private link | Cross-provider networking and egress on a hot path |
| To avoid vendor lock-in | Rarely | Portability everywhere, which means using the worst common denominator | Managed services you cannot use, and a platform team to replace them |
| For higher availability | Rarely | Full active-active with replicated data and tested failover | More than active-active in one provider, for the same result |
| To negotiate better pricing | Sometimes | Credible ability to move one workload, not all of them | Usually smaller than the engineering cost of real portability |
What actually has to be duplicated
The reason multi-cloud costs so much more than it looks is that the compute layer — the part everyone thinks about — is the easy part. Containers run anywhere. What does not port is everything underneath and around them: the virtual network model and its address planning, the identity system and its policy language, the secret store, the load balancer's behaviour and certificate handling, the managed database's replication and backup semantics, the observability pipeline, the infrastructure-as-code providers, the cost model, and the on-call runbooks that assume all of the above.
Identity is the sharpest example. Each provider has a different policy language, a different way of granting a workload an identity, and a different audit format. A least-privilege policy written for one does not translate; it must be re-derived, re-reviewed and re-audited. Now every access-control question in the company has two answers, and the failure mode is not that the second one is wrong — it is that nobody notices it drifted from the first.
Then there is the data. Cross-provider traffic is metered egress on the way out, arrives over the public internet or a paid interconnect, and adds tens of milliseconds to every hop. An architecture that puts the application on one provider and the database on another is not multi-cloud; it is a distributed system with a slow, expensive, third-party-dependent link in the middle of its hot path. If you take one operational rule from this lesson: keep a workload and its data on the same provider, and let the seam fall between workloads rather than through one.
The price of "avoiding lock-in"
The lock-in argument deserves a specific answer rather than a dismissal. Lock-in is real: a managed queue, a proprietary database or a serverless platform genuinely makes leaving harder. The question is what the insurance costs relative to the risk. Full portability means refusing every differentiated managed service and rebuilding it yourself on the lowest common denominator — running your own database instead of a managed one, your own queue, your own secret store, your own observability stack. You have not avoided lock-in; you have relocated it, from a vendor with an on-call rota to a small internal platform team with none.
The proportionate answer is almost always the middle one. Keep the *data* portable, because data gravity is the thing that actually traps you: standard formats, exportable backups, a documented and periodically rehearsed export. Keep the application deliberately boring at its boundaries — containers, standard protocols, an interface in front of anything exotic. Then use the managed services, because they are the reason to be on a cloud at all. The exit cost you are buying down is a migration project, and a migration project is a known quantity; see The Five Dispositions.
Write the decision down, whichever way it goes. The most valuable artifact this lesson produces is a short record naming the requirement, the option chosen, the alternative rejected and the cost accepted — because in eighteen months somebody will ask why the platform team is twice the size it needs to be, and "a board member was worried in 2024" is not an answer anyone can act on.
DECISION: second cloud provider for the settlement workload
DATE: 2026-03-11 OWNER: platform REVIEW: 2027-03
REQUIREMENT Customer contract 4417 s.9 requires settlement data to be
processed in-country. Provider A has no region there.
SCOPE Settlement service and its database only. Approx 4% of the
estate. Everything else stays on Provider A.
REJECTED (a) Full portability across both providers — would remove
managed database and queue from the whole platform.
(b) Wait for Provider A to open a region — no committed date.
ACCEPTED COST Second IAM model and audit trail; second IaC provider;
on-call runbooks duplicated for one service; interconnect
charges on async replication; ~1 engineer of ongoing load.
NOT CLAIMED This does not improve availability. Provider A remains a
single point of failure for 96% of the estate, by choice.
REVISIT IF Provider A opens an in-country region, or contract 4417 ends.Key points
- Multi-cloud is not automatically more reliable — it is more surface, and most large outages come from your own change, not the provider's.
- Write the business requirement in one sentence first. "Avoid lock-in" is an anxiety, not a requirement.
- The honest reasons are specific: a regulator, a contract, an acquisition, or one managed service that exists in one place.
- Compute ports easily; networking, identity, secrets, observability, IaC and runbooks do not — that is where the cost lives.
- Keep a workload and its data on the same provider; put the seam between workloads, never through a synchronous hot path.
- The proportionate version of lock-in insurance is portable data and boring boundaries, not refusing managed services.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Each provider gets its own network address plan, chosen up front so ranges never overlap when they are eventually connected.
- • Workloads are packaged as containers so the compute layer is genuinely portable, and everything provider-specific is pushed to the edges.
- • Identity is modelled twice, in two policy languages, with a documented mapping and a review that checks the two have not drifted apart.
- • Connectivity is a private interconnect or VPN, treated as a metered, latency-adding shared dependency rather than as a local network.
- • Observability is centralized into one pipeline that ingests both estates, because two dashboards mean nobody knows which one is telling the truth.
- • Infrastructure-as-code uses separate provider configurations, and environments are defined per provider rather than abstracted into one fictional interface.
- • Two upgrade calendars, two deprecation notices, two sets of quotas and two support relationships.
- • Two IAM models to keep least-privilege in, with an explicit periodic reconciliation — drift here is silent.
- • Runbooks that name the provider in every step, because "restart the load balancer" means different things in each.
- • A hiring and training obligation: engineers must be competent in both, or the second estate is operated by one person who cannot go on holiday.
- • Cost attribution across two billing models that categorize things differently, which finance will need reconciled.
- • A rehearsal cadence if the justification was failover, because an untested standby is a claim, not a capability.
- • The interconnect degrades and a synchronous cross-provider call turns a local latency problem into a distributed one; both estates look healthy in isolation.
- • IAM drift: a policy tightened on one provider and forgotten on the other, discovered during an audit rather than an incident.
- • A "failover" to the second provider that has never been rehearsed, attempted during an outage, and found to be missing data, DNS or capacity.
- • Egress charges appearing in a quarterly review after a chatty service was deployed across the seam.
- • Expertise concentration: the one engineer who understands the second estate leaves.
- • Lowest-common-denominator architecture quietly making the primary estate worse, because the good managed service was rejected for portability.
- • Operational load scales with the number of *distinct* platforms, not with traffic — the second provider costs roughly the same whether it serves 1% or 40% of the load.
- • Cross-provider data transfer scales with chattiness, which grows faster than traffic when services are split badly.
- • Team expertise is the dimension that runs out first: it is the one you cannot buy with capacity.
- • A bounded footprint scales fine; a fully portable platform gets harder to change as each new capability must be built twice.
- • Two identity systems means two blast radii, two audit trails and two places a misconfiguration can hide.
- • The interconnect is a new trust boundary — traffic across it should be authenticated and encrypted, not trusted because it is "internal".
- • Secrets now live in two stores with two rotation mechanisms; a rotation that succeeds in one and fails in the other is a classic partial-failure incident.
- • A wider aggregate attack surface: two public edges, two control planes, two sets of credentials that CI must hold.
- • On the credit side, a genuine compromise of one provider's control plane does not automatically reach the other — but only if the CI identity that can deploy to both is itself well protected, and usually it is not.
- • Two fixed platform costs: baseline resources, support plans and minimum footprints on each side.
- • Cross-provider egress, charged on the way out and frequently on a hot path nobody intended to create.
- • Duplicated engineering effort on every platform capability — the largest cost and the one never budgeted.
- • Lost discounts: committed-use pricing rewards concentration, so splitting spend can cost more per unit on both sides.
- • Opportunity cost of the managed services rejected for portability, paid as salary rather than as a cloud bill.
- • One observability pipeline covering both estates, with the provider as a dimension on every metric.
- • Cross-provider request latency and error rate as an explicit service-level indicator, because it is a dependency you invented.
- • Interconnect throughput and cost, trended, as the early warning for accidental chattiness.
- • IAM policy diff between the two estates, reviewed on a schedule — this is a monitored artifact, not a one-time migration task.
- • The signal that lies: per-provider status dashboards, each green, while the path *between* them is what is broken.
- • One provider, multiple regions. This buys real geographic redundancy with one identity model, one network model and one set of runbooks, and it is the right answer for the large majority of availability requirements. See Multi-Region Deployment.
- • One provider plus a documented, rehearsed exit plan. This satisfies most contractual "no lock-in" clauses at a fraction of the cost of running a second estate.
- • A bounded second footprint: exactly the one workload the requirement names, on the second provider, with no expectation of portability elsewhere.
- • Portable data with provider-specific infrastructure — standard formats and rehearsed exports — which addresses data gravity, the part of lock-in that actually traps you.
- • Doing nothing, and writing down why. A recorded decision not to go multi-cloud is a legitimate and often correct output of this analysis.
- • Buys independence from one vendor's decisions; costs a second of every platform capability, permanently.
- • Buys a negotiating position; costs more in engineering time than the discount is usually worth.
- • Portability buys optionality; costs the managed services that were the reason to use a cloud in the first place.
- • A bounded footprint keeps the cost proportionate but gives up the availability story people imagined they were buying.
What people believe, and what is true
Multi-cloud means we survive a provider outage.
Only if the system can run entirely on either provider with current data, and only if you have rehearsed it. Most multi-cloud systems depend on both and are therefore less available, not more.
Kubernetes makes us provider-independent.
It makes the compute layer portable. Load balancers, identity, secrets, storage classes, managed databases and observability are still provider-specific, and they are most of the work.
Avoiding lock-in is free if we just use open standards.
It costs every managed service you decline and every replacement you build and operate. Lock-in moves from a vendor to your own platform team.