CDN & Caching with CloudFront

The plain-language idea

CloudFront is AWS's CDN: a network of edge locations physically close to users, each holding a cached copy of your content so a request doesn't have to travel back to the origin (your S3 bucket, your API, wherever the real content lives) every time. The behavior that actually matters day to day comes down to three levers:

• TTL (time to live) — how long an edge location keeps a cached response before checking the origin again. Set per cache behavior, which can differ by path pattern (/static/* cached for a year, /api/* barely cached at all).
• Cache key — what CloudFront considers "the same request" for caching purposes. By default it's just the URL path — two requests for /product?color=red and /product?color=blue can collide into the same cached response if query strings aren't included in the cache key, which is a real, recurring bug category.
• Invalidation — forcing edge locations to drop a cached copy before its TTL naturally expires, because something changed and can't wait.

See it in a real thing: three ways to invalidate, ranked by cost

Content-hashed filenames: a new build is a new URL — nothing to invalidate, ever. The cheapest option, by construction.

BackNext

1. Content-hashed filenames (main.a3f8c1.js) — the cheapest and most correct option. A new build is a new URL nothing has cached yet; the old cached file is simply never requested again and expires naturally. No invalidation call needed at all.
2. Explicit invalidation (aws cloudfront create-invalidation --paths "/index.html") — forces specific paths to be dropped immediately. Necessary for content that can't be renamed (like index.html itself, which has to keep a stable URL), but costs money past a monthly free allotment and isn't instant across every edge location worldwide.
3. Short TTLs — the blunt option. Setting a 60-second TTL on everything "solves" staleness by mostly not caching, which defeats the point of a CDN and multiplies origin load.

What people usually miss

Watch out

• An invalidation isn't instant everywhere. It propagates across CloudFront's global edge network, which takes time — a request that lands on an edge location mid-propagation can still serve the stale cached version for a short window after the invalidation was requested.
• Query strings aren't part of the cache key unless explicitly configured to be. An API response that varies by query parameter (?page=2) needs its cache policy to include query strings, or every page of a paginated response can collide into one cached entry — a subtle, hard-to-reproduce bug that only shows up under real traffic.
• Cache behaviors are evaluated by path pattern, most-specific first, not by declaration order — a catch-all /* behavior and a specific /api/* behavior can coexist, with requests matching /api/* correctly using that behavior's (probably much shorter) TTL even though /* is also a technical match.
• A CDN caching an error response is a real failure mode. If an origin briefly returns a 500 and that response gets cached, every edge location now serves that error until the cache clears — CloudFront's own error-caching TTL (separate from success-response TTL) exists specifically to bound how long a transient origin failure gets amplified into a widespread outage.

Why this matters in interviews

"A user says they're still seeing the old version of the site after a deploy" is a real, recurring support question, and the strong answer reaches for the specific mechanism — TTL, cache key, invalidation propagation — rather than "tell them to clear their browser cache," which is very often not even where the stale copy actually lives.