Avoiding lock in without overpaying means treating lock in as a quantifiable switching cost rather than a fear, then buying only the portability whose option value exceeds its premium. For most workloads, blanket multicloud is the overpriced answer: it forfeits the deepest commitment discounts, adds egress and integration cost, and splits your engineering across two clouds. The cheaper protection is a credible, costed ability to move a meaningful slice of spend, which gives you negotiating leverage without paying to run everything twice.
The lock in debate is usually framed as portability against discount, as if you must pick a side. That framing overpays. Lock in has a price, the discount you forgo to stay portable has a price, and the right answer is the one with the lower total cost for each workload. This article sits in the multicloud strategy cluster and the broader cross cloud cost optimization guide.
What is cloud lock in really made of?
Lock in is the sum of your switching costs, and it has four components. Data gravity is the first: moving large datasets out of a provider incurs egress charges, and the more data you accumulate, the more expensive the exit. Managed service dependency is the second: the deeper you build on a provider's proprietary databases, queues, and serverless primitives, the more re engineering a move requires. Commitments are the third: an AWS Savings Plan, an Azure Reservation, a GCP Committed Use Discount, or OCI Universal Credits tie you to a provider for a term. Skills are the fourth: a team fluent in one cloud cannot operate a second one overnight.
Naming the four components matters because they are not equal and they are not fixed. Data gravity and managed service dependency are structural and grow over time. Commitments are contractual and expire. Skills are a function of hiring and training. You can manage each one deliberately rather than treating lock in as a single undifferentiated risk, and that is what lets you reduce the parts that matter without paying to eliminate all of them.
Why does blanket multicloud usually overpay?
Running the same workload across providers to stay portable looks like prudence and behaves like a tax. To keep a workload portable you avoid each provider's deepest proprietary services, so you give up the managed capabilities that make a single cloud efficient. You spread spend across providers, which means you hit the deeper commitment discount tiers on none of them, because discount tiers reward concentration. You move data between clouds, paying egress on every crossing. And you ask your team to be expert in two environments instead of one. Each of these is a real cost, and together they frequently exceed the lock in they remove.
The State of FinOps work through 2026 shows scope expanding to SaaS, AI infrastructure, and private estates, which makes the multicloud premium even less attractive: complexity is rising on every axis, and adding a second cloud to every workload multiplies it. The question of when concentration beats diversification is worked through in consolidate or diversify, the spend question.
What protection do you actually need?
The protection most buyers want from portability is leverage: the ability to walk away, or credibly threaten to, when a provider's renewal terms are poor. You do not need to run everything on two clouds to have that. You need a costed, credible plan to move a meaningful slice of spend, and a workload architecture that does not make such a move impossible. That is a fraction of the cost of full portability and delivers most of the negotiating benefit, because the account team is measured on retained spend and responds to a real alternative.
Concretely, this means keeping the parts that create the most leverage portable, and letting the rest sit deep in one provider where the efficiency is. A stateless compute tier is cheap to keep portable; a proprietary analytics warehouse holding years of data is not, and trying to keep it portable forfeits the very efficiency you are paying the provider for. Selective portability spends your portability budget where the option value is highest.
A European SaaS company ran a deliberately portable architecture across two providers to avoid lock in, splitting every workload and avoiding proprietary services on principle. We priced the strategy: the split forfeited a full discount tier on commitments, egress between the clouds was material, and the team carried the cost of dual expertise. We consolidated the stateful core onto one provider for the deeper discount, kept the stateless tier portable for leverage, and built a costed migration plan for a single data heavy workload as the walk away option. Total spend fell 27 percent while the company kept real negotiating leverage into its next renewal. Figures are verified against billing data and anonymised.
Does avoiding lock in mean avoiding commitments?
No, and conflating the two is how buyers leave the largest savings on the table. Commitments discount roughly 20 to 72 percent against on demand, which makes them among the biggest levers available, and refusing them out of a fear of lock in is overpaying to stay free. The discipline is to commit safely: size coverage to a defensible baseline you would run regardless, keep the variable layer on demand or on Spot, and ladder expiry dates so no single cliff forces a rushed renewal. A laddered commitment book is itself a form of flexibility, because a portion comes up for decision every few months. Avoiding lock in is about staying able to move, not about forgoing the discount that funds the rest of the programme.
How do you keep the lock in price down over time?
Manage the four components deliberately. Watch data gravity: tier and prune data so the egress cost of a hypothetical move stays bounded, and be aware that OCI egress is materially cheaper than the hyperscalers if egress economics drive a placement decision. Contain managed service dependency by choosing, workload by workload, where proprietary depth is worth the lock in and where an open standard keeps the exit affordable. Keep commitments laddered and sized to forecast. And maintain enough cross cloud skill that a move is operationally feasible, even if you run mostly on one provider. None of this is free, but each is far cheaper than running everything twice, and together they keep lock in priced and managed rather than feared.
Lock in decisions at a glance
| Component | Overpriced response | Right sized response |
|---|---|---|
| Data gravity | Avoid storing data in any one cloud | Tier and prune; price the egress of a move |
| Managed services | Avoid all proprietary services | Use depth where it pays; keep exits open where it matters |
| Commitments | Forgo discounts to stay free | Size to baseline, ladder expiries |
| Skills | Staff fully for two clouds | Maintain enough to make a move feasible |
Sequencing these moves across an estate is the subject of the multicloud optimization roadmap, which lays out the order in which to make them.
Frequently asked questions
Is multicloud the best way to avoid lock in?
How do I price the cost of cloud lock in?
Does avoiding lock in mean avoiding commitments?
Price your lock in, then decide
We quantify your real switching costs, identify where portability earns its premium and where it does not, and build the leverage you need into your next renewal, on the buyer side, with zero provider commissions. Talk it through with one of our founders.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.