CloudFront in practice: distributions, origins, and cache behaviors

A CloudFront distribution is the top-level object tying everything together. It has one or more origins (where content actually comes from — an S3 bucket, an ALB, any HTTP server) and one or more cache behaviors (rules mapping URL path patterns to which origin handles them, and how caching should work for that pattern).

This is the practical shape of the CDN concept from the Cloud Computing domain's CDN lesson: static assets (images, JS bundles) served from an S3 origin with long cache times, API calls forwarded to a dynamic origin with caching mostly or entirely disabled, all through the same distribution and the same custom domain.

Origin Access Identity (or its newer replacement, Origin Access Control) is a CloudFront-managed identity that's granted read access to a private S3 bucket, so the bucket never needs to be made public — users only ever reach the content through CloudFront, and direct requests to the bucket's own S3 URL are denied. This is the correct pattern for static-asset origins: keep the S3 bucket private (per the S3 lesson's default-private guidance), and let OAI/OAC be the only thing with read access to it.

Exactly like the Cloud Computing domain's CDN lesson warns generically — a header, cookie, or query string that changes the response but isn't included in what CloudFront varies on will cause the wrong cached response to be served to the wrong user. The forwarded_values block above is where that's controlled: query_string = true includes query strings in the cache key (so ?page=1 and ?page=2 cache separately), headers = ["Authorization"] means CloudFront will vary its cache by that header specifically rather than caching one response for everyone regardless of who's authenticated — critical for a per-user API response, and exactly the kind of misconfiguration that leaks one user's data to another if it's left off.

An invalidation manually purges cached content from CloudFront's edge locations before its TTL naturally expires — needed when content at a fixed URL changes and can't wait for the cache to expire on its own (as opposed to the versioned-URL strategy covered generically in the Cloud Computing domain, which avoids needing invalidation at all for assets that can have a new filename per deploy).

Invalidations aren't instant (can take minutes to propagate to all edge locations globally) and, beyond a monthly free allowance, cost money per path — exactly why the versioned-URL approach is preferred for anything that can use it, with invalidation reserved for the smaller set of fixed-URL content that genuinely needs it.