Low Cache Hit Ratio on CloudFront Distributions

When cache behaviors include all query strings, all cookies or high-cardinality headers such as User-Agent in the cache key, or when objects carry short Cache-Control max-age values, CloudFront treats near-identical requests as distinct objects and forwards most of them to the origin. The CDN is in place, but the origin still handles close to the full request volume.

Each miss is paid for at the origin: S3 GET requests, load balancer capacity units, EC2, container or Lambda compute, and for origins outside AWS, the other provider's egress charges. CloudFront bills every viewer request whether it is a hit or a miss. The pattern is common on distributions created with a single default behavior that forwards everything so the application works, and it matters most on busy websites, APIs and media delivery.

A cache miss is billed twice: once by CloudFront for the viewer request and delivery, and again by the origin for serving the request.

CloudFront requests and delivery

Billed per 10,000 requests and per GB delivered to viewers, for both cache hits and cache misses

Origin request cost

Each miss generates an origin request billed by the origin service, such as S3 request charges or load balancer and compute usage

Origin fetch data transfer

Free from AWS origins to CloudFront, but billed by the other provider when the origin is outside AWS

Origin Shield requests

Optional extra caching layer billed per 10,000 requests that reach Origin Shield from other regional caches

• Turn on the additional distribution metrics (billed as a fixed monthly CloudWatch charge per metric) and review Cache hit rate, the percentage of cacheable requests served from cache, alongside Requests and Origin latency on the CloudFront Monitoring page
• Use the CloudFront cache statistics report or the x-edge-result-type field in standard access logs to see the share of Hit, RefreshHit and Miss results by path
• Inspect each cache behavior's cache policy for cache keys that include all query strings, all cookies or headers with many unique values such as User-Agent
• Check Cache-Control max-age on static objects served by the origin, and compare origin request volume (for example S3 GET requests or ALB request count) with CloudFront Requests

• Include in the cache key only the query strings, cookies and headers that actually change the response, and normalize parameter case and order in the application
• Split static and dynamic content into separate cache behaviors, forwarding cookies only on the dynamic paths, and use managed cache policies such as CachingOptimized for static assets
• Set the longest practical max-age on static objects, and use stale-while-revalidate and stale-if-error where the origin supports them
• Replace User-Agent in the cache key with CloudFront device-type headers when responses vary only by device class
• Enable Origin Shield for origins that serve many edge locations when its per-request fee is lower than the origin load it removes; for fully personalized responses that cannot be cached, accept the lower hit rate rather than risk serving wrong content

• Increase the proportion of requests that are served directly from the CloudFront caches (cache hit ratio)docs.aws.amazon.com
• View CloudFront and edge function metricsdocs.aws.amazon.com
• Amazon CloudFront pay-as-you-go pricingaws.amazon.com
• COST08-BP03 Implement services to reduce data transfer costsdocs.aws.amazon.com