Egress Is the Real Lock In

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 not what your code calls; it is what your bytes cost to leave, 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.

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, which is the pricing structure of a savings account with an early termination fee, not the pricing structure of a network.

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.

On the twenty-third of July, 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 have 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 matters. A price unchanged since 2018, against an input cost falling year over year, is a statement about a published list rather than a model. Whatever the margin on egress was three years ago, it is wider now, and it goes on widening without anyone at any provider ever raising a price. That is a much quieter mechanism than a price rise, and much harder to argue with in a procurement meeting.

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 is 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.

Now the case nobody is afraid of. 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. The difference is not the size. It is that this one recurs whether or not anybody ever migrates anything, and it recurs 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 rather than 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 - free in, metered out, metered again at every internal boundary - rather than against this quarter's table.

The mechanism that makes this lock-in rather than an expense 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 actual 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 not what the line costs this month. It is whether anyone has ever computed what it 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 not insurance. It is a permanent tax you levied on yourself to avoid a temporary one somebody else might levy on you.

I should narrow the claim, because "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, which happens to be most people building anything that stores much.

What stays with me is the direction of the meter. Every other price in this industry has fallen for forty years, relentlessly, and the one that governs whether you can leave has been flat since 2018 while its input collapsed. That is not a conspiracy and nobody had to arrange it; it is what happens when the cost of accumulating is zero and the cost of withdrawing is not. You do not get locked in by signing something. You get locked in one upload at a time, at no charge.