Table of Contents
- The Lock-In Argument Examined
- What Multi-Cloud Actually Costs
- The Lowest Common Denominator Problem
- Lock-In Has Degrees
- When Multi-Cloud Is Genuinely Justified
- Portability Without Multi-Cloud
- What Migration Actually Involves
- A Defensible Position
- Common Pitfalls
- Conclusion
- Frequently Asked Questions
Key takeaway: Multi-cloud as insurance against lock-in means paying continuously — in duplicated infrastructure, doubled operational expertise, egress charges, and abandoned managed services — to avoid a one-time migration cost you will probably never incur.
The Lock-In Argument Examined
The reasoning for multi-cloud is usually presented as risk management. Depending on one provider creates exposure: they could raise prices, degrade service, change terms, or suffer an outage. Spreading across providers reduces that exposure.
Each concern is real. The question is whether the mitigation costs less than the risk it addresses, and this is where the argument is rarely worked through.
Consider what the mitigation actually requires. Infrastructure defined twice, or defined once in a way that uses neither provider well. Operational expertise in two ecosystems, including two identity models, two networking models, and two sets of failure modes. Data either duplicated, with egress charges to keep copies synchronised, or centralised, in which case one provider is a dependency anyway. Tooling that works across both, which frequently means the least capable option. And managed services abandoned in favour of self-hosted alternatives, because equivalents differ.
Against that continuous cost, the risk being avoided is a migration you may never perform. And critically: the multi-cloud architecture does not eliminate that migration cost — it pays a portion of it continuously, forever, in exchange for reducing the eventual amount.
That trade can be correct. It usually is not, and it is worth calculating rather than assuming.
What Multi-Cloud Actually Costs
The costs are concrete and mostly ongoing:
Duplicated infrastructure. Running meaningful capacity in two providers means paying for capacity in both, with utilisation split. Reserved capacity discounts, which require commitment, become harder to justify when demand is divided.
Egress charges. Moving data between providers is billed, generally at rates substantially above intra-provider transfer. An architecture where services in one cloud query data in another pays continuously for every request.
Doubled operational surface. Two identity systems, two networking implementations, two monitoring integrations, two sets of quotas and limits, two support relationships. Every operational procedure needs a variant for each.
Expertise cost. Deep knowledge of one cloud is expensive to hire. Deep knowledge of two, in the same team, is considerably more so. In practice teams end up with shallow knowledge of both, which produces worse architecture than deep knowledge of one.
Slower delivery. Every design decision must consider two implementations. Features that would use a managed service require building something portable instead.
More failure modes. Cross-cloud networking, replication lag between providers, and inconsistent behaviour between environments are new categories of incident that a single-cloud architecture does not have.
That final point deserves emphasis. Multi-cloud is frequently justified by resilience, and the added complexity introduces failure modes that would not otherwise exist. Whether net resilience improves is genuinely uncertain and rarely measured.
The Lowest Common Denominator Problem
The most consequential cost is architectural rather than financial.
Building for portability means using only capabilities available equivalently across providers. In practice that means compute, object storage, and basic networking — the commodity layer. Everything above it either differs enough to be non-portable or must be self-hosted.
The services you give up are the ones providing most of the value:
| Instead of | You self-host and operate |
|---|---|
| Managed relational database | Database on instances, with backup, failover, patching |
| Managed queue or stream | Message broker cluster |
| Managed identity and access | Your own authentication and authorisation layer |
| Serverless functions | Container platform with your own scaling |
| Managed data warehouse | Query engine and storage layer |
| Managed monitoring | Observability stack as a production system |
Each row is a team’s worth of operational work replacing something a provider operates for you. The cumulative effect is that a portable architecture requires substantially more people to run and delivers less capability.
The pattern worth naming: teams that adopt multi-cloud for portability frequently end up operating a private platform on rented hardware. That is a legitimate choice with real advantages, and it is a different decision from the one they thought they were making, and it should be evaluated on its own terms rather than as lock-in avoidance.
Lock-In Has Degrees
Treating lock-in as binary obscures the useful analysis. Different dependencies have very different exit costs.
Low switching cost. Compute instances, object storage, virtual networking, load balancers. Conceptually similar everywhere; migration is mechanical work.
Moderate switching cost. Managed databases with standard engines, container orchestration, CI systems. Same interfaces, different operational tooling.
High switching cost. Proprietary data stores, provider-specific serverless models, integrated identity, managed machine learning platforms, data warehouses. No equivalent exists; migration means redesign.
Very high switching cost. Data volume itself. Egress charges on petabytes are frequently the dominant migration cost regardless of architecture. Note that this applies to multi-cloud architectures too — the data still has to move.
The productive strategy is selective rather than uniform. Accept high lock-in where the managed service provides substantial value and the alternative is operating it yourself. Reduce lock-in where it is cheap to do so — using standard database engines rather than proprietary ones, keeping business logic free of provider SDK calls, using open formats for stored data.
That last point is worth isolating: keeping data in open, portable formats addresses the highest-cost dependency at almost no ongoing expense. It is the highest-return lock-in mitigation available and it requires no multi-cloud architecture.
When Multi-Cloud Is Genuinely Justified
There are legitimate cases, and they are more specific than the general lock-in argument.
Regulatory or contractual requirement. Some jurisdictions and some customers mandate it. This is not a technical decision and the cost is simply incurred.
Acquisition inheritance. You acquired a company running elsewhere. The cost of migration may exceed the cost of operating both, at least for a period.
Genuinely different capability needs. One provider is materially better for a specific workload — a particular accelerator, a specific data service, a regional presence. Using the better tool for a distinct workload is different from architecting for portability.
Negotiating position at very large scale. Credible ability to move affects pricing. This matters at spend levels where a few percent is a large absolute number, and it does not require running production in two clouds — a demonstrated capability may suffice.
Geographic coverage. No single provider has optimal presence everywhere. Latency or data residency requirements in specific regions can force it.
Specific resilience requirements. Where a provider-wide outage is genuinely unacceptable, and you have verified that your multi-cloud implementation actually survives one, which requires testing rather than architecture diagrams.
Notice what is absent: general anxiety about lock-in, and a preference for keeping options open. Those are the most common motivations and the least defensible ones, because they justify continuous cost against an unquantified risk.
Portability Without Multi-Cloud
The useful middle position is reducing switching cost without running everywhere. Most of the benefit at a fraction of the cost.
Containerise workloads. Container images run anywhere. This is cheap, has other benefits, and removes compute portability as a concern entirely.
Use standard database engines. A standard engine on a managed service is far more portable than a proprietary store, at similar cost and operational burden.
Keep provider SDKs at the boundary. Business logic that calls provider APIs directly is entangled with the provider. The same logic behind a thin interface is not. This is ordinary good design and it happens to address portability.
Store data in open formats. Open table and file formats mean the data is readable by other tooling. Given that data is usually the dominant migration cost, this is the highest-value item on the list.
Infrastructure as code with a portable tool. Configuration remains provider-specific and the workflow and knowledge transfer.
Document the exit path. Knowing roughly what migration would involve, and what it would cost, converts an anxiety into an estimate. Frequently the estimate is reassuring.
That final item is underrated. Much lock-in fear is fear of an unknown quantity. A documented, costed migration plan — even one nobody intends to execute — resolves the anxiety and informs the decision better than any architecture.
What Migration Actually Involves
For calibration, the realistic components of a provider migration:
Compute and containers move relatively easily. Networking must be redesigned, since models differ enough that translation is not mechanical. Identity and access requires rebuilding, as the models are not equivalent. Managed service replacements need selecting and integrating. Data must be moved, with egress charges and a synchronisation strategy for the cutover. Infrastructure code is largely rewritten. Operational tooling and runbooks need updating. The team needs to learn the new environment. And a cutover plan with rollback must be built and tested.
For a substantial estate this is a multi-quarter programme with meaningful risk. That is the cost multi-cloud exists to avoid.
The comparison that matters: is a multi-quarter programme, possibly never undertaken, more expensive than permanently doubled operational surface and abandoned managed services? For most organisations the answer is no. For a few — regulated, very large, or with genuine capability needs across providers — it is yes.
A Defensible Position
What most organisations should actually do:
Choose one primary provider deliberately. Based on capability fit, pricing, regional presence, and available expertise. Commit to using it well, including its managed services.
Reduce cheap lock-in. Containers, standard database engines, open data formats, provider SDKs behind interfaces. These cost little and address the expensive dependencies.
Accept expensive lock-in where the value is real. A managed database that removes an operational burden is worth depending on.
Use a second provider for specific workloads where it is genuinely better. Not for portability — for capability.
Document and cost the exit path. Then revisit it periodically as the estate changes.
Reconsider if circumstances change. A regulatory requirement, a large acquisition, or a genuine capability gap changes the calculation legitimately.
This is less satisfying than a portable architecture and it reflects the actual economics. The organisations that operate most effectively in cloud are generally those that picked one and used it thoroughly, not those that maintained optionality.
Common Pitfalls
Multi-cloud as generalised lock-in insurance. Continuous cost against an unquantified risk.
Lowest common denominator architecture. Abandons the managed services that provide most of the value.
Ignoring egress charges in cross-cloud designs. Frequently the largest ongoing cost and the most easily overlooked.
Assuming resilience improves. Added complexity introduces failure modes; net effect requires testing.
Shallow expertise in two clouds. Produces worse architecture than deep expertise in one.
Never testing the failover. A multi-cloud architecture that has not survived a simulated provider outage is a diagram.
Treating lock-in as binary. Different dependencies have very different exit costs and warrant different decisions.
Conclusion
Multi-cloud as insurance against lock-in inverts the economics. It pays continuously — duplicated infrastructure, doubled operational surface, egress charges, abandoned managed services, slower delivery — to reduce a one-time cost that may never be incurred.
The better position is selective. Choose one provider and use it thoroughly, including the managed services that are the reason to be in cloud at all. Reduce the lock-in that is cheap to reduce: containers, standard engines, open data formats, provider calls behind interfaces. Accept the lock-in that buys something real.
Then document what migration would actually involve and roughly what it would cost. That estimate converts an anxiety into a number, and the number is usually smaller than the cumulative cost of the architecture built to avoid it.
Genuine multi-cloud justifications exist — regulation, acquisition, specific capability, geographic coverage, very large scale. They are specific, and none of them is a general preference for keeping options open.
Frequently Asked Questions
Is lock-in not a real risk? It is real and it is one risk among several, with a cost that can be estimated. The mistake is treating it as the dominant consideration without comparing it against the continuous cost of avoidance.
Does Kubernetes provide portability? For workload scheduling, substantially. Not for the surrounding infrastructure — networking, storage classes, identity, and load balancers are provider-specific. Kubernetes moves compute portability from moderate to easy and leaves the rest.
What about provider outages? Multi-region within one provider addresses most realistic scenarios at far lower cost than multi-cloud. Provider-wide outages happen and are rare, and a multi-cloud architecture only helps if it has been tested against one.
Is a hybrid on-premises and cloud arrangement the same problem? Similar costs and frequently better justifications — existing hardware investment, data residency, or latency to on-premises systems. The operational duplication cost is comparable.
How can a provider be evaluated for lock-in risk? Ask what migrating each component would require, and total the estimate. Components where the answer is “redesign” are your expensive dependencies, and whether that is acceptable depends on what they provide.
Should managed services be avoided to stay portable? Generally no. Managed services are a primary reason to use cloud, and avoiding them means operating equivalents yourself, which requires more people and delivers less. Depend on them where they save real work.
What is the highest-value portability measure? Open data formats. Data is usually the dominant migration cost, and keeping it in portable formats addresses that at almost no ongoing expense.
