Question

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?

Answer 1

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.