In short. CloudFront uses the greater of selected origin freshness values and Error Caching Minimum TTL, with a special no-store rule for four errors.
Definition: CloudFront uses the configured Error Caching Minimum TTL as the baseline for cached error responses. An origin
max-age,s-maxage, orExpiresvalue can extend that duration, whileno-store,no-cache, andprivatesuppress error caching only for status codes 404, 410, 414, and 501.
Key facts
- Amazon's CloudFront error caching documentation says the default error caching duration is 10 seconds.
- CloudFront uses the greater of the origin's
max-age,s-maxage, orExpiresvalue and the Error Caching Minimum TTL. - For error codes 404, 410, 414, and 501, the origin directives
no-store,no-cache, andprivatemake CloudFront skip the cached error response. - For other error codes, CloudFront ignores those three directives and uses the Error Caching Minimum TTL.
- RFC 9111 defines
no-storeas a response directive that prevents a cache from storing or reusing the response, subject to the standard'smust-understandexception.
What is the precedence between the origin and the CloudFront setting?
The Error Caching Minimum TTL is the floor for an error that CloudFront caches. Amazon's documentation says that the origin can control the duration for an individual object's error response by sending a cache header. With Cache-Control: max-age, Cache-Control: s-maxage, or Expires, CloudFront selects the greater duration. A header value therefore can lengthen the configured minimum, but a smaller header value cannot shorten it.
The same page limits max-age and s-maxage to the Maximum TTL configured for the cache behavior that fetches the error page. That limit applies to those two Cache-Control values. The page describes Expires as another input to the greater-of comparison.
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>
Expires: <HTTP-date>
RFC 9111 describes the general HTTP model behind these fields. max-age makes a response stale after the stated number of seconds. For a shared cache, s-maxage takes precedence over max-age and Expires, and Expires supplies the date after which a response is stale when a stronger directive is absent.
When does no-store prevent an error from being cached?
CloudFront gives special treatment to three response directives for four error codes. If the origin sends no-store, no-cache, or private with status 404, 410, 414, or 501, CloudFront does not cache the error response. For every other error code covered by the page, CloudFront ignores these directives and caches the error for the Error Caching Minimum TTL.
Cache-Control: no-store
Cache-Control: no-cache
Cache-Control: private
The HTTP standard gives these directives different general meanings. no-store tells a cache to avoid storing any part of the request or response and to avoid using the response for another request. An unqualified no-cache response must be validated before reuse. private tells a shared cache not to store the response. CloudFront's documented status-code rule is therefore the product behavior to check for these error responses.
If the origin sends another Cache-Control directive, or sends no headers, Amazon documents the result as caching for the Error Caching Minimum TTL. A 416 response is a separate exception: CloudFront does not cache it even when a value is configured for status code 416.
What should you inspect in a response?
Inspect the origin response status and the cache headers together. Record whether the status is one of 404, 410, 414, or 501, then check for no-store, no-cache, or private. For other statuses, compare the Error Caching Minimum TTL with max-age, s-maxage, or Expires, and check the cache behavior's Maximum TTL when either of the two numeric Cache-Control directives is present.
CloudFront can continue returning a cached error until its error-caching duration elapses. Amazon also documents URL-based invalidation for an error cached longer than desired, with a separate invalidation required for each object when the origin returns errors for multiple objects.
Related terms
- Cache-Control
- Why can CloudFront keep returning an error after the origin page is fixed?
- Can CloudFront completely disable error caching for an S3 origin?
- Does adding Cache-Control through a CloudFront response policy change edge caching?
FAQ
Does max-age=0 always disable CloudFront error caching?
No. CloudFront compares the origin value with the Error Caching Minimum TTL and uses the greater value. The selected no-store, no-cache, and private rule is a separate status-code condition.
Does no-store have the same effect for every CloudFront error?
No. The documented no-cache treatment applies to 404, 410, 414, and 501. For other error codes, CloudFront ignores no-store, no-cache, and private and applies the Error Caching Minimum TTL.
Can a configured value of zero mean that no error response is cached?
Only for the cases covered by CloudFront's other rules. Status code 416 is not cached, while the four selected error codes can avoid caching when one of the three directives is present. The configured minimum remains the baseline for other cached errors.
Sources
- Amazon Web Services, "Control how long CloudFront caches errors", undated
- Internet Engineering Task Force, "RFC 9111: HTTP Caching", June 2022
Check how a page reads to answer engines. Open the GEO score analyzer