Cache hit ratio is one of the most important performance metrics for a CloudFront distribution. A cache hit means CloudFront served the response without touching your Origin — zero Origin load, minimum latency. The primary lever for improving cache hit ratio is cache key engineering.
What Is a Cache Key?
The cache key is the unique identifier CloudFront uses to store and look up a cached response. By default, the cache key is just the URL path. But CloudFront can include additional dimensions:
- Query strings:
?color=red&size=large - HTTP headers:
Accept-Language,User-Agent,Authorization - Cookies:
session_id,user_tier
Every unique combination of cache key components creates a separate cache entry. Including too many dimensions fragments your cache and destroys your hit ratio.
Cache Key Anti-Pattern: Including Everything
A common mistake is forwarding all headers and cookies to the Origin "just in case." If you include the User-Agent header in your cache key, CloudFront creates a separate cache entry for every browser version — Chrome 120, Chrome 121, Firefox 118, Safari 17, etc. A single URL can generate hundreds of cache entries, each with a near-zero hit rate.
Cache Key Best Practice: Include Only What Changes the Response
Ask: "Does this header/cookie/query parameter actually change what the Origin returns?"
- If your Origin returns different content based on
Accept-Language→ include it. - If your Origin ignores
User-Agent→ exclude it from the cache key (but you can still forward it to the Origin if needed, separately from the cache key).
CloudFront separates these concerns with Cache Policies (what goes in the cache key) and Origin Request Policies (what gets forwarded to the Origin). You can forward a header to the Origin without including it in the cache key.
Cache Policy: Include query string "version" only
Origin Request Policy: Forward all headers to Origin (for logging/analytics)
Result: Cache key = path + ?version=X (high hit ratio)
Origin receives full headers (full context)