Ask an engineering team what locks them into their cloud provider and you will hear about proprietary services. Managed queues, serverless runtimes, identity systems with no equivalent elsewhere. All real, all replaceable given a quarter of effort.
Then ask the finance team, and you get a different answer: it costs more to leave than to stay. Not because rebuilding is expensive, but because copying your own data out of the building has a per-gigabyte price attached, and the bill scales with exactly the thing that makes leaving worthwhile.
Uploading data is free. Storing it is cheap and getting cheaper every year. Reading it back out to anywhere that is not the same provider costs somewhere between 5 and 9 cents per gigabyte at the tiers most companies actually sit in.
That is not a cost-recovery number. Transit and peering at hyperscaler volume costs a fraction of a cent per gigabyte. The gap between what bandwidth costs and what egress is priced at is not an accident of pricing complexity — it is the mechanism.
Consider a modest data platform: 200 TB in object storage, accumulated over four years of perfectly reasonable engineering decisions. Storage runs maybe $4,000 a month, which nobody escalates. Copying it out once, at 8 cents per gigabyte, is roughly $16,000 — four months of storage cost, payable in a single month, to do something that generates no new revenue.
The technical work of the migration might be three weeks. The invoice for moving your own bytes is what turns it into a board conversation.
The effect is not limited to exit. Egress pricing quietly determines design decisions long before anyone considers leaving.
You do not put the analytics warehouse in a different provider from the application database, because the cross-provider traffic would cost more than the warehouse. You do not serve large media from a second, cheaper provider, because the origin fetches are billed. You do not run a genuine multi-cloud failover, because keeping state synchronised across two providers means paying egress continuously, forever.
Each of those is a rational local decision. Together they produce an architecture where every byte lives next to every other byte inside one provider — which is precisely the architecture that is most expensive to unwind. The pricing did the design work.
The standard mitigation is to front object storage with a CDN so that repeated reads are served from cache and origin egress drops. This works, and every serious team already does it.
It does nothing for the case that matters. A migration is a full read of every object exactly once. Cache hit rate on a one-time full scan is zero. The CDN is a discount on your steady state, not on your exit.
Committed-use egress discounts have the same shape: they reduce the ongoing bill in exchange for a commitment, which is another way of describing the thing you are trying to get out of.
European regulation now requires cloud providers to allow customers to switch without switching charges, and the major providers have introduced free-egress-on-exit programmes in response. This is genuine progress and it is narrower than the headlines suggest.
The waivers generally apply when you are terminating your account entirely, require you to notify the provider and complete within a defined window, and cover only the data you are taking with you. They do not help the far more common case: a team that wants to move one workload, keep another, and run both for a year while they do it. Partial migration — the only kind most organisations can safely execute — is still billed per gigabyte.
Price your exit now, while it is cheap to know. Multiply your total stored bytes by the egress rate for your tier. That number is your switching cost, and it grows every month you do not look at it. Put it on the same page as the storage line item.
Do not let the number grow unexamined. Most object stores contain a large fraction of data nobody reads: old build artefacts, logs past their useful life, replaced backups, the second and third copies of datasets somebody snapshotted before a risky change. Lifecycle rules that delete or downgrade this data reduce the exit price as directly as they reduce the storage bill.
Keep the newest data portable. If a full copy is unaffordable, a rolling copy is not. Continuously replicating the last 90 days elsewhere costs a predictable monthly amount and means an emergency migration starts with the data that matters already in place.
Weight egress properly when you choose. Compare providers on bandwidth policy with the same seriousness you compare them on instance price. A provider with generous included transfer and flat overage is making a different promise about your ability to leave than one where the meter runs on every gigabyte out — and that promise is worth more over five years than a few percent on compute.
Lock-in used to mean a proprietary API you would have to rewrite against. That version was at least visible in the code, and engineers could argue about it in design review.
This version is invisible until the day you try to leave, it accumulates automatically with normal use, and no single decision creates it. It is the better trap, which is why it is the one that is still standing.