Data Egress Fees Explained: The Charge Nobody Budgets For

Egress is the industry word for data leaving a provider’s network. If your
server sends a web page to a visitor, streams a video, returns an API response
or transfers a backup to somewhere else, that is egress, and on most platforms
it is metered and billed.

Ingress, meaning data arriving, is almost always free. That asymmetry is
deliberate, and understanding it explains a great deal about how cloud pricing
behaves.

Why the charge exists

Providers pay for their connections to the rest of the internet, and those
costs scale with volume. Charging for outbound traffic passes that cost on to
the customers who generate it. There is a second, less discussed effect:
inbound data is free and outbound data is not, which makes it cheap to move your
data in and comparatively expensive to move it out again. Whether you regard
that as sensible cost recovery or as a retention mechanism, both readings
describe the same pricing structure, and you should plan around it either way.

What usually counts, and what usually does not

The exact rules differ by provider, so treat this as a map rather than a
specification, and confirm against the provider’s own pricing documentation.

• Billed in most cases: traffic from your servers to the
  public internet, traffic between regions, and in some cases traffic between
  availability zones inside the same region.
• Free in most cases: inbound traffic from the internet, and
  traffic between resources in the same zone over private addresses.
• Varies considerably: traffic from object storage, traffic
  through a CDN, and traffic to the provider’s own other services.

That third category is where bills go wrong. Serving large files directly
from object storage to the public can be one of the most expensive things a
small project does, because every download is metered egress.

Included allowances change the picture entirely

Some providers bundle a transfer allowance with each instance. A server plan
might include a quantity of outbound transfer per month, and you pay nothing
extra until you exceed it. For a small site, a blog, an internal tool or a
low-traffic API, that allowance may be more than you will ever use, which makes
egress a non-issue.

Other platforms meter outbound transfer from the first gigabyte. Their
compute may be cheaper, and for a workload that processes data internally and
returns very little, that can be the better deal. For a workload that serves
media to the public, it may be dramatically worse.

This is why two providers with identical instance prices can produce bills
that differ by a large multiple, and why a price comparison that only compares
CPU and RAM is incomplete. The developer-focused providers tend to bundle
transfer allowances, which is part of why
Hetzner, DigitalOcean and
Linode often work out cheaper for content-serving workloads than their
specifications alone suggest.

Estimating your own egress

You do not need a sophisticated model. You need a rough figure, and you can
get one from two numbers you probably already have.

Take the average size of what you serve, multiply by how many times you
expect to serve it per month, and add a margin. A page with images that weighs
two megabytes, served fifty thousand times, is roughly a hundred gigabytes of
egress. Compare that against the allowance included with your plan. If it is
comfortably inside, stop thinking about egress. If it is not, egress is now a
design constraint and you should treat it as one.

Reducing it

The reductions that matter are mostly unglamorous:

1. Put a CDN in front of static assets. Cached responses are
   served from the edge rather than from your origin, which cuts origin egress
   substantially for anything repeatedly requested.
2. Compress what you send. Text, JSON and HTML compress well,
   and most of the saving is free to obtain.
3. Serve correctly sized images. Sending a four thousand pixel
   photograph to a phone is the single most common source of avoidable egress on
   small sites.
4. Set cache headers properly. A browser that does not
   re-request an unchanged file does not generate egress at all.
5. Keep chatty services in the same zone. Cross-zone and
   cross-region traffic between your own components adds up quietly.

Where egress genuinely matters most

Three situations deserve explicit attention before you commit. Media delivery,
because video is large and repeated. Backups copied off the platform, because
the whole point is to send a full copy somewhere else, regularly. And migration,
because moving away from a provider means paying to extract everything you have
accumulated there, which is worth knowing before you accumulate it.

For everyone else, egress is a line item to understand once and then check
occasionally. The failure mode is not that the charge is unfair. It is that
nobody looked at it until the traffic arrived.