Menu
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?
896
a 0 TTL results in a client making an If Modified Since request, hence if the content has not be modified, it will be served from the local cache. If the content has no-cache, it will be fetched everytime regardless of it being expired or not.
Amazon CloudFront now lets you configure a Default TTL and a Maximum time-to-live (Max TTL) to specify how long CloudFront caches your objects in edge locations. These new settings enhance the control over cache duration that you already had with the Minimum TTL setting (Min TTL).
Minimum TTL Specify the minimum amount of time, in seconds, that you want objects to stay in CloudFront caches before CloudFront forwards another request to your origin to determine whether the object has been updated. The default value for Minimum TTL is 0 seconds.
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.
87
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
