CloudFront cache TTL calculator

Paste the Cache-Control header your origin returns (with or without the header name), and an Expires time if it sends one. Choose a managed cache policy or type your own minimum, default and maximum TTL. The calculator applies the rules from the CloudFront Developer Guide and says which input decided.

The lower half follows one object through CloudFront's layers. Set how many requests a second it gets, across how many edge locations, and how many cache key variants there are: different values of headers, cookies or query strings that the cache policy includes in the key. Each variant is cached separately.

Every CloudFront cache behaviour has three TTL settings, from the cache policy or the legacy cache settings: a minimum, a default and a maximum. CloudFront combines them with the origin's headers as follows:

• If the response has s-maxage, CloudFront uses it; otherwise max-age; otherwise the time until Expires. The value is raised to the minimum TTL if it is below it and lowered to the maximum TTL if it is above it.
• If the response has none of those, CloudFront uses the default TTL, or the minimum TTL if that is larger.
• If the response says no-cache, no-store or private, CloudFront respects it when the minimum TTL is 0 and caches for the minimum TTL otherwise.

So with the legacy defaults or CachingOptimized, a response with no caching headers is kept for 24 h, and one with max-age of two years is kept for 365 days, the maximum. With the UseOriginCacheControlHeaders policy, whose default TTL is 0, a response without caching headers is not cached at all.

A minimum TTL above 0 overrides the origin's request not to cache. The managed CachingOptimized policy, the usual choice for static content, has a minimum TTL of 1 second, so a response marked no-store or private is cached for 1 s and can be served to other users during that second. The CloudFront guide warns about this for the three managed policies with a minimum above 0. Personalised or sensitive responses belong behind a policy with a minimum TTL of 0, such as CachingDisabled or UseOriginCacheControlHeaders, where no-cache sends every request to the origin and no-store and private are not cached.

The guide adds a related warning: when the minimum or maximum TTL is above 0 and the origin cannot be reached, CloudFront may serve a copy it fetched earlier even if it was marked no-store. Sending stale-if-error=0 asks it to return the error instead.

Unless a response headers policy changes them, CloudFront passes the origin's headers on to the browser, and browsers apply them as written: the cache policy's TTLs affect only CloudFront. HTTP caching (RFC 9111) gives shared caches their own directive for this split: s-maxage applies only to shared caches and overrides max-age there. max-age=60, s-maxage=600 lets CloudFront answer for 600 s while each browser checks again after a minute, a common setup for pages that change occasionally. An invalidation can then refresh CloudFront quickly, while no browser holds a copy for more than a minute.

Two directives from RFC 5861 let a cache use an expired copy. stale-while-revalidate=N lets CloudFront answer with the expired copy for up to N seconds while it fetches a fresh one in the background, so users do not wait for the origin when the TTL runs out. stale-if-error=N lets it keep serving the expired copy for up to N seconds when the origin is unreachable or returns a 5xx error. CloudFront caps both at the maximum TTL. Together they hide both the latency of revalidation and short origin outages: max-age=600, stale-while-revalidate=60, stale-if-error=86400 keeps a page fresh for ten minutes and keeps it up for a day if the origin goes down.

A request first reaches an edge location near the user. On a miss, the edge asks a regional edge cache, a larger cache shared by the edge locations of a region, and only on a miss there does the request go further. Origin Shield, an optional extra layer, sits between all regional caches and the origin, so the origin sees at most one request per object per TTL for the whole distribution.

Each layer that keeps its own copy for the TTL sends on about one request per copy per TTL, so the origin's load depends on how many copies the top layer holds. For one object requested 100 times a second (360,000 times an hour) over 50 edge locations and 8 regional caches, the model gives:

CloudFront caches a separate copy for each distinct cache key: the URL plus whatever headers, cookies and query strings the cache policy includes. Including one with many values splits the traffic. With a 60 s TTL, adding a key component with 20 equally common values (a language header, say) lowers the edge hit ratio from 99.17% to 85.72%, and raises origin requests from 60 to 1,124 an hour with Origin Shield, or from 476 to 8,723 without it.

The cure is to include only what changes the response. The CloudFront guide separates the cache key from what is forwarded to the origin: an origin request policy can send a header to the origin without making it part of the key. Headers such as User-Agent, with thousands of values, are the classic cause of a low hit ratio; CloudFront's own device headers, such as CloudFront-Is-Mobile-Viewer, reduce them to a few values.

To replace an object before its TTL runs out, CloudFront offers invalidation: a request to remove given paths from every cache, after which the next request goes to the origin. It takes time to reach every location and does nothing for copies already in browsers. The alternative is to put a version or a content hash in the file name, such as app.3f9a2c.js, and change the reference in the HTML; the new name is a new cache key, the old copy simply expires, and both CloudFront and browsers can then cache files for the maximum TTL. The CloudFront guide recommends versioned names for files that change often, partly because an invalidation cannot reach copies already held by browsers or corporate proxies.