The egress trap: the cloud line item nobody budgets for

You budgeted for compute. You budgeted for storage. Then the invoice landed and there was a line you never modeled: data transfer. Egress. The fee you pay to read your own data back out of the cloud.

It is rarely the headline number. It is the one that creeps up while you are not looking, and then one month it is a third of the bill and nobody can say exactly why.

What egress actually is, and why it is priced like this

Egress is outbound data: bytes leaving a zone, a region, or the provider’s network entirely. Inbound is usually free. Outbound is metered per gigabyte, and the rate stacks in layers — cross-AZ, cross-region, out to the internet — each with its own price.

Storing data is cheap and getting cheaper. Moving it is where the margin lives. Charging for egress does two things for a hyperscaler at once: it prints money on traffic that costs them very little, and it raises the cost of ever leaving. The data you put in is free to ingest. Getting it back out, at scale, is not. That asymmetry is not an accident. It is the business model.

How it warps your architecture

Here is the part that should bother you as an engineer. Egress pricing stops being a billing detail and starts making design decisions for you.

• You stop moving data. The clean design says copy this dataset to where the compute is. The invoice says don’t. So you contort the topology to keep bytes still, even when that is the wrong call.
• You fear multi-region. Replicating to a second region for resilience is exactly what you should do. Cross-region egress makes it a recurring tax, so you talk yourself out of it.
• You avoid the obvious analytics pipeline because pulling the data to the tool that should process it costs more than the processing.
• You get locked in. Once your data is large, the cost of pulling it out to evaluate another provider is itself a deterrent. The egress meter is a moat, and you are on the wrong side of it.

None of these are correctness decisions. They are invoice-avoidance decisions wearing an architecture costume.

The bill-shock pattern

It always looks the same. A launch goes well. A batch job gets chattier. A misconfigured client retries across a region boundary. A new dashboard polls an object store from the wrong place. Traffic that was a rounding error becomes the dominant cost, and the worst part is you cannot predict it in advance — the rate card has so many tiers and boundaries that the only way to learn the number is to get billed for it. You architect defensively around a cost you can’t model. That is the trap.

What we do instead

We think you should architect for correctness, not for the invoice. So we took the lever away.

There is no egress charge between Kaligon resources in the same region. Your VM talking to your block volume, your object store, your database, another VM — that traffic is free. Move data to where the compute is. Replicate within the region for resilience. Build the pipeline the textbook way. The bytes between your own resources do not show up on the bill.

Outbound traffic to the internet is a single flat rate. One number. No cross-AZ surcharge, no cross-region tier ladder, no surprise boundary you tripped over at 2am. You can read it off the pricing page and put it in a spreadsheet before you build anything.

That fits how the rest of Kaligon is priced: one flat price per resource, per-second billing that caps monthly, and a hard budget that actually stops spend. No reserved-instance gymnastics, no committed-use discounts you have to chase. And because your data stays in the region you chose, it doesn’t quietly wander somewhere more expensive to leave.

Egress should be a network concern, not a design constraint. Architect the right thing. Let the invoice be boring.