Egress fees exist to make leaving look more expensive than staying.
Egress pricing is built to make repatriation feel too expensive to start. Do the one-time math and the story usually flips.
In this article 5 sections
- Cloud providers let your data in for free and charge you to take it out. That asymmetry is a strategy, not a quirk of networking.
- The one-time cost of leaving is almost always smaller than one more year of the bill you are trying to escape.
- Standard Linux is portable on day one and on day three thousand. Proprietary managed services are the lock-in that never shows up as a line item.
- Our engineers run the move by hand, with the cutover as a short, planned, rehearsed window.
Why the exit is priced, not the entrance
Data into a hyperscaler is free. You can push terabytes in and never see a charge for the ingress. Data out is a different story. Read those two directions next to each other. The direction that keeps you costs nothing. The direction that frees you has a meter on it.
That is not an accident of how bandwidth is billed. The packets do not know which way they are going. Egress is metered by the gigabyte, which prices the exit. The exit is the moment a customer leaves, and a number large enough at that moment turns a decision into a project nobody wants to start.
Do the one-time math
Here is the math, and we are not going to invent the totals for you, because your numbers are yours. Take your last full invoice and fill in four lines.
| The line | How to get it | Your number |
|---|---|---|
| Data to move (TB) | Your total stored footprint | ____ |
| Egress out, one time | TB × your provider's published egress rate | ____ |
| Metered spend per month | Compute + storage + transfer + managed services on your last bill | ____ |
| Months to break even | One-time egress ÷ the monthly spend you stop paying | ____ |
The last line is the whole argument. For most environments that number is small, and every month after it is money you simply stop spending.
The lock-in that isn't on the invoice
Egress is the tax you can see. The deeper one is architectural. Every proprietary managed service you adopt (the vendor's queue, the vendor's function runtime, the vendor's database dialect) is a piece of your application that only runs in one place.
Standard Linux does not do this to you. A workload on a plain distribution, standard packages, and open protocols is portable the day you build it and portable three thousand days later. We run standard Linux on hardware we own. Nothing we hand you is a dialect you can only speak here.
How the move actually runs
A migration off a hyperscaler is not a leap of faith when the engineers holding both ends of the wire have done it many times before. We stage the move, sync the data ahead of the cutover, and rehearse the switch. Our people do the hands-on work. You are not handed a runbook and wished luck.
We make leaving us easy too
The honest test of this argument is whether we apply it to ourselves, and we do. Our own exit stance has been on our About page for years: standard Linux, standard tools, no part of your stack held hostage. We do not build a moat out of your switching cost.
We keep customers by being good, not by making it expensive to leave. Most people who leave stay on good terms, and some come back.
Straight answers
Will you help me leave later?+
Yes, and we will not make it painful. Standard Linux, standard tools, your data pulls out clean. We would rather you leave easily and come back than stay because leaving hurts.
Does my IP change?+
Usually yes, since the addresses are ours. We plan the DNS cutover with you, lower TTLs ahead of time, and keep both ends live until the switch settles. For most sites, visitors never notice the cutover.
How long is the cutover?+
Short, and planned with you in advance. We sync the data ahead and rehearse the switch, so the window itself is minutes of DNS, not hours of copying.
Cost your exit in about 3 minutes
Answer a few questions and get a real build with a price range. No account, no sales pitch, just math.
Start the wizardYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer