The multi-cloud question arrives as a risk question: what happens if one provider has an outage, changes its terms, or prices us out? It gets answered as an architecture question, which is why so many programs stall halfway. The useful version is narrower and more tractable. For each workload, what actually has to run where, and what does moving it cost?
Most enterprises end up with two clouds for reasons that have nothing to do with portability: an acquisition, a data-residency requirement, a vendor commitment, or a specialist service that only one provider does well. That is fine. The mistake is treating the resulting estate as a portability program instead of a placement discipline. Placement asks where each workload should live given its constraints. Portability asks whether it could move anywhere, and then pays for that option forever.
The portability promise and the invoice that follows
Containers genuinely port. A stateless service in a standard image, with configuration injected at runtime, moves between providers in days and usually runs better on the second cloud because the second attempt is better designed. That is the part of the promise that holds.
Almost everything else resists. Managed warehouses, managed queues, managed identity, private networking, serverless eventing, and accelerator capacity all carry provider-specific behavior. The abstraction layer that hides the differences tends to hide the useful parts too: you get the lowest common denominator of networking, observability, and permissions, and you pay a team to maintain the veneer. The option is not free, and the invoice arrives every month in the form of extra platform work.
Data gravity is a budget line
Data has weight. The larger the dataset, the more applications, reports, and engineers cluster around it, and the more expensive it becomes to move. Two costs do the damage: the transfer itself and the recomputation after it.
List rates for internet egress from the major clouds have hovered near nine cents per gigabyte for the first tier in US regions, with volume tiers, destination, and network tier changing the number. Inbound is usually free. Cross-region and cross-zone traffic is metered separately, and private endpoint services add their own per-gigabyte charge on top: AWS PrivateLink, for example, lists about one cent per gigabyte processed for the first petabyte, plus per-endpoint hourly charges.
Worked example, and these are assumptions, not quotes: a 20 TB analytics replica refreshed with a 10% monthly delta generates about 2 TB of cross-cloud transfer per month, which at nine cents per gigabyte is roughly $184, plus the initial 20 TB seed at about $1,840. Those numbers are survivable. Now put a 60 TB data lake into a cross-cloud replication design: about 61,440 GB a month at the same rate is roughly $5,530 a month, before anyone queries it. The architecture that looked like resilience becomes a permanent line item, and storage is the cheap part.
Control planes do not port
This is the part that surprises platform teams. The data path can be made portable with open source. The control plane usually cannot. Managed Kubernetes is the standard example: the API surface looks similar, but node pools, load balancer integration, identity bindings, autoscaling behavior, and upgrade mechanics are provider-specific. A cluster definition is portable in theory and a week of work in practice, which is close enough to not portable when you have forty of them.
Managed identity is worse. Authorization models differ at the level of how a policy is expressed, how roles attach to resources, and where the boundary of trust sits. A policy written for one provider's model does not translate mechanically to another's. The same applies to managed queues, managed stream processing, hosted model endpoints, and anything with provider-supplied SDKs at the core of its retry or credential logic.
Serverless is a useful test case. A function is small, so the rewrite looks cheap. But the value sits in the surrounding bindings, the event sources, the queues, the permission model, and the deployment pipeline. Moving the function is easy; moving the system around it is the project.
Identity is the real lock-in
Federation is the good news. Most enterprises already run an identity provider and can federate with each cloud using SAML or OIDC, so a person can sign in to both without a second password. Provisioning with SCIM works well enough. That part of multi-cloud identity is a solved problem, and it is why leaders sometimes conclude that identity is portable.
The lock-in lives one layer down. Human login is federated; the authorization model is not. Group-to-role mappings, resource hierarchies, policy languages, and the audit trail format are all provider-specific, and workload identity is more specific still. A service running in cloud A assumes a native identity to reach cloud B, which means cross-cloud trust, which means a second set of credentials, rotation rules, and failure modes that your security team now has to review in two dialects.
There is a practical test. Ask how a service in one cloud authenticates to a managed resource in the other, and count the number of credentials involved. If the answer includes a long-lived key stored somewhere, the design has created the exact standing privilege that zero-trust programs exist to remove.
DR is not the same thing as multi-cloud
Disaster recovery is specified with two numbers: recovery time objective, how long the workload can be down, and recovery point objective, how much data you can lose. The standard pattern ladder runs from backup and restore, through a pilot light and a warm standby, to an active-active design, and each rung costs more and recovers faster.
Multi-cloud is often proposed as the top rung, and it is usually the wrong way to buy it. A second cloud adds a new failure domain, a new control plane, a new network, and a new runbook, and it requires the data to be replicated there, which brings back the egress bill from earlier. It also creates a recovery path that is exercised rarely and owned by nobody. Unless the risk you are hedging is specifically a provider-level failure, a second region in the same cloud, with the same tooling and the same team on call, delivers better recovery per dollar.
There are honest reasons to run cross-cloud DR: regulatory insistence on provider independence, a genuine concentration concern raised by your board, or a workload whose data already lives in two places. Those are decisions to make explicitly, with the replication cost modeled and the failover runbook tested at least once a year.
Workload placement: a table you can defend
The table below is a placement default, not a rule. Use it to have the argument once per workload instead of once per quarter.
| Workload | Where it usually lands | Binding constraint | What breaks if forced elsewhere |
|---|---|---|---|
| System of record (ERP, CRM) | One cloud or on-premises, single primary region | Data gravity and vendor licensing | Licensing, integrations, and latency |
| Analytics warehouse and lake | The cloud that already holds the data | Egress and recomputation | A five-figure monthly transfer bill |
| Latency-sensitive inference | Several regions inside one cloud | Accelerator capacity and network distance | Cold starts, capacity shortfalls, worse tail latency |
| Batch training and fine-tuning | Wherever capacity is available and cheapest | Quota and spot availability | Training data egress and job restarts |
| Stateless application services | Anywhere; usually one cloud by default | Team skills, not technology | Little, which is why moving is rarely urgent |
| Regulated data workloads | In-country region, one or two providers maximum | Residency and audit evidence | Duplicate controls and duplicated audits |
| DR standby | Second region in the same cloud; second cloud only for a narrow tier | Recovery time and data loss targets | Untested runbooks and replication cost |
Read the table as a set of arguments to settle once. The system of record is a decision about licensing and gravity, and pretending otherwise wastes a year. The analytics warehouse is a decision about egress, and the number is knowable in an afternoon. Latency-sensitive inference is a capacity decision that changes with the market, so it should be revisited on a schedule rather than re-litigated per incident.
What to do next
- Tag every workload with a single binding constraint: gravity, latency, residency, licensing, or skills. If a workload has two, you have not decided yet.
- Price the top three cross-cloud data flows at current list rates and put the monthly number in the architecture review, not in a footnote.
- Inventory cross-cloud credentials and count the long-lived ones. Each is a project with a deadline.
- Write the RTO and RPO for your top ten workloads, then check which of them actually need a second provider rather than a second region.
- Test one failover this quarter and record how long it took, including the human time to decide, not just the technical recovery.
Multi-cloud is a portfolio of specific decisions, not a posture. Decide where each workload should run, price the seams between them, and stop funding portability you will never exercise. The organizations that get this right usually run fewer clouds than they planned, and know exactly why each remaining one is there.
