我了解到Cloudfront现在支持将0设置为最小TTL，我想知道它如何工作以及是否影响Cloudfront / AWS S3的成本？
Cloudfront如何知道js或CSS文件何时更改？我们在部署期间将新文件上传到S3。我不知道修改时间是否正确，但我认为是正确的。
主要问题是，将其设置为0还是像现在这样保留5分钟，并且在部署后在Cloudfront中使js / css无效，是否更便宜。有时，当我们只进行后端更改而上线时，就不需要使它们失效。多数情况下，我们也会更改css / js。
答案 0 :(得分：1)
Minimum TTL很少需要自定义。
Minimum TTL不会不定义CloudFront缓存对象的最短时间。听起来就是那样，但这是一个普遍的误解。
为帮助阐明这一点，让我首先阐明TTL。
TTL（生存时间）是CloudFront在内部为每个单个对象计算的值，目的是确定是否应完全缓存对象，然后确定是否仍在缓存中找到对象被认为是新鲜。如果某个对象在缓存中的停留时间少于其TTL，则称为“新鲜”，否则称为“过时”。
新鲜对象可以提供给查看者，而无需检查其来源。
陈旧对象应该不提供给查看者，而无需验证其来源，并最终将其清除。
CloudFront可能会在其缓存中保留过期对象一段时间。 （它可以在有条件的请求下，通过原始来验证陈旧对象是否仍然良好。它还可以在有限的条件下继续使用该陈旧对象，包括您的起源发生故障。）
CloudFront也可以随时从其缓存中清除新对象。为什么会那样做？缓存空间是免费的，因此，如果没有请求，CloudFront缓存继续存储在缓存中的所有内容就没有意义。 CloudFront可以随时从缓存中清除“不受欢迎”的对象。
由此，我们可以很清楚地知道TTL不是 “ CloudFront将对象缓存多长时间？” 而是” CloudFront会考虑将TTL多长时间？缓存的对象是否新鲜？”
如果对象的TTL计算为0，则CloudFront不会缓存该对象。
那么...一个对象将如何获得计算出的0 TTL？来自原点的响应中至少有以下标头之一：
Cache-Control: private
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: s-maxage=0
Cache-Control: max-age=0 // ignored when s-maxage is present
只有在这些情况下，Minimum TTL通常会扮演角色。 （此外，Expires HTTP标头可以触发它，但不要使用Expires －请使用Cache-Control。）
Cache-Control主要用于浏览器，但是CloudFront在尝试为每个对象计算适当的TTL时也会观察到它。
Minimum TTL在CloudFront将根据上述条件从起点的Cache-Control标头中推断出的值上确定下边界，较小的值将四舍五入。如果您的原点返回（例如）Cache-Control: private, no-cache, no-store，则该TTL应该为0 ...，但是CloudFront将该对象的内部TTL设置为 0或更大的值{strong> 0或Minimum TTL
如果响应包含（例如）Cache-Control: max-age=15，则浏览器和CloudFront都会为该对象计算15秒的TTL。如果Minimum TTL设置为300，则CloudFront会忽略原点指定的15秒，并将其对象的内部TTL设置为300秒。浏览器仍将使用15秒，因为CloudFront不会修改Cache-Control响应标头。
tl; dr：Minimum TTL是CloudFront将分配给对象的最小内部TTL值，而与原始响应中导致其计算 lower 值的值无关。将此设置从默认值0更改是一个高级选项。它没有设置CloudFront缓存对象所需的最短时间。