Cache Behaviors and TTL Settings

Cache behaviors are the rules that tell CloudFront how to handle requests for different URL path patterns. Each cache behavior maps a path pattern (e.g., /images/*, /api/*, *.css) to a specific origin and caching configuration.

A distribution has one Default Cache Behavior (matching all paths not caught by more specific behaviors) and up to 25 additional path-based behaviors. CloudFront evaluates behaviors in order from most specific to least specific, then falls through to the default.

Path patterns support wildcards: * matches any combination of characters including slashes, and ? matches any single character. Examples:

• /images/* — all URLs starting with /images/
• *.jpg — all requests ending in .jpg anywhere in the path
• /api/v2/* — all API v2 routes
• /static/??.css — static CSS files with exactly two characters before .css

Behaviors are evaluated in the order listed in the distribution configuration. Put more specific patterns first. The default behavior (*) always matches last.

CloudFront separates caching logic into two policy types:

• Cache Policy: defines what CloudFront uses as the cache key—the combination of headers, query strings, and cookies that determine whether a cached object matches a request. Also sets TTL bounds.
• Origin Request Policy: defines which headers, query strings, and cookies are forwarded to the origin—even if they are not part of the cache key (to send auth headers to the origin without varying the cache per token)

AWS provides managed policies (e.g., CachingOptimized, CachingDisabled) that cover most use cases, or you can create custom policies.

CloudFront respects three TTL values from the Cache Policy:

• Minimum TTL: the shortest time CloudFront caches an object, regardless of origin headers (default 0)
• Default TTL: the time CloudFront caches an object when the origin does not send a Cache-Control or Expires header (default 86,400 seconds = 1 day)
• Maximum TTL: the longest CloudFront will cache an object, capping the origin's Cache-Control max-age directive (default 31,536,000 = 1 year)

These three values bound the actual cache duration sent by origins via Cache-Control headers.

When your origin sends a Cache-Control: max-age=3600 header, CloudFront caches the object for 3,600 seconds—as long as this value falls within the Cache Policy's Minimum and Maximum TTL bounds. If the origin sends Cache-Control: no-cache or Cache-Control: no-store, CloudFront will check with the origin before serving the cached copy each time.

For static assets that rarely change, set a long max-age (e.g., 31536000 = 1 year) and use cache busting—include a content hash in filenames (e.g., app.a3f4b5.js)—so the URL changes when content changes, automatically invalidating the old cached version.

A powerful cache behavior pattern separates static and dynamic content:

• /static/*, *.css, *.js, *.jpg → S3 origin, CachingOptimized policy (high TTL, no cookies/query strings in cache key)
• /api/* → ALB origin, CachingDisabled policy (always fetched from origin, all headers/cookies forwarded)
• /* (default) → ALB origin, moderate caching

This separates the high-cacheable static tier from the dynamic API tier, maximising cache hit ratios for static content while ensuring API responses are always fresh.

When you update content in S3 or your origin and want to immediately serve the new version from CloudFront without waiting for TTL expiry, you create a cache invalidation. Specify paths to invalidate (e.g., /images/logo.png or /images/*) and CloudFront removes those objects from all edge caches.

Invalidations have a cost: the first 1,000 paths per month are free; additional paths cost per-path. Wildcard invalidations (e.g., /*) count as one path. Best practice: use versioned filenames for static assets (cache busting) instead of frequent invalidations to reduce cost and delay.

The cache key is the unique identifier CloudFront uses to look up a cached response. By default, the cache key is only the URL path. Including additional components increases the number of distinct cache entries:

• Query strings: /search?q=aws and /search?q=s3 are separate cache entries if q is in the cache key
• Headers: including Accept-Encoding lets CloudFront cache gzip and non-gzip versions separately
• Cookies: including session cookies creates per-user cache entries, effectively disabling caching

Minimise cache key components for maximum cache efficiency. Only include what genuinely produces different response content.

CloudFront can automatically compress text-based objects (HTML, CSS, JavaScript, JSON) using gzip or Brotli before delivering them to viewers. This reduces payload size by 60–80% and improves page load times without any changes to your origin.

To enable compression: ensure the Cache Policy includes Accept-Encoding in the cache key (CloudFront needs to cache gzip and non-gzip versions separately), and enable Compress Objects Automatically in the cache behavior. CloudFront compresses objects larger than 1,000 bytes and smaller than 10 MB.

The cache hit ratio is the percentage of requests served from the CloudFront cache without going to the origin. A high ratio (80%+) means lower origin costs and better performance. Monitor it via the CloudFront console Cache Statistics report or via the CacheHitRate CloudWatch metric.

Ways to improve the cache hit ratio: increase TTL values, reduce the number of headers/cookies in the cache key, use query string normalisation (forward only the query strings your application actually uses), and set appropriate Cache-Control headers at the origin.

Each cache behavior can point to a different origin, enabling a single CloudFront distribution to serve content from multiple backends. For example:

• /static/* → S3 origin (private bucket via OAC)
• /api/* → ALB origin in us-east-1
• /media/* → MediaPackage CDN origin for video streaming

Each behavior also independently configures Viewer Protocol Policy, Allowed HTTP Methods, and function associations (CloudFront Functions or Lambda@Edge). This makes a single distribution a flexible, multi-purpose delivery layer.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: cache behaviors map URL path patterns to origins and caching rules, Min/Default/Max TTL bounds control how long content is cached with the origin's Cache-Control headers taking precedence when present, and cache invalidations immediately clear stale content from all edge locations. Minimise cache key components to maximise hit ratio. Next up we explore signed URLs, signed cookies, and geo-restriction.