What is a TTL 0 in CloudFront useful for?

Some weeks ago Amazon announced that they have lowered the content expiration period:

Amazon CloudFront Lowers Minimum Content Expiration Period

So much that you can actually set now TTL in CloudFront to 0. So my question is, why could it be useful to have a CloudFront distribution with TTL set to 0. To me this means no caching at all so every request that gets to CloudFront will end up hitting the origin.

What am I missing?

This new feature of Amazon CloudFront is actually extremely useful for many use cases, because hitting the origin works a bit different than it looks at first sight and is not necessarily a problem, to the contrary; while this feature has been released earlier already, it all comes together with the recent release of Amazon CloudFront - Support for Dynamic Content, e.g. for the question at hand:

> Variable Time-To-Live (TTL) - In many cases, dynamic content is either > not cacheable or cacheable for a very short period of time, perhaps > just 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 particular origin to 0, > CloudFront will still cache the content from that origin. It will then > make a GET request with an If-Modified-Since header, thereby giving > the origin a chance to signal that CloudFront can continue to use the > cached content if it hasn't changed at the origin. [emphasis mine]

In other words, using a TTL of 0 primarily means, that CloudFront delegates the authority for cache control to the origin, i.e. the origin server decides whether or not, and if for how long CloudFront caches the objects; please note specifically, that a GET request with an If-Modified-Since header doesn't necessarily mean that the object itself is retrieved from the origin, rather the origin can (and should) return the HTTP status code 304 - Not Modified where applicable:

> Indicates the resource has not been modified since last requested. [...] > Using this saves bandwidth and reprocessing on both the server and > client, as only the header data must be sent and received in > comparison to the entirety of the page being re-processed by the > server, then sent again using more bandwidth of the server and client. [emphasis mine]

See Mark Nottingham's excellent Caching Tutorial for details on the mechanics and benefits of HTTP cache control, a really important and effective part of the HTTP architecture.

Understanding how all these parts work together can be a bit difficult indeed, accordingly the table in section Specifying the Minimum Time that CloudFront Caches Objects for Download Distributions within Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration) attempts to summarize the effects when applied in the context of CloudFront with or without TTL = 0 specifically.

Note that Amazon is not saying "TTL is 0", it is saying "Minimum TTL is 0". and that is very different. The description above is very desirable but there is no guarantee that Cloudfront actually does it.

In my experiences right now, I can see a cached image stay for a few minutes in the edge while my origin has it changed already.

So, I think saying "Minimum TTL is 0" is probably more like "Amazon has no strict intent to keep this in a cache", and maybe "and it will refetch often".

For applications like CMSs, where the web user is posting new content, I think TTL-0 is still not sufficient. You still have to either invoke invalidations from the CMS or employ different paths for different version numbers.

CloudFront can be used in combination with certificate manager to add HTTPS support to S3 websites. You might want this, but zero caching.

Another use case for this is If you want to manipulate the headers of the request for non-cacheable content using lambda edge https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html. Example x-api-key.