CDN setup that actually reduces your egress line

A CDN that is only used for latency often still leaves most of the origin egress bill intact. The configurations that actually move the needle on cost are long TTLs for versioned assets, cache keys that ignore noise, and an origin shield or regional edge so that repeated misses from the same geography hit the origin only once.

I measure success by the cache-hit ratio and by the origin egress volume, not by the pure request count. A 95 % hit ratio on a busy static asset is the difference between a manageable bill and a surprise.

One media library I moved behind a properly configured CDN saw origin egress fall by more than 80 % within a week. The only application change was adding immutable Cache-Control headers on versioned objects and stripping tracking parameters from the cache key. Everything else was CDN configuration.

Cache key and TTL mistakes that keep origin traffic high

• Including unique query parameters (tracking IDs, session tokens) in the cache key
• Short TTLs on assets that change only on deploy
• No Cache-Control headers from the origin, forcing the CDN to use conservative defaults
• Serving the same content under multiple URLs without normalisation

Fixing the cache key and setting a 24-hour (or longer) TTL for versioned static files routinely doubles or triples the hit ratio.

Origin shield / regional edge

When many edge locations miss at the same time they can all pull from the origin, multiplying the egress. An origin shield (or the provider’s regional edge tier) collapses those misses into a single origin pull. For global traffic this is often the single highest-leverage change after correct TTLs.

Verifying the hit ratio

Most CDNs expose hit/miss metrics. I look at:

• Overall hit ratio
• Hit ratio by path or by cache behaviour
• Origin request volume versus edge request volume

# Example CloudFront – use the real reporting API or console
# Look for “Cache hit rate” and “Bytes downloaded from origin”

If the hit ratio is low on a path that should be static, the cache key or the TTL is the first place to look.

When a CDN does not reduce egress

• Dynamic, uncacheable responses
• Range requests or streaming that bypass the cache
• Clients that send no-cache or very short max-age
• Misconfigured behaviours that forward every request to the origin

In those cases the CDN still helps latency for the cacheable subset, but the egress line will not shrink until the application itself becomes more cache-friendly.

A correctly configured CDN is one of the highest-ROI cost controls available for any public-facing static or semi-static content. The work is mostly in the cache key, the TTL and the verification of the hit ratio; once those are right the origin egress drops and stays down.

I also keep the Egress calculator open when tuning. After the hit ratio stabilises I plug the new origin volume back in and confirm the expected monthly saving. The calculator does not configure the CDN for you, but it makes the before/after comparison numerical and hard to argue with.