CloudFront cache hit rate: how it changes origin egress cost

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

CDN pricing is usually dominated by edge bandwidth and requests, but origin egress can become a major hidden line item. Cache hit rate is the primary knob that changes how much traffic reaches your origin.

Definitions (what "hit rate" means)

• Cache hit: request served from an edge cache without going to the origin.
• Cache miss: request goes to the origin (and often fills the cache).
• Hit rate: hits / (hits + misses) over a time window.

A simple cost model (good for budgeting)

Start with your expected edge traffic and an assumed hit rate H (e.g., 0.85).

• Origin requests/month ~= edge requests/month * (1 - H)
• Origin egress GB/month ~= edge bandwidth GB/month * (1 - H)

This is a baseline. Short TTLs, invalidations, and multi-region fills can increase origin traffic beyond the simple (1 - H) factor.

What breaks cache hit rate (and raises origin cost)

• Cache fragmentation: forwarding many query strings, cookies, or headers creates many cache keys.
• Short TTLs: frequent revalidation forces more origin requests.
• Frequent invalidations: purging popular content reduces hits during deploy windows.
• Uncacheable responses: missing or restrictive Cache-Control headers.
• Cache fills: when the same object is fetched by many edge locations, a single miss can become multiple origin fetches (especially right after deploys).

How to improve hit rate safely

• Use versioned asset URLs (content-hashed filenames) so you rarely need invalidations.
• Normalize cache keys: only include the query params/cookies/headers that truly change responses.
• Set intentional TTLs: long TTL for static assets; shorter TTL for HTML; avoid "0 by default".
• Separate dynamic endpoints: keep truly dynamic, personalized endpoints out of the cache path.
• Use Origin Shield (when appropriate): reduces multi-POP cache fill by centralizing origin fetches.

Worked example (sanity check)

If your CDN serves 10,000 GB/month at the edge:

• At 90% hit rate: origin egress ~= 10,000 GB * (1 - 0.90) ~= 1,000 GB/month
• At 70% hit rate: origin egress ~= 10,000 GB * (1 - 0.70) ~= 3,000 GB/month

A temporary hit rate drop during deployments can show up as a visible origin egress spike, even if edge bandwidth is unchanged.

Cache key checklist (avoid fragmentation)

• Only forward query params that change the response.
• Only forward cookies that change the response (auth cookies often make responses uncacheable).
• Only vary on headers you need; avoid varying on large or unstable headers.
• Confirm caching behavior for 200s and for common 4xx/5xx responses.

Measure and validate

• Measure hit rate on a real distribution, not a single endpoint or a single day.
• Track both edge bytes and origin bytes to validate the origin reduction assumption.
• Validate whether compression changes "bytes at edge" vs "bytes at origin".
• Validate origin request spikes during deploy windows and invalidations.

Related tools

CloudFront cost calculator Origin egress cost Invalidation pricing

Sources

• CloudFront caching: docs.aws.amazon.com
• CloudFront metrics: docs.aws.amazon.com

Related guides

Related calculators

FAQ