Skip to content
ServerSpotter

Understanding egress pricing — the hidden cloud cost

8 min read

Why egress is the “hidden” cloud cost

Many beginners compare hosting options by CPU, RAM, and disk, then get surprised by a bill that’s much higher than expected. One of the most common causes is egress bandwidth: the cost of sending data out of a provider’s network to the public internet or to other networks.

Egress often feels “hidden” because:

  • It may be listed deep in pricing pages or as a separate line item.
  • It’s usage-based, so it scales with traffic and growth.
  • It can be triggered by normal operations (downloads, video, backups, API responses), not just “high traffic.”
Understanding egress early helps you estimate total cost and design your setup to avoid unnecessary data transfer fees.

What egress bandwidth is (and what it isn’t)

Egress (outbound traffic) is data leaving a provider’s infrastructure. Common examples:

  • A visitor downloads your website assets (images, JS, CSS) from your server.
  • Users stream video/audio hosted on your instance.
  • Your API responds with JSON payloads to clients on the internet.
  • Your server pushes backups to another provider or to a different region.
Ingress (inbound traffic) is data entering the provider (uploads, requests coming in). Many providers charge little or nothing for ingress, but charge for egress.

Where egress is measured

Providers typically measure egress at one or more points:

  • VM/instance network interface (traffic leaving the VM to the internet)
  • Load balancers (traffic from the LB to clients, sometimes also between LB and instances)
  • Object storage/CDN (data served to users)
  • Inter-region / inter-AZ traffic (data between regions or “availability zones”)
This matters because you can sometimes “move” where traffic is served (e.g., via CDN) and change the price model dramatically.

“Included transfer” vs “metered egress”

In practice you’ll see two broad models:

1. Included transfer / unmetered up to a cap (common in many VPS/dedicated providers) You pay a fixed monthly price and get a large transfer allowance (e.g., 20 TB/month) or “unmetered” at a certain port speed subject to fair use.

2. Metered egress per GB (common in hyperscale clouds) You pay per GB (or TB) of data leaving, sometimes with tiered pricing. This can be very cheap for low traffic but becomes significant as you scale.

How providers charge for egress

Egress pricing is not one-size-fits-all. Providers may charge differently depending on:

Destination: internet vs internal vs private links

  • To the public internet: usually the most expensive category in cloud pricing.
  • Within the same data center/region: sometimes free, sometimes discounted, sometimes still billed.
  • Between regions: often billed (and can be more expensive than internet egress).
  • To a private interconnect: may be cheaper, but requires special networking products.

Product: compute vs storage vs CDN

You might pay egress charges from multiple services:

  • Compute instance egress: serving files directly from your VM.
  • Object storage egress: users downloading files from a storage bucket.
  • CDN egress: delivering cached content globally (sometimes cheaper, sometimes with request fees).

Time and billing increments

Some providers bill:

  • Per GB with tiers (first X TB at one rate, then cheaper)
  • Per GB with a minimum monthly charge
  • Separately for IPv4 vs IPv6 (less common for bandwidth, more for address rental)
  • By 95th percentile on enterprise networking (common in colocation; less common for beginner VPS)

Free tier and “included” transfer comparisons (what to look for)

When people say “free egress” they usually mean one of these:

  • A monthly allowance included in the price (e.g., “20 TB included”)
  • A small free tier (e.g., first 100 GB free, then charged per GB)
  • Free egress only to certain destinations (e.g., to the same region, or to a paired CDN)
Instead of memorizing specific numbers (which change), learn to compare offers using a checklist.

A practical comparison checklist

When comparing providers, check:

1. How much outbound transfer is included per month? Look for “Traffic included,” “Transfer,” or “Bandwidth.” 2. What happens after you exceed the included amount? Is it throttled, overage billed, or do you need to upgrade? 3. Is internal traffic billed? Example: VM → object storage, VM → database, cross-zone. 4. Are there separate charges for CDN, load balancers, or object storage? 5. Are there regional differences? Hyperscale clouds often price egress differently by region.

Example: small app vs content-heavy app

  • Small app (API + admin panel): egress might be modest (a few 10s–100s of GB/month).
  • Content-heavy (images, downloads, video): egress can dominate cost quickly (TBs/month).
If your business is “move bytes to users,” egress is a first-class cost, not a rounding error.

Practical examples: estimating egress before you deploy

Example 1: a simple website

Assume:

  • Average page weight: 2 MB
  • Monthly page views: 100,000
Estimated egress: 2 MB × 100,000 = 200,000 MB ≈ 200 GB/month

That may be within many “included transfer” plans, but in metered egress models it can become a noticeable monthly add-on.

Example 2: file downloads

Assume:

  • File size: 200 MB
  • Downloads per month: 5,000
Estimated egress: 200 MB × 5,000 = 1,000,000 MB ≈ 1 TB/month

Now egress is a major line item. Serving from your VM vs object storage vs CDN can change the cost and performance.

Example 3: backups leaving the provider

Assume:

  • Daily backup: 50 GB
  • Retention: not relevant for egress, only transfer out
  • You push it to another provider every day
Monthly egress for backups: 50 GB × 30 ≈ 1.5 TB/month

This surprises people because it’s not “user traffic,” but it’s still outbound transfer.

How to minimize egress costs (without breaking your app)

1) Cache aggressively (browser + server)

  • Set long-lived cache headers for static assets:
- `Cache-Control: public, max-age=31536000, immutable` for versioned assets
  • Use compression:
- Gzip/Brotli for text assets (HTML/CSS/JS/JSON)

Less data served per user = less egress.

2) Put a CDN in front of static content

A CDN can reduce the amount of data your origin server sends by caching at edge locations. This can:

  • Lower VM egress from your compute instance
  • Improve performance globally
  • Move costs into CDN pricing (which may be cheaper and/or have a free tier)
Tip: keep cache hit ratio high by using cache-friendly URLs and versioning assets (`app.3f2c1.js`).

3) Don’t serve large files from your app server

For downloads, uploads, and media:

  • Store large objects in object storage optimized for delivery
  • Use signed URLs so your app authorizes access but doesn’t stream every byte
This also reduces load on your app server.

4) Keep traffic “local” when possible

If you use multiple services (VM + database + object storage), try to keep them:

  • In the same region/data center
  • In the same provider network, if internal traffic is free/cheap
Cross-region architectures are powerful, but they can multiply transfer charges.

5) Be careful with logs, metrics, and debugging

Common egress traps:

  • Shipping verbose logs to third-party services
  • Exporting high-cardinality metrics
  • Frequent full database dumps pulled to a local machine
Fixes:
  • Reduce log verbosity in production
  • Batch and compress exports
  • Do internal aggregation before exporting

6) Optimize media

Images and video are egress magnets.

  • Resize images to actual display sizes
  • Use modern formats (WebP/AVIF where appropriate)
  • For video, use adaptive bitrate streaming rather than single large files

7) Measure and alert on outbound traffic

Even beginners should set up basic visibility:

  • Provider dashboard traffic graphs
  • OS-level tools (e.g., `vnstat`, `iftop`) for quick checks
  • Billing alerts if your provider supports them
Catching a sudden spike early (a bot scraping, a misconfigured endpoint, hotlinked images) can save real money.

VPS-friendly alternatives with generous included transfer

If your project is bandwidth-heavy and predictable, many developers consider non-hyperscale providers where pricing is simpler and traffic is bundled.

Hetzner

Hetzner is often chosen for strong price/performance and clear resource bundles. Many plans include a large monthly transfer allowance and straightforward overage rules. It’s popular for:

  • Web apps and APIs
  • Self-hosted services
  • Storage/download use cases (within included limits)
What to verify:
  • Included traffic on the specific plan type (cloud vs dedicated)
  • Any port speed limits and overage pricing

Contabo

Contabo is known for aggressive specs per dollar and often includes large traffic bundles. It can be attractive for:

  • Budget VPS needs
  • Dev/test environments
  • Projects where cost predictability matters
What to verify:
  • Fair use and network performance expectations
  • Support response times and service model (important for production)

OVH / OVHcloud

OVH is a common choice for dedicated servers and VPS with substantial included transfer options. It’s frequently used for:

  • Dedicated servers with high bandwidth needs
  • Self-managed infrastructure at scale
  • Projects where having lots of included traffic helps control costs
What to verify:
  • Included transfer specifics by product line
  • Any anti-DDoS/network policies that might affect edge cases
Important: “Included transfer” doesn’t mean infinite. Read the traffic policy and understand what happens if you exceed it (throttling vs billing vs required upgrade).

Putting it together: choosing the right approach

A useful rule of thumb:

  • If you want maximum flexibility and managed services: hyperscale cloud can be great, but you must model egress.
  • If you want predictable bills and lots of bundled bandwidth: a VPS/dedicated provider like Hetzner, Contabo, or OVH may be simpler—especially for bandwidth-heavy workloads.

A beginner-friendly decision workflow

1. Estimate monthly egress (GB/TB) using real assumptions. 2. Decide where content should be served from: - VM, object storage, CDN, or a combination 3. Compare providers based on: - Included transfer and overages - Internal traffic rules (VM↔DB↔storage) - Tooling for monitoring and alerts 4. Add safeguards: - Caching, CDN, compression - Billing/traffic alerts - Rate limiting and bot protection if needed

Key takeaways

  • Egress is outbound data transfer and is a major cost driver for downloads, media, backups, and popular apps.
  • Providers charge in different ways: per-GB metering, included monthly transfer, or product-specific pricing (compute vs storage vs CDN).
  • You can reduce egress with caching, CDNs, media optimization, smarter architecture, and monitoring.
  • If predictable bandwidth is a priority, consider VPS/dedicated-focused providers like Hetzner, Contabo, and OVH, and compare their included transfer policies carefully.