Why does my CloudFront distribution use the cache settings of my origin when I set up custom object caching?

Short description

When you customize object caching, you configure the Default Time to Live (TTL), Minimum TTL, and Maximum TTL. CloudFront uses the following behavior:

• If the origin doesn't return a caching header, then the CloudFront distribution uses the Default TTL.
• If the origin returns a caching header that's lower than the Minimum TTL, then the distribution uses the Minimum TTL.
• If the origin returns a caching header that's larger than the Maximum TTL, then the distribution uses the Maximum TTL.

Note: The response to the client contains the origin's caching headers even when CloudFront caches the response based on Minimum TTL or Maximum TTL. All private caches, such as a browser or proxy, can use the origin's caching header.

If your distribution doesn't cache based on your custom values, then check that the origin doesn't have conflicting caching headers.

Resolution

Identify the conflicting caching headers

Verify whether origin caching headers conflict with your distribution's custom object caching. The following resolution identifies common scenarios.

The Minimum TTL and Default TTL are set to 0, but there are still results from CloudFront

Check the response from CloudFront to verify whether the value for X-Cache is Hit from cloudfront or RefreshHit from cloudfront:

< HTTP/1.1 200 OK< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: max-age=300, Public
< Accept-Ranges: bytes
< Server: AmazonS3
< Age: 14
< X-Cache: Hit from cloudfront

If X-Cache is Hit from cloudfront or RefreshHit from cloudfront, then the request was served from the cache of the edge location.

Check the Cache-Control, Expires, and Age values in the response. If the max-age value for Cache-Control is greater than the value for Age, then the cached response is served from the CloudFront cache (not stale). If the Expires date is still in the future, then the cached response is also not stale. This is expected behavior even if the cache behavior path has Minimum TTL and Default TTL set to 0.

Note: In the preceding example, the Maximum TTL is greater than 0. When all TTL values are set to 0, caching is off.

The Maximum TTL and Default TTL are greater than 0, but there are misses from CloudFront

Check the response from CloudFront to verify whether the value for X-Cache is Miss from cloudfront:

< HTTP/1.1 200 OK< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: no-cache, no-store
< Accept-Ranges: bytes
< Server: AmazonS3
< X-Cache: Miss from cloudfront

If X-Cache is Miss from cloudfront, then the request was retrieved from the origin and wasn't served by the cache.

Check the Cache-Control value in the response. If Cache-Control is no-store, then the header directs CloudFront to not cache the response. If Cache-Control is no-cache, then the header directs CloudFront to verify with the origin before it returns a cached response.

These behaviors override the Maximum TTL and Default TTL settings.

Note: Responses that aren't from the cache don't have an Age header.

In the preceding example, Minimum TTL is set to 0. When minimum TTL is greater than 0, CloudFront caches the object even if the response has the no-cache or no-store header. For more information, see Specify the amount of time that CloudFront caches objects.

CloudFront is caching error responses

CloudFront forwards error responses from the origin to the client by default. CloudFront caches the origin's error response for 10 seconds.

If the origin's error response contains a Cache-Control header, then CloudFront caches the error with the relevant TTL instead of the default 10 seconds. CloudFront doesn't cache its own error responses, unless specified otherwise in a custom error response.

To check whether the error response is from the origin or CloudFront, check the Server value. To check whether the error is a cached response, check if the response includes the Age header.

The following example is an error from an Amazon Simple Storage Service (Amazon S3) origin that is a cached response:

< HTTP/1.1 403 Forbidden
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 21:07:51 GMT
< Server: AmazonS3
< Age: 12
< X-Cache: Error from cloudfront

The following example is an error from CloudFront that isn't a cached response:

< HTTP/1.1 403 Forbidden
< Server: CloudFront
< Date: Sat, 03 Feb 2018 21:14:53 GMT
< Content-Type: text/xml
< Content-Length: 146
< Connection: keep-alive
< X-Cache: Error from cloudfront

Update the origin

After you identify the caching headers that are overriding your distribution's custom object caching, update the origin:

1. Identify where in the web server configuration that the headers are applied.
2. Remove the lines where the headers are applied.
3. Restart the server.
4. Test your origin directly to check that the caching headers are no longer returned in the response.
5. Run an invalidation on your entire CloudFront distribution to apply the change.

Related information

Cache content based on request headers

Manage how long content stays in the cache (expiration)