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 (Default 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 default TTL value, then verify that the origin's caching headers don't conflict.

Resolution

Identify the caching headers that conflict

Verify whether the origin's caching headers conflict with your distribution's custom object caching.

The Minimum TTL and Default TTL are set to 0, but there are still cached 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 came from the cache of the edge location. In a refresh hit, CloudFront revalidates with the origin that the expired object isn't modified, and then refreshes when the object is stale.

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 comes from the CloudFront cache. 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 came from the origin and not the cache.

If the Cache-Control value 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. If Cache-Control is private, then CloudFront should only store the response in private caches, such as the local cache for a browser.

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 examples, Minimum TTL is set to 0. If Minimum TTL is greater than 0, then CloudFront caches the object, even if the response has no-cache, no-store, or private directives. For more information, see Specify the amount of time that CloudFront caches objects.

CloudFront caches error responses

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

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.

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

The following example is an error from an Amazon Simple Storage Service (Amazon S3) origin that's 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 override your distribution's custom object caching, update the origin.

Complete the following steps:

1. Identify where the headers are in the web server configuration.
2. Remove the lines where the headers are applied.
3. Restart the server.
4. Test your origin to check that the caching headers no longer return 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)