AWS CloudFront Caching Explained
Understand how CloudFront caching works: cache keys, TTLs, cache policies and invalidations, and how to configure them for Next.js and API traffic.
Amazon CloudFront is AWS's content delivery network. Configured well, it makes sites dramatically faster and cheaper to run. Configured badly, it serves stale or even wrong content. Here is how caching really works.
The cache key
CloudFront stores one cached object per cache key. By default that is the URL path, but a cache policy can add query strings, headers or cookies. Every value you add to the key lowers your hit ratio, so include only what changes the response.
TTLs and origin headers
The minimum, default and maximum TTLs in the cache policy work together with the Cache-Control headers from your origin. Let the origin decide with max-age and s-maxage, and use the policy as guard rails.
Static assets vs. HTML vs. APIs
- Hashed static assets: cache for a year with
immutable - HTML pages: short TTLs or stale-while-revalidate
- Authenticated API calls: do not cache, or include the auth header in the key
Invalidations
Invalidations remove objects before their TTL expires. They are useful after deployments or CMS publishes, but prefer versioned file names for assets so you rarely need them.
Conclusion
Keep cache keys minimal, let origins control freshness with headers, and separate the behaviour of static assets, pages and APIs.