Why can CloudFront keep returning an error after the origin page is fixed?

Definition: CloudFront can keep returning an error because it caches error responses at edge locations. The Error Caching Minimum TTL sets how long a cached 4xx or 5xx response can continue to represent an origin problem after the requested object becomes available again.

Key facts

• CloudFront caches error responses for a default duration of 10 seconds, then sends the next request for the object to the origin. Amazon's error caching documentation describes this sequence.
• You can set an Error Caching Minimum TTL for each 4xx and 5xx status code that CloudFront caches, and a long value can keep an error response or custom error page visible after the object is available again.
• An origin Cache-Control: max-age, Cache-Control: s-maxage, or Expires value makes CloudFront use the greater value between that header and the Error Caching Minimum TTL.
• For error codes 404, 410, 414, and 501, no-store, no-cache, or private prevents error caching. CloudFront ignores those directives for other error codes and uses the Error Caching Minimum TTL.
• When the cached error lasts longer than wanted, CloudFront's documentation says to invalidate the URL of the requested object. Each affected object needs its own invalidation.

How can an old error survive an origin fix?

When the origin first returns an error, CloudFront stores the error response according to the configured error-caching rules. A later viewer request can therefore receive the stored error or a custom error page without reaching the fixed origin. The CloudFront error caching guide says that the next origin request happens when the error-caching duration elapses.

The setting is per status code. A distribution can therefore apply different error cache durations to different 4xx and 5xx responses. A shorter duration sends more requests to the origin, while a longer duration reduces those requests and can extend the period during which an old error is served. CloudFront does not cache status code 416 responses, even when an Error Caching Minimum TTL is configured for that code.

Which response headers affect the error cache?

The origin can supply a cache lifetime for an individual error response. According to the CloudFront documentation on error expiration, max-age, s-maxage, and Expires are compared with the Error Caching Minimum TTL, and CloudFront uses the greater value. Those cache-control values cannot exceed the Maximum TTL configured for the cache behavior that fetches the error page.

For 404, 410, 414, and 501, the origin can send Cache-Control: no-store, no-cache, or private to keep that error response out of the cache. For other error codes, CloudFront ignores those three directives and caches the response for the Error Caching Minimum TTL. If the origin sends another Cache-Control directive or no headers, CloudFront uses that minimum value.

How do you remove the cached error?

If the object is available again and its error expiration is longer than wanted, invalidate the URL of the requested object. The CloudFront invalidation guide states that the next viewer request after invalidation goes back to the origin for the latest version. When several objects returned errors, invalidate each object separately.

In the CloudFront console, choose the distribution, open Invalidations, choose Create invalidation, and enter one invalidation path per line. The CloudFront invalidation procedure also documents the AWS CLI form for a wildcard path:

aws cloudfront create-invalidation --distribution-id {{distribution_ID}} --paths "/*"

The same procedure says to quote a path containing *, and warns that an invalidation cannot be cancelled after submission. An invalidation removes the CloudFront edge copy. A viewer or intermediary cache outside CloudFront can still hold an older response until its own expiration.

What should you check first?

Check the response status, the cache behavior that serves the URL, and the Error Caching Minimum TTL for that status code. Then check whether the origin response includes max-age, s-maxage, Expires, or one of the directives that affects 404, 410, 414, and 501. If the origin is fixed and the stored error must be removed immediately, submit an invalidation for the requested object path.

Related terms

• Can CloudFront return a successful status for an origin error page?
• How does CloudFront combine origin cache headers with error cache settings?
• Can CloudFront completely disable error caching for an S3 origin?

FAQ

Does fixing the origin clear an existing CloudFront error?

No. CloudFront can continue serving the cached error or custom error page until the error-caching duration expires. An invalidation removes the relevant edge copy sooner.

Does setting Error Caching Minimum TTL to zero always prevent errors from being cached?

For an S3 bucket origin, CloudFront still uses an error caching minimum TTL of 1 second when the configured value is 0 seconds. The documented S3 protection does not apply to other origin types.

Should you invalidate one path or several paths?

Use the URL of the requested object. When multiple objects returned errors, CloudFront's error caching documentation says to invalidate each object separately.

Sources

1. Amazon CloudFront, "Control how long CloudFront caches errors", undated
2. Amazon CloudFront, "Invalidate files to remove content", undated
3. Amazon CloudFront, "Invalidate files", undated

---

Check how a page reads to answer engines. Open the GEO score analyzer