What is TTL 0 in CloudFront?

A few weeks ago, Amazon announced that they had reduced the duration of the content:

Amazon CloudFront lowers minimum content expiration

So much that you can really set the TTL in CloudFront to 0. So my question is why it would be useful to have a CloudFront distribution with a TTL set to 0. It doesn’t mean any caching to me at all, so every request that gets into CloudFront, gets to the origin.

What am I missing?

+52
amazon-web-services amazon-cloudfront cdn
May 16 '12 at 2:50
source share
2 answers

This new Amazon CloudFront feature is actually extremely useful for many use cases, because the defeat started a little different than it seems at first glance and is not necessarily a problem, vice versa; while this feature was released earlier, it all comes along with the recent release of Amazon CloudFront - support for dynamic content , for example. for the issue in question:

Variable Life Time (TTL) . In many cases, dynamic content is either not cached or cached for a very short period of time, perhaps only a few seconds. In the past, CloudFront's minimum TTL was 60 minutes, since all content was considered static. The new minimum TTL value is 0 seconds. If you set the TTL for a specific source to 0, CloudFront will cache the content from that source. Then make a GET request with the If-Modified-Since heading , thus the source has a chance to signal that CloudFront can continue to use cached content if it has not changed at the beginning . [emphasis mine]

In other words, the use of TTL 0 primarily means that CloudFront delegates authority to manage the cache to the origin, that is, the origin server decides whether or not, and if CloudFront caches objects for a long time; note that a GET request with the If-Modified-Since header does not necessarily mean that the object itself is retrieved from the source, and the source can (and should) return an HTTP 304 status code - not changed , where applicable:

Indicates that the resource has not been modified since the last request. [...] Using this, saving bandwidth and processing on the server and the client, since only the header data should be sent and received in comparison with the entire page processed by the server, and then sent again using the greater bandwidth of the server and client. [emphasis mine]

Take a close look at the Mark Nottingham Caching Tutorial for more information on the mechanism and benefits of managing HTTP cache, a really important and efficient part of the HTTP architecture.

Understanding how all these parts work together can be a little difficult, respectively, in the table in the section “Specifying the minimum time when CloudFront caches objects for loadable distributions in Note How long objects remain in the cache CloudFront Edge Cache (Object Expiration) tries to summarize effects when applied in a CloudFront context with or without TTL = 0.

+105
May 16 '12 at 15:47
source share

Please note that Amazon does not say that “TTL is 0”, it says “Minimum TTL is 0”. and this is completely different. The description above is highly desirable, but there is no guarantee that Cloudfront will actually do this.

In my experiments right now, I see that the cached image remained for several minutes in the edge, until my origin has already changed.

So, I think that “Minimum TTL is 0” is probably more like “Amazon has no strict intention to cache this” and, possibly, “and it will be updated frequently.”

For applications like CMS, where the web user publishes new content, I think TTL-0 is still not enough. You still have to either invalidate the CMS or use different paths for different version numbers.

+2
Jan 26 '15 at 9:23
source share



All Articles