I set custom object caching on my CloudFront distribution. Why is my distribution using the cache settings of my origin?

5 minute read
0

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?

Short description

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

  • If the origin doesn't return a caching header, then the distribution uses the Default TTL.
  • If the origin returns a caching header that's less than the Minimum TTL, then the distribution uses the Minimum TTL.
  • If the origin returns a caching header that's greater 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. 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, then check the origin. Verify whether the origin has any conflicting caching headers.

Resolution

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, then check the response from CloudFront. Verify whether the response 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, then the cached response is considered new and is served from the edge location. If the Expires date is still in the future, then the cached response is also considered new. This occurs 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 the response from CloudFront. Verify whether the response 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-store," then the header is directing CloudFront to not cache the response. If the value for Cache-Control is "no-cache," then the header is directing CloudFront to verify with the origin before returning a cached response. These directives supersede 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 10 seconds by default.

If the error response from the origin contains a Cache-Control header, CloudFront caches the error with 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 (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

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.

Related information

Caching content based on request headers

AWS OFFICIAL
AWS OFFICIALUpdated 2 years ago