For a image gallery I use amazon cloudfront.
I have set at the origin:
Cache-Control:max-age=31536000 (1 Year)
1. Is it usefull to set the TTL 0 (24 hours) to 1 Year too when I have already set the max-age?
2. Will amazon check the file with TTL0 every 24 hours when I have set the max-age to 1 year?
Amazon is saying:
Objects are cached for the greater of the value of the Cache-Control max-age directive or the value of the CloudFront Minimum TTL
Amazon is also saying:
If an object in an edge location isn't frequently requested, CloudFront might evict the object—remove the object before its expiration date—to make room for objects that are more popular.
In that case, I think its usefull to set TTL to year, because the images will stay for sure and not before? Please correct me.
Thanks for clarification.
This question is essentially answered in the answer to Cloudfront TTL not working although the question is not exactly a duplicate.
No, the minimum TTL is not especially useful if you are setting your own Cache-Control: headers.
No, Cloudfront will not check every 24 hours if your minimum TTL or your Cache-Control: headers specify an age longer than 24 hours. If an object is going to be checked by Cloudfront, the object needs to be expired. The point of the maximum allowable age, from the perspective of a cache like Cloudfront, is that until the maximum allowable age expires, no check is needed, because the object is not expected to be stale.
The time to live (TTL) (not "minimum TTL," just the TTL as a general concept) is the maximum amount of time that a cache, like Cloudfront, is supposed to serve up a copy of an object without verifying, with the origin server, that its copy of the object is not stale. The time to live is the maximum allowable age the cache can retain an object without verifying its freshness.
The minimum TTL is not the minimum amount of time the object should be cached.
The minimum TTL is the minimum value to be used in determining the maximum allowable age. It's the minimum value for the TTL, and only specifies a minimum lower boundary on the maximum age, such that a conflicting Cache-Control: header specifying a shorter TTL than the minimum TTL will be disregarded, overridden, increased upward, using the minimum TTL instead (to determine the maximum allowable age in the cache of the object).
Similarly, in the absence of any other directives, the minimum TTL is used as the sole determinant of what the maximum life of the object, in the cache, is to be.
So, no, setting both the minimum TTL and the Cache-Control: header to a comparably large value will have no effect, because, as you correctly point out:
Objects are cached for the greater of the value of the Cache-Control max-age directive or the value of the CloudFront Minimum TTL
— http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
This statement, however, must be read with an understanding of the nature of caching. Content stored by a cache -- by the nature of a cache, generally -- is volatile and ephemeral and can be evicted at any time. As you have also noted:
If an object in an edge location isn't frequently requested, CloudFront might evict the object—remove the object before its expiration date—to make room for objects that are more popular.
This is not something that can be avoided with configuration of Cloudfront or your origin server. Sometimes objects are evicted. They may be, and often are, held for as long as the maximum age permits, and sometimes longer.
Typically, CloudFront serves an object from an edge location until the object expires. After it expires, the next time the edge location gets an end-user request for the object, CloudFront forwards the request to the origin server to verify that the cache contains the latest version of the object:
If CloudFront already has the latest version, the origin returns only a 304 status code (not modified).
If you are not familiar with 304 Not Modified, you may wish to research it, along with the If-Modified-Since: request header that typically triggers this response from your origin server. (Of course, in the case where you're caching the results of, say, a dynamic image resize operation, your origin will never be able to respond 304 unless it has retained a local copy of its own prior response to the request.)
Also significant and often overlooked is the fact that Cloudfront is not a single entity. It is not accurate to say that a specific object either "is stored in" or "is not stored in" Cloudfront at any given moment in time. There are over 50 edge locations as of this writing, and an object may be stored in some edge locations and not in others. It may be evicted early from one edge location, but not from others. At edge locations through which an object has never been requested, it will never be stored until the first request occurs that causes it to be fetched.