Filter concepts by levelShowing all levels.

AWS · CloudFront and Edge Delivery

CloudFront and Edge Delivery

The distribution model, S3 vs ALB origin patterns, and keeping cached content fresh

  • Distribution → cache behavior → policiescache key vs origin-forwarded data, kept separate
  • S3 + OAC for static, ALB for dynamicone distribution can mix both by path
  • 24h default TTLif the origin sends no cache-control headers
  • Versioned filenames > invalidationAWS's own recommendation — free, and reaches every cache layer

1.CloudFront Core Vocabulary

A distribution tells CloudFront where to get content (the origin — S3, an ALB, a custom HTTP server) and how to cache and route it. Cache behaviors match request paths to specific settings; a cache policy controls what varies the cache key (headers, cookies, query strings); an origin request policy controls what gets forwarded to the origin. Edge locations are the worldwide points of presence that actually cache and serve content close to viewers.

Key features

  • Distribution: the CloudFront configuration tying together origins, cache behaviors, and delivery settings
  • Origin: where CloudFront fetches uncached content from — an S3 bucket, ALB, API Gateway, or custom HTTP server
  • Cache behavior: path-pattern-based rules (e.g. /api/* vs /images/*) each with their own cache/origin-request policy
  • Cache policy: controls what becomes part of the cache key (headers, cookies, query strings) — the wider the key, the lower the hit rate
  • Origin request policy: controls what additional information is forwarded to the origin on a cache miss
  • Edge locations: CloudFront's worldwide points of presence that cache and serve content close to each viewer
A request through CloudFront
routed toon a miss,matched byfetches from

Viewer request

Nearest edge location

cache hit → served immediately

Cache behavior match

by path pattern

Origin (S3, ALB, custom)

fetched only on a cache miss

  • Viewer request
    • leads to Nearest edge location (routed to)
  • Nearest edge location — cache hit → served immediately
    • leads to Cache behavior match (on a miss, matched by)
  • Cache behavior match — by path pattern
    • leads to Origin (S3, ALB, custom) (fetches from)
  • Origin (S3, ALB, custom) — fetched only on a cache miss

Signature

Distribution → cache behavior → cache policy + origin request policy

Distribution ties origins + cache behaviors together. Cache policy = what varies the cache key. Origin request policy = what gets forwarded to the origin on a miss. Keep the cache key as narrow as the content actually requires.

2.CloudFront + S3 vs CloudFront + ALB Patterns

CloudFront + S3 fits static content (images, JS/CSS bundles, downloads) — Origin Access Control keeps the bucket private, reachable only through CloudFront. CloudFront + ALB/API Gateway fits dynamic content where responses vary per request — CloudFront still helps with TLS termination, edge caching of cacheable responses, and DDoS absorption, even when most responses aren't cached at all.

Key features

  • CloudFront + S3: Origin Access Control (OAC) restricts the bucket to be reachable only via CloudFront, keeping it otherwise private
  • CloudFront + ALB/API Gateway: fits dynamic, per-request content — TLS termination and DDoS absorption still apply even with low cache hit rates
  • A single distribution can mix both — different cache behaviors (by path) can route to different origins (e.g. /static/* → S3, /api/* → ALB)
  • Default expiration for cached content is 24 hours if the origin sends no explicit caching headers

Choosing the origin pattern

Choosing the origin pattern
Content typePattern
Static assets (images, JS/CSS, downloads)CloudFront + S3, with Origin Access Control
Dynamic API responses, mostly uncacheableCloudFront + ALB/API Gateway
A single app serving bothOne distribution, path-based cache behaviors routing to each origin
One distribution, two origins by path

/static/* → S3 (via OAC)

  • A warehouse of finished goods
  • Bucket stays private, reachable only via CloudFront
  • Fully cacheable at the edge

/api/* → ALB

  • A kitchen cooking each order fresh
  • TLS termination + DDoS absorption still apply
  • Mostly uncacheable, and that's fine
  • /static/* → S3 (via OAC)
    • A warehouse of finished goods
    • Bucket stays private, reachable only via CloudFront
    • Fully cacheable at the edge
  • /api/* → ALB
    • A kitchen cooking each order fresh
    • TLS termination + DDoS absorption still apply
    • Mostly uncacheable, and that's fine

Command

text
S3 origin: bucket kept private, OAC grants CloudFront-only read access
ALB/API origin: TLS termination + DDoS absorption apply, even with a low cache hit rate

CloudFront + S3 (via Origin Access Control) fits static content, kept otherwise private. CloudFront + ALB/API Gateway fits dynamic content — TLS termination and DDoS absorption still apply even with a low cache hit rate. One distribution can mix both via path-based cache behaviors.

3.Cache Keys, TTL, and Invalidation

TTL controls how long an edge location keeps a cached response before checking the origin again — 24 hours by default if the origin sends no caching headers. Invalidation forces a manual cache clear but costs money and does not reach caches CloudFront does not control (browser, corporate proxy). AWS's own recommendation for frequently-updated content is versioned filenames instead of invalidation.

Key features

  • Default TTL: 24 hours if the origin sends no explicit cache-control headers
  • Invalidation requests cost money past a free monthly allotment — versioned filenames do not
  • Invalidation does not clear caches CloudFront does not control — browser caches or corporate proxies may still serve the old version until their own TTL expires
  • AWS's own recommendation for frequently-updated content: use versioned filenames (e.g. app.a1b2c3.js) rather than invalidation
  • Versioned filenames also make cache-hit debugging and access-log analysis easier, since each version has a distinct, traceable name

Command

bash
aws cloudfront create-invalidation --distribution-id ABCDEF --paths "/images/*"

TTL defaults to 24 hours with no origin caching headers. Invalidation costs money past a free allotment and never reaches caches outside CloudFront (browser, proxy). Prefer versioned filenames over invalidation for frequently-updated content — AWS's own recommendation.

Remember

  • A cache policy controls the cache key; an origin request policy controls what is forwarded to the origin — two separate, easily-confused settings.
  • Every extra header/cookie/query-string in the cache key multiplies distinct cache entries — keep it as narrow as the content requires.
  • Origin Access Control keeps an S3 origin bucket private, reachable only through CloudFront — never make it directly public "for CloudFront to reach it."
  • Invalidation never reaches caches CloudFront doesn't control (browser, corporate proxy) — versioned filenames do, for free.

Pro tip

  • CloudFront in front of a mostly-uncacheable API still adds value: TLS termination at the edge and DDoS absorption, independent of hit rate.

Next up

  • Databases — RDS
  • Aurora — Working Knowledge
  • DynamoDB

Sources

  • What is Amazon CloudFront — docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
  • Invalidate files to remove content — docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
  • Checked against official AWS documentation 2026-08-21

Spotted a mistake on this page? Tell us.