Google stopped charging customers to leave in January and AWS followed three weeks ago, so the exit fee everybody feared is now, conditionally, nothing. The meter that decides your architecture was left exactly where it was. The arithmetic runs on both: leaving once was always survivable, while a boundary crossed on every request is a subscription no refactor cancels, and the lock-in is where the asymmetry makes you put the next service.
26 March 2024·7 min read·clouddependencies
Every architecture review I have sat in eventually arrives at the lock-in question, and it is always the same question in slightly different words. How much of this is proprietary. Could we run it somewhere else if we had to. Are we depending on anything only one company sells. These are reasonable things to ask, they get asked seriously by people who have been burned before, and they are pointed almost entirely in the wrong direction.
So the sentence worth carrying out of this is short and slightly annoying. Lock-in is what your bytes cost to move, and it is denominated in a unit that no amount of refactoring operates on. You can rewrite every line of an application in a year. You cannot rewrite where forty terabytes are.
The last three months are worth reading carefully, and they are not a victory. On the eleventh of January, the same day the European Data Act came into force with provisions aimed squarely at switching charges, Google said it would stop charging customers who are leaving to take their data with them. AWS said the same three weeks ago. Both offers come with the shape you would expect: you have to ask for it, it covers a full departure and not the move of one workload elsewhere, and it runs for a bounded window while you go.
Read that as what it is. The providers gave away the one-time charge, which is the number that appears in board papers and press coverage and regulatory filings, and kept the per-gigabyte charge on traffic that crosses a boundary during normal operation, which is the number that decides where your next service gets built. If you had asked me which half they would surrender, I would have told you this one, and I would have been right for the reason the rest of this piece is about.
Transfer is free one way, metered the other. No provider charges you to send data in. All of them charge to send it out. If the cost driver were the cost of carrying packets this would make no sense, because a bit costs the same to move in either direction and the ports are the same ports. What it does instead is make accumulation frictionless and withdrawal expensive. A network charges for the ports and lets traffic run both ways across them; this charges for the exit, the way a savings account with an early termination fee does.
The meter runs inside the perimeter too. Egress is not only about the internet. Traffic between availability zones is billed per gigabyte in each direction, traffic between regions is billed, and a highly available design that spreads replicas across zones on purpose is a design that pays for its own redundancy by the gigabyte. So the charge lands hardest on exactly the architectures the same provider's well-architected guidance tells you to build.
In July 2021 Cloudflare published a piece called "AWS's Egregious Egress" making three claims. Industry wholesale transit prices have fallen an average of 23 percent a year for ten years, leaving wholesale bandwidth about 93 percent cheaper than it was a decade ago. AWS egress rates in North America and Europe had not dropped by a cent since 2018. And the resulting markups over Cloudflare's estimate of wholesale cost run into the hundreds of percent, with South Korea, which the post treats as getting off lightly, still at 357 percent.
The first thing to do with that is name who published it. Cloudflare sells a network in competition with the ones it is pricing, it runs the Bandwidth Alliance, whose members waive their side of the transfer bill for mutual customers, and the post is in part an argument for joining that program. None of which makes a number wrong. It does mean the post is advocacy with arithmetic attached, and a reader who does not say so out loud is going to quote it as a survey.
The second thing is to see where the arithmetic is soft. Every markup multiple in it is a ratio, and the denominator is what wholesale transit costs, which is privately negotiated, commercially sensitive, and not published by anyone. Cloudflare had to estimate it, and then adjust the estimate for assumed link utilization and for the way transit is billed at the 95th percentile. Move either assumption a little and the multiple moves a lot. I would read those figures as a direction of travel rather than as a measurement.
The third thing is that one claim needs no denominator at all, and it is the one that has aged best. The metered per-gigabyte rate is a statement about a published list, with no model behind it, and against an input cost falling year over year it has held. One qualifier belongs here that did not exist when that post was written: the free monthly allowance went up by two orders of magnitude at the end of 2021, which genuinely removed the charge for small users. The rate above the allowance is where it was. Whatever the margin on egress was six years ago it is wider now, and it goes on widening without anyone at any provider ever raising a price, which is a much quieter mechanism than a price rise and much harder to argue with in a procurement meeting.
Stop reading other people's multiples and do the sum on your own two cases, because they behave completely differently.
Take the case everyone is afraid of first. You have 100 TB sitting in object storage in a North American region and you want it somewhere else. Run it through the published tiers and it comes to roughly $8,000 to copy out once. Against that, storing the same 100 TB at the standard rate runs somewhere near $2,350 a month, so the entire exit fee was about three and a half months of what it already costs you to keep. Painful to sign off, entirely survivable, and a one-time event. As of this month, if you are leaving altogether and remember to ask, it is nothing at all. The exit fee is the number that has just been zeroed, and it is the smaller of the two.
Now the case nobody is afraid of, and the one no announcement in January or March touches. A service answers requests in one provider and reads from a data store in another, and it moves 1 TB a day across that boundary. That is 30 TB a month, which at the same published tiers is about $2,700 a month, or over $32,000 a year. Recurrence is what separates the two cases. This one bills whether or not anybody ever migrates anything, it is not a departure so no waiver applies to it, and it runs for as long as the boundary sits where it sits.
The headline rates cluster, and the tails do not. List prices for the first tier of internet egress from a major North American region sit within a few cents of one another, near $0.09/GB, with Google listing above that and Microsoft marginally below. The free monthly allowances differ by two orders of magnitude between them. So the cheapest provider for an application with a small constant trickle is not the cheapest for one with a large monthly volume, and neither ranking is visible from a comparison chart.
A CDN in front changes which meter you are on. Content served through a provider's own edge network is billed at edge rates instead of origin egress rates, and the fetch from origin to edge is often discounted or free. For anything cacheable this is the largest single lever available and it requires no architectural change worth the name. For anything personalized or streaming from a database it does nothing at all.
The lists change and your architecture does not. Everything in this section is a published rate at the time I am writing, and published rates move. What does not move on the same timescale is where you decided your data lives and which network path your requests take to reach it. Design against the structure instead of this quarter's table. Free in, metered out, metered again at every internal boundary.
The mechanism that turns this from an expense into lock-in is that it changes where the next thing gets built. When reaching data that lives elsewhere carries a per-gigabyte charge and reaching data that lives here does not, every individual placement decision quietly favors here. So the new service goes next to the old data, and the analytics job goes next to the new service, and in four years there is a gravity well that nobody chose, assembled entirely out of decisions that were each correct on the day.
And for most organizations the line item is small. If you move a few terabytes a month, the egress charge is a rounding error next to the compute bill, you will not save your way to anything meaningful by optimizing it, and you would be better off spending the afternoon on your database. The people making the most noise about egress pricing, myself in this paragraph included, are frequently people with an interest in you buying bandwidth somewhere else.
The thing that stops that being a full answer is the derivative. The exit price is computed against the data you have, and the data you have only grows; the cost of a decision you might make in five years is being set by a rate card today, on a volume that will be several times larger by then. The tell is whether anyone has ever computed what the exit would cost, once, and written the number down.
One crossing per request is a subscription. The distinction that predicts the bill is whether a boundary is crossed once during a migration or once per request forever. Anything in the hot path that reaches across a provider line has committed you to paying for that line at the rate of your traffic growth, indefinitely, and there is no version of a code change that alters it. Move the boundary or accept the subscription.
Do not build for a migration you will never run. The temptation after reading any of this is to add an abstraction layer so you stay portable. That layer is paid for every day by every engineer who works through it, in complexity and in features you cannot use, and it is usually more expensive than the exit fee it was built to avoid. Portability that is never exercised is a permanent tax you levied on yourself to avoid a temporary one somebody else might levy on you.
"Egress is the real lock-in" is the kind of line that gets repeated past the point where it is true. Plenty of organizations are locked in the old-fashioned way, by a proprietary service with no equivalent anywhere else, and for them the API question is the right question. And plenty more are not locked in at all; they have a modest bill, a portable stack, and no data worth the name. The argument here applies to the middle case. That happens to be most people building anything that stores much.
Under a regulation aimed at switching costs, three providers in three months removed the charge on the single event that almost nobody performs, and left untouched the charge on the traffic that runs every second of every day and quietly decides where the next service goes. Both are called egress. Only one of them was ever the lock-in, and it is the one still on the meter. You do not get locked in by signing something. You get locked in one upload at a time, at no charge.