Egress is what you pay to move data out of the cloud to the internet, and for any content-heavy application it is one of the largest transfer lines on the bill. A CDN changes the economics in two ways. First, CDN egress rates are typically lower than serving the same bytes directly from a cloud origin, so even an uncached request can be cheaper through the edge. Second, and far more important, a cached request is served from the edge entirely, so it generates no origin egress whatsoever; only the cache misses pull from origin. That means the single most valuable number in this whole exercise is the cache hit ratio, the share of requests served from cache. Push it from sixty percent to ninety percent and you have cut origin egress by three quarters. Most of the work of cutting egress with a CDN is the work of raising that ratio.
This article is part of our complete guide to cloud storage and data cost optimization, the cluster pillar it links up to. It builds directly on data egress charges explained, which sets out why egress is priced the way it is.
A cache hit produces no origin egress at all. The cache hit ratio is the lever: every percentage point you raise it removes that share of requests from your most expensive transfer line.
Put a CDN in front of everything cacheable
The first move is simply to serve cacheable content through a CDN rather than directly from origin. Static assets such as images, video, scripts, stylesheets, downloads and software artifacts are the obvious candidates, and for many sites these are the bulk of egress by volume. Serving them through the edge means repeat requests for the same file are answered from cache near the user instead of pulled across the internet from your origin every time. The same logic extends to object storage: putting a CDN in front of a public bucket converts expensive direct-from-storage egress into cheaper edge delivery, and is one of the most reliable wins on a media-heavy bill. This complements broader transfer reduction covered in how to reduce data egress waste.
Raise the cache hit ratio deliberately
Putting a CDN in place is necessary but not sufficient; a CDN with a poor hit ratio still pulls most traffic from origin. Raising the ratio is a set of concrete tuning steps. Set generous cache lifetimes on content that does not change often, using long max-age headers and versioned filenames so you can cache aggressively and still ship updates instantly. Normalize cache keys so that trivial query-string and header variations do not fragment the cache into many near-duplicate entries that each miss. Cache the things teams forget are cacheable, such as API responses that are identical across users, and font and configuration files. And monitor the hit ratio as a first-class metric, because a config change or a new query parameter can quietly collapse it. The hit ratio is the number to watch; the bill tracks it almost directly.
| Lever | What it does | Effect on egress |
|---|---|---|
| CDN in front of static assets | Serves repeat requests from edge | Removes hits from origin egress |
| Longer cache lifetimes | Keeps content cacheable for longer | Raises hit ratio, fewer origin pulls |
| Cache-key normalization | Stops cache fragmentation | Raises hit ratio on the same content |
| Origin Shield / mid-tier cache | Adds a second cache layer at origin | Cuts origin fetches on cache misses |
| Compression at the edge | Shrinks bytes per response | Lower egress per delivered request |
Is egress the line that keeps growing?
Our cloud cost audit measures your cache hit ratio, tunes the CDN and caching so most bytes leave the cheap way, and proves the egress saving against a clean baseline on AWS, Azure, GCP and OCI. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Cut origin fetches on the misses you cannot avoid
Some requests will always miss the cache, so the next lever is making those misses cheaper. An origin shield or mid-tier cache puts a second caching layer close to your origin, so when many edge locations miss at once they fetch from that shared layer rather than all hammering origin, which collapses many origin egress events into one. Compression at the edge shrinks the bytes in every response, cutting egress per request whether the response is cached or not. And for dynamic content that genuinely cannot be cached, the question becomes whether it needs to leave the cloud at all, which loops back to architecture and the inter-region transfer patterns that drive a separate part of the transfer bill.
The Cloud Storage and Egress Cost Playbook includes the CDN cache-ratio audit and the header-tuning checklist we use to raise hit ratios before renegotiating any transfer commitment.
Know what not to cache
Aggressive caching saves money, but cache the wrong thing and you trade a cost problem for a correctness problem, so the rule is to cache by content type rather than by blanket policy. Never cache authenticated or personalized responses at a shared edge, since one user could be served another user's data; scope those to private caches or skip the cache entirely. Be careful with content that changes silently, such as a file overwritten in place under the same name, which is why versioned or fingerprinted filenames matter: they let you cache forever and still publish updates instantly by changing the URL. And set short or no caching on genuinely dynamic API responses while still caching the static and semi-static parts of the same application, so the cacheable majority gets the saving without putting the dynamic minority at risk. The goal is a high hit ratio on safe content, not a high hit ratio on everything.
Mind the CDN's own pricing
A CDN is a cost as well as a saving, so it pays to understand its pricing before you assume the win. CDN egress is billed per gigabyte delivered, often with regional rate tiers, and some providers also charge per request and for cache invalidations. The net saving is almost always positive for cacheable traffic, but you confirm it by comparing blended CDN delivery cost against the origin egress it displaces, and by negotiating committed-volume rates once volume is high. Verify current CDN and egress rates in the provider's documentation as of May 2026 before modeling the change, since these prices move. The point is to choose the CDN configuration that minimizes total transfer cost, not to add an edge layer and hope.
The short version
Use a CDN and caching to cut egress bills by serving all cacheable content through the edge, then treating the cache hit ratio as the metric that matters: longer cache lifetimes, normalized cache keys, and caching the responses teams forget are cacheable all raise it, and every point of hit ratio removes that share of traffic from expensive origin egress. Cut the unavoidable misses with an origin shield and edge compression, and confirm the net saving against the CDN's own per-gigabyte and per-request pricing. When you want the cache ratio measured and the egress proven down across the estate, that is part of what our rightsizing and waste elimination service delivers.