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.
- The origin returns the object with a Cache-Control header
- Both cache layers keep a copy; later requests are hits
- A viewer requests /app.js from the nearest edge location
- 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
- How CloudFront delivers content — Amazon CloudFront Developer Guide
- Manage how long content stays in the cache — Amazon CloudFront Developer Guide
- Invalidate files to remove content — Amazon CloudFront Developer Guide
- Restrict access to an Amazon S3 origin — Amazon CloudFront Developer Guide