.htaccess - Cloudfront max-age together with TTL usefull? -

for image gallery use amazon cloudfront.

i have set @ origin:

cache-control:max-age=31536000 (1 year) 

1. usefull set ttl 0 (24 hours) 1 year too when have set max-age?

2. amazon check file ttl0 every 24 hours when have set max-age 1 year?

amazon saying:

objects cached greater of value of cache-control max-age directive or value of cloudfront minimum ttl 

amazon saying:

if object in edge location isn't requested, cloudfront might evict object—remove object before expiration date—to make room objects more popular. 

in case, think usefull set ttl year, because images stay sure , not before? please correct me.

thanks clarification.

this question answered in answer cloudfront ttl not working although question not duplicate.

no, minimum ttl not useful if setting own cache-control: headers.

no, cloudfront not check every 24 hours if minimum ttl or cache-control: headers specify age longer 24 hours. if object going checked cloudfront, object needs expired. point of maximum allowable age, perspective of cache cloudfront, until maximum allowable age expires, no check needed, because object not expected stale.

the time live (ttl) (not "minimum ttl," ttl general concept) maximum amount of time cache, cloudfront, supposed serve copy of object without verifying, origin server, copy of object not stale. time live maximum allowable age cache can retain object without verifying freshness.

the minimum ttl not minimum amount of time object should cached.

the minimum ttl minimum value used in determining maximum allowable age. it's minimum value ttl, , specifies minimum lower boundary on maximum age, such conflicting cache-control: header specifying shorter ttl minimum ttl disregarded, overridden, increased upward, using minimum ttl instead (to determine maximum allowable age in cache of object).

similarly, in absence of other directives, minimum ttl used sole determinant of maximum life of object, in cache, be.

so, no, setting both minimum ttl , cache-control: header comparably large value have no effect, because, correctly point out:

objects cached greater of value of cache-control max-age directive or value of cloudfront minimum ttl

^{— http://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/expiration.html}

this statement, however, must read understanding of nature of caching. content stored cache -- nature of cache, -- volatile , ephemeral , can evicted @ time. have noted:

if object in edge location isn't requested, cloudfront might evict object—remove object before expiration date—to make room objects more popular.

this not can avoided configuration of cloudfront or origin server. objects evicted. may be, , are, held long maximum age permits, , longer.

typically, cloudfront serves object edge location until object expires. after expires, next time edge location gets end-user request object, cloudfront forwards request origin server verify cache contains latest version of object:

if cloudfront has latest version, origin returns 304 status code (not modified).

if not familiar 304 not modified, may wish research it, along if-modified-since: request header typically triggers response origin server. (of course, in case you're caching results of, say, dynamic image resize operation, origin never able respond 304 unless has retained local copy of own prior response request.)

also significant , overlooked fact cloudfront not single entity. not accurate specific object either "is stored in" or "is not stored in" cloudfront @ given moment in time. there on 50 edge locations of writing, , object may stored in edge locations , not in others. may evicted 1 edge location, not others. @ edge locations through object has never been requested, never stored until first request occurs causes fetched.