How to Cut S3 Egress Costs: 9 Levers That Actually Work

Storing data in S3 or any S3-compatible bucket is cheap. Getting it back out is where the bill grows. On the major hyperscalers, egress to the public internet typically runs in the range of $0.05 to $0.09 per GB after a small free tier, and at scale that single line item can dwarf what you pay for the storage itself. This guide walks through the levers that actually move the number, ordered roughly from highest leverage to lowest, so you can pick the ones that fit your traffic profile.

Why egress is expensive in the first place

Egress fees are not a hardware cost - they are a commercial choice. Moving bytes out of a hyperscaler's network costs the provider a fraction of a cent per GB in transit, but the headline price is set far higher to capture value and to discourage data from leaving the platform. That is the lock-in mechanism: your storage is cheap to fill and expensive to drain. Once you understand egress as a pricing strategy rather than a physics problem, the levers below make more sense. For the broader mechanics of how providers bill data transfer, see our explainer on egress fees.

Lever 1: Put a CDN in front of your bucket

The single biggest win for read-heavy workloads is caching. A CDN serves repeat requests from edge nodes, so the origin bucket only pays egress on a cache miss. If your cache hit ratio is 90 percent, you have cut origin egress by roughly 90 percent in one move. CDN bandwidth is usually priced lower than raw object-storage egress, and many providers offer free or discounted transfer between their own object storage and their own CDN.

• Set sensible Cache-Control headers so objects stay cached - short max-age defeats the purpose.
• Use long TTLs with content-hashed filenames for static assets (immutable caching).
• Watch your hit ratio in CDN analytics; a low ratio usually means cache-busting query strings or tiny TTLs.

Lever 2: Move to a free-egress provider

A growing set of S3-compatible providers charge zero for egress, or bundle a generous transfer allowance with storage. For workloads that are egress-dominated - public downloads, media distribution, dataset hosting - migrating the bucket can eliminate the line item entirely, even if the per-GB-month storage price is slightly higher. The math is simple: if egress is 60 percent of your bill, a provider that zeroes it out wins even at a 30 percent storage premium. Compare per-GB storage and transfer terms side by side on the object storage comparison and the egress pages, and always check the live tables for current numbers.

Lever 3: Keep traffic in the same region

Egress to the public internet is the expensive path. Traffic between two services in the same region and the same provider is usually free or close to it. If your compute reads objects from a bucket in a different region, you are paying inter-region transfer on top of everything else. Co-locate your buckets with the compute that reads them, and prefer same-AZ where the provider charges for cross-AZ traffic.

Lever 4: Compress before it leaves the bucket

You pay egress per byte on the wire, so fewer bytes means a smaller bill. Text-heavy payloads - JSON, logs, CSV, HTML - compress by 70 to 90 percent with gzip or Brotli. Serve assets pre-compressed where the client supports it, and store logs and exports compressed at rest so the egress byte count matches the compressed size. For already-compressed formats (JPEG, MP4, Parquet with internal compression) this lever does little, so target the text.

Lever 5: Cut request and small-object overhead

Egress is not the only transfer-adjacent cost. Many providers charge per 1,000 GET/PUT requests, and a workload that fetches millions of tiny objects can rack up request fees that rival the byte cost. Batch small objects, use range requests instead of repeated full downloads, and prefer fewer large reads over many tiny ones.

Lever 6: Use a peering or private interconnect for bulk transfer

If you regularly move large volumes between a cloud and your own data center or another cloud, a direct interconnect (private network link) is often billed at a steep discount versus public-internet egress. The fixed port cost only pays off above a certain monthly volume, so estimate first, but for steady bulk pipelines it can halve the effective per-GB rate.

Lever 7: Cache and deduplicate at the application layer

Before the bytes ever reach the network, ask whether the request was necessary. Application-side caching, client-side caching with proper ETags, and deduplicating identical downloads all reduce origin reads. A 304 Not Modified response carries almost no payload.

A table of levers, ranked

How to estimate your savings

Start with your actual numbers, not a guess:

1. Pull last month's egress GB and request counts from your bill or usage dashboard.
2. Estimate your achievable cache hit ratio - for static assets, 85-95 percent is realistic; for unique downloads, much lower.
3. Multiply current egress by (1 minus hit ratio) to model the CDN scenario, then add CDN bandwidth cost at the CDN's per-GB rate.
4. Separately, price the same egress volume at a free-egress provider (storage cost only) and compare totals.
5. Apply a compression factor to text-heavy traffic before doing any of the above.

Run those four numbers and the right lever usually becomes obvious. Use the egress cost calculator to plug in your GB and compare provider rates, and check current per-GB pricing on the live object storage and egress tables rather than memorized figures - rates change.

Takeaway

Egress is a pricing lever the provider pulls on you; caching, provider choice, locality, and compression are the levers you pull back. For most teams the order of operations is: front the bucket with a CDN, keep service-to-service reads in-region, compress text, and - if egress still dominates - move egress-heavy buckets to a free-egress object storage provider. Estimate with your own numbers, validate against the live comparison tables, and revisit the calculation whenever your traffic profile shifts.