CloudFront bills are driven by a combination of data transfer, request volume, and — the lever most teams underuse — cache hit ratio. A distribution with a mediocre cache hit ratio pays for the same content to be fetched from origin repeatedly, and that origin traffic is almost always the more expensive part of the bill.
Start With Cache Hit Ratio, Not Price Class
Cache hit ratio measures the percentage of requests CloudFront serves directly from edge cache versus forwarding to your origin. A low hit ratio usually traces to one of a few root causes:
- Overly granular cache keys — including query strings or headers in the cache key that don't actually affect the response, fragmenting what could be one cached object into many uncached variants
- Cache-Control headers set too conservatively at the origin, forcing more frequent revalidation than the content actually needs
- Dynamic content mixed into the same distribution/behavior as genuinely static assets, with no path-based behavior separating them
{
"CacheBehaviors": [{
"PathPattern": "/static/*",
"CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",
"MinTTL": 86400,
"DefaultTTL": 604800
}, {
"PathPattern": "/api/*",
"CachePolicyId": "4135ea2d-6df8-44a3-9df3-4b5a84be39ad",
"MinTTL": 0,
"DefaultTTL": 0
}]
}
Separating static and dynamic paths into distinct cache behaviors, each with a cache policy matched to how that content actually changes, is consistently the single highest-leverage optimization we make on CloudFront cost engagements.
Reduce Origin Request Volume With Origin Shield
For distributions with multiple edge locations frequently missing cache and hitting origin independently, Origin Shield consolidates those origin requests through a single additional caching layer, reducing the total number of requests your origin (and any associated compute or database cost behind it) has to serve. This adds a small additional cost for the shield layer itself, but for origin-request-heavy distributions, the net savings from reduced origin load typically outweighs it.
Price Class Selection
CloudFront's price class setting controls which edge locations serve your content — using all edge locations globally costs more than restricting to North America and Europe, for example. If your actual user base is concentrated in specific regions, restricting price class to match reduces cost without meaningfully affecting performance for users outside the excluded regions (who'd still be served, just from a farther edge location).
Compression and Format Optimization
Ensure compression is enabled at the CloudFront level (Brotli or gzip) for compressible content types — this directly reduces data transfer costs, which scale with bytes served. For image-heavy sites, converting to modern formats (WebP, AVIF) at the origin before CloudFront ever serves them compounds with compression to meaningfully cut transfer costs.
Right-Sizing Logging and Real-Time Metrics
CloudFront access logging and real-time log configurations both carry their own cost (S3 storage for standard logs, Kinesis Data Streams costs for real-time logs). Audit whether every distribution genuinely needs both enabled — a low-traffic internal distribution rarely needs real-time logging, and standard logs can often be sampled or have a shorter retention policy than the default.
Monitoring the Impact
After implementing cache policy changes, monitor cache hit ratio and origin request volume in CloudWatch over at least a full week (to account for day-of-week traffic variation) before drawing conclusions — a change that looks neutral over 24 hours sometimes shows a clear improvement once a full weekly cycle of traffic patterns is captured.
aws cloudwatch get-metric-statistics \
--namespace AWS/CloudFront \
--metric-name CacheHitRate \
--dimensions Name=DistributionId,Value=E1EXAMPLE \
--start-time 2026-01-01T00:00:00Z --end-time 2026-01-08T00:00:00Z \
--period 86400 --statistics Average
Frequently Asked Questions
How much can cache hit ratio improvements realistically save on a CloudFront bill?
It varies significantly by starting point and traffic pattern, but distributions with poorly-tuned cache keys often see origin request volume (and associated cost) drop substantially after separating static and dynamic cache behaviors — the exact percentage depends on how much of your traffic was needlessly bypassing cache before.
Does Origin Shield make sense for every distribution?
No — it adds cost, so it's most beneficial for distributions with high origin request volume across many edge locations. A low-traffic distribution with an already-high cache hit ratio likely won't see enough origin request reduction to justify the added shield cost.
Is restricting price class a real cost lever, or mostly marginal?
It's a real, straightforward lever for global-traffic distributions where a meaningful share of edge locations serve regions with little to no actual user base — but check your access logs by region first, since restricting price class where you genuinely have users in the excluded regions trades cost for real latency degradation.
Should we compress at the origin or let CloudFront handle it?
CloudFront can compress on the fly for eligible content types, but pre-compressing static assets at the origin (especially for large files) can reduce the compute overhead CloudFront spends compressing on every cache miss, complementing rather than replacing CloudFront's automatic compression.
How do we know if our current cache policy is actually hurting us?
Check your CacheHitRate metric in CloudWatch — a hit ratio well below what's typical for your content type (static-asset-heavy sites often see very high hit ratios when tuned well) is a strong signal that cache key configuration or TTL settings need review.
See what a 2-week AWS cost audit finds in your account → rutagon.com/contact or call 907-841-8407.