By Yair Knijn · March 3, 2026

The egress bill you only discover the day you try to leave the cloud

The CTO signs off on a repatriation plan that pays back in fourteen months. Compute is cheaper on the new platform, storage is half the price, the spreadsheet green from month two. The one number that never made the model is the cost of physically moving the data out, and it lands as a single line on a single invoice the week migration starts.

The assumption under almost every migration case is that the data is already yours, so moving it is free. It is yours. Moving it is not free. Egress is metered per gigabyte leaving the network, and at petabyte scale the charge to walk out the door can exceed the annual savings the project was built to capture. That is the exit tax, and it makes cloud lock-in financial rather than technical.

Why the exit cost never appears in the savings model

Migration models are built around recurring line items, because those are the numbers already on the bill: compute, storage, licensing, support. Egress at exit is none of those. It is a one-time event in the future, triggered only by an action you have not taken, so there is no historical line to anchor it to. The cost of staying is visible and the cost of leaving is invisible, which is what makes the savings look real. Treat the move as a capital event with its own number, and if you have not written a dollar figure for the exit, you do not have a business case.

Egress pricing as a deliberate retention mechanism

Ingress is free on every major provider and egress is not, and that gradient is no accident. Getting data in costs nothing; getting it out costs per gigabyte. Each terabyte you load deepens the moat, and the bill to cross it back grows with your own success on the platform. The lock-in here is not a proprietary API. It is arithmetic.

Regulators eventually named it. The EU Data Act (Regulation (EU) 2023/2854) treats switching and data-egress charges as a barrier to competition, caps them at the provider's actual direct costs during a transition, and bans them outright from 12 January 2027. Ahead of that, AWS, Azure, and Google all announced free egress for customers leaving entirely. Read the conditions: the waivers generally apply when you take all your data and close the account, not when you split a workload across clouds. Multi-cloud, the case most CTOs are actually building, still meters at full rate.

Modeling the one-time move against steady-state gains

The honest model has four inputs: total data to move, the per-GB rate that applies to you, projected monthly savings, and the break-even where savings clear the exit charge. Measure the volume from billing, not the architecture diagram, and count the logs, backups, and snapshots nobody remembers creating. Use the partial-migration rate, not the all-or-nothing waiver. If the move costs a year of savings, a fourteen-month payback is really twenty-six.

What the model exposes is a ratio: recurring savings against one-time egress. Repatriating a compute-heavy, data-light service is usually a clean win, because the egress is a rounding error against the compute spend. The trap is the data-heavy case, where the thing making the platform expensive is the same thing making it expensive to leave. When a single egress invoice eats a year or more of projected gains, the platform has already won, and renegotiating in place or staging the exit beats eating it in one quarter.

Pricing the exit before you commit to the entrance

The cheapest time to price your exit is before you sign the entrance. Cloud Horizons keeps that figure live for every workspace, tracking stored volume against current published egress rates per cloud so the cost is visible the day it matters, not the day you try to leave. Price the move in your FinOps view before the deck reaches the board, and decide with the real number instead of the one you learn too late.