My Amazon CloudFront distribution has a cache behavior with object caching set to Customize, but my distribution still uses the cache settings of my origin. How can I fix this?

When you customize object caching, you configure the Default TTL, Minimum TTL, and Maximum TTL. Amazon CloudFront uses these parameters based on whether the origin returns a caching header:

  • If the origin doesn't return a caching header, the distribution uses the Default TTL.
  • If the origin returns a caching header that's less than the Minimum TTL, or greater than the Maximum TTL, then the distribution uses the respective Minimum TTL or 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. The origin's caching header can be used by any private cache, such as a browser or proxy.

If your CloudFront distribution isn't caching based on the custom values that you set on cache behaviors, verify whether there are any conflicting caching headers from the origin.

To verify whether origin caching headers conflict with your distribution's custom object caching, follow these instructions based on the issues you're seeing:

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

If there are hits from CloudFront even when a request URI matches a cache behavior path with Minimum TTL and Default TTL set to 0, check whether the response from CloudFront shows the X-Cache header as "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 the X-Cache header is "Hit from cloudfront" or "RefreshHit from cloudfront," then the request was served from the cache of the edge location.

Review the rest of the response for the Cache-Control, Expires, and Age headers. The Cache-Control and Expires headers are behavioral caching headers that tell the intermediary (CloudFront) or private (browser) cache how to store a request. The Age header shows how long a response has been cached.

If the max-age value for Cache-Control is greater than the value for Age, or the Expires date is still in the future, then the cached response is considered new and is served from the edge location, even if the cache behavior path has Minimum TTL and Default TTL set to 0.

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

If there are misses from CloudFront even when a request URI matches a cache behavior path with Maximum TTL and Default TTL set to values greater than 0, check if the response from CloudFront shows the X-Cache header as "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 the X-Cache header is "Miss from cloudfront," then the request was retrieved from the origin and wasn't served by the cache.

Review the Cache-Control header in the response. If the value for Cache-Control is "no-cache" or "no-store," then the header is directing CloudFront to not cache the response, or to verify with the origin before returning a cached response. This directive supersedes the Maximum TTL and Default TTL CloudFront settings.

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

CloudFront is caching error responses

By default, CloudFront forwards error responses from the origin to the client. Additionally, CloudFront caches the origin's error response for 5 minutes (300 seconds).

If the error response from the origin contains a Cache-Control header, CloudFront caches the error according to the relevant TTL instead of the default 5 minutes. CloudFront doesn't cache its own error responses, unless specified otherwise in a custom error response.

To determine whether the error response is from the origin or Cloudfront, check the Server header. To determine whether the error is a cached response, check the Age header—a cached response includes an Age header.

The following example is an error from an Amazon Simple Storage Service (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

After you identify the conflicting caching headers, update the origin

After you determine which caching headers are superseding your distribution's custom object caching, follow these steps:

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

Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2018-06-05