Why CloudFront Missed the Cache and How We Slashed S3 Costs by 80%

Numbers Don’t Add Up

We noticed our AWS bill was unusually high – about $2,400 per month for S3 alone, even though we only served static files behind CloudFront, which should have cached most requests.

S3 Logs Reveal the Oddity

CloudFront metrics showed a cache‑hit rate of only 12% , far below the expected >90% for static assets. Checking S3 access logs, each request from CloudFront contained an If-Modified-Since header, and S3 responded with 304 Not Modified. CloudFront kept revalidating the objects and never cached the 304 responses, causing millions of unnecessary origin requests.

Root Cause

The underlying issue was that the uploaded files lacked a Cache-Control header. CloudFront was configured to “respect the origin headers”; without any cache directives from S3, CloudFront defaulted to revalidating every request.

Simple Fix

We updated our upload command to include proper cache metadata:

aws s3 cp file.js s3://bucket/ --cache-control "public, max-age=86400"

We also used S3 Batch Operations to retroactively add the correct Cache-Control header to existing objects.

After the Fix

Cache‑hit rate jumped from 12% to 94% .

S3 request count dropped from ~8 million per month to about 500 k .

Monthly cost fell from $2,400 to roughly $480 .

Page load times improved because CloudFront no longer repeatedly hit the origin.

Lessons Learned

The key takeaway is not to assume CloudFront will automatically handle caching correctly; it strictly follows the headers you provide. Always set explicit Cache-Control headers for static files, monitor CloudFront cache metrics, and periodically audit S3 object metadata.