Skip to content
BytePatterns

CloudFront & Caching Layers

AWS for Interviews: lesson 8 of 18

Edge, regional cache, origin — and a cache key that decides it all.

Lesson 8 of 18 · 6 min

CloudFront & Caching Layers

Step 1 of 10

The origin lives in one Region. Viewers are everywhere, so CloudFront puts caches in edge locations near them.

The Idea

CloudFront answers viewers from edge locations near them. A miss asks a regional edge cache, then the origin — S3, a load balancer, any HTTP server. The cache policy sets the cache key (which headers, cookies and query strings make two requests "the same") and TTL bounds; within them, the origin's Cache-Control headers decide how long a copy lives.

Real-World Example

A web app names its JavaScript bundles by content hash, caches them for a year and never invalidates them: a deploy ships new names. Origin access control keeps the S3 bucket readable only by the distribution.

The Tradeoff

A bigger cache key means fewer hits. Invalidations remove paths from the caches, but paths beyond a monthly free allowance are billed; versioned file names avoid them entirely.

Hands-On

# illustrative — bucket and distribution ID are placeholders
aws s3 cp app.3f9a1c.js s3://site-bucket/js/ \
  --cache-control "public, max-age=31536000, immutable"
aws cloudfront create-invalidation --distribution-id E2EXAMPLE \
  --paths "/index.html" "/css/*"

Your turn

Put the steps in the right order.

  1. The origin returns the object with a Cache-Control header
  2. Both cache layers keep a copy; later requests are hits
  3. A viewer requests /app.js from the nearest edge location
  4. The edge misses and asks the regional edge cache, which misses too

Mini quiz

1 / 3

Putting every cookie and query string into the cache key:

Sources

New lessons land every few weeks

Leave an address and we will tell you when the next one is up. That is the only reason we will use it.

One address, stored so we can email you. Nothing else, ever.