CloudFront caches content at edge locations close to users, reducing latency and origin load. The cache behavior, TTLs and how you handle updates decide whether users get fresh or stale content, and how much traffic reaches the origin.
Before you start
You should understand HTTP caching and origins. This article covers CloudFront behaviors and invalidation.
Step-by-step walkthrough
Step 1: Set the cache behavior and TTL
A cache behavior matches a path pattern and sets how long objects are cached via the minimum, default and maximum TTL. Immutable assets can have a long TTL; HTML that changes often needs a short one. Honor the origin’s cache headers where appropriate.
Step 2: Update with versioned paths instead of invalidation
The cheapest way to update a cached asset is to change its URL, such as app.abc123.js, so the new file is a new cache entry. Invalidation forces edges to drop objects by path, which takes time and has a cost, so reserve it for paths you cannot version.
Step 3: Protect the origin with an origin shield
An origin shield adds a caching layer between the edges and the origin, so a miss in one edge is served by the shield rather than the origin. This reduces origin load and improves hit ratio, especially across regions.
Worked scenario
Versioned filenames make updates cache-friendly.
GET /static/app.abc123.js -> long TTL, cached at edge
deploy: build /static/app.def456.js and reference the new name
old file: still cached, but unreferencedWalk through the example
Because the filename changes with the content, the new build is a new URL and the edge fetches it once, while the old file stays cached and harmless. No invalidation is needed, and every client gets the correct version. Invalidation is reserved for the rare path that cannot be versioned.
Common mistake
Invalidating /* on every deploy, which forces every edge to refetch everything, costs money and can overload the origin. Another is a long TTL on mutable HTML, so users see stale pages.
Verify the behavior
Check response headers for the cache status and TTL. Deploy a versioned asset and confirm the new file is fetched while the old remains cached. Compare origin request counts with and without an origin shield.
Interview exercise
Why prefer versioned URLs over invalidation?
Answer and reasoning
Versioning makes each new build a distinct cache key, so edges fetch it once and serve it immediately, with no global propagation delay or invalidation cost. Invalidation must propagate to every edge and may briefly serve stale content. Versioning also lets old and new coexist, which suits gradual rollouts.
Continue learning
Compare origin design in CDN content and caching in HTTP caching. Read the AWS CloudFront caching documentation and try the AWS interview questions.