Amazon web services AWS Cloudfront 0最小TTL含义和；成本

我了解到Cloudfront现在支持将0设置为最小TTL，我想知道它是如何工作的，以及它是否会影响Cloudfront/AWS S3的成本

Cloudfront如何知道js或css文件何时更改？我们在部署到S3时上传新文件。我不知道修改时间是否正确，但我认为正确

---

主要的问题是，如果将其设置为0或者像我们现在这样保持5分钟，并在部署后在Cloudfront中对js/css进行无效化，是否更便宜。有时，当我们只使用后端更改时，我们不需要使其无效。大多数时候，我们也会对css/js进行更改。

最小TTL

很少需要定制

最小TTL

不定义CloudFront缓存对象的最小时间量。听起来是这样，但这是一个常见的误解

为了帮助澄清这一点，让我首先澄清TTL

TTL（生存时间）是CloudFront在内部为每个对象计算的一个值，用于确定是否应该缓存一个对象，然后确定在缓存中找到的对象是否仍然是新的。如果对象在缓存中的时间少于其TTL，则称其为“新鲜”，否则称其为“过时”

一个新的对象可以提供给一个观众，而无需检查来源

一个过时的对象应该而不是在没有与源验证的情况下被提供给查看者，并且最终应该被清除

CloudFront可能会在缓存中保留过时对象一段时间。（它可以通过有条件的请求与源站验证陈旧对象是否仍然良好。它还可以在有限的条件下继续使用陈旧对象，包括源站中断）

CloudFront还可以随时从缓存中清除新对象。为什么会这样？缓存空间是免费的，因此如果CloudFront缓存没有被请求，那么继续将其存储在缓存中是没有意义的。CloudFront可以随时从缓存中清除“不受欢迎”的对象

<> P> >，希望TTL是“强>不<强”>“CyrdFox缓存对象多长时间？”而不是“CyrdFrand考虑缓存对象多长时间？”

如果对象的计算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

只有在这些情况下，

最小TTL

才能发挥作用。（另外，

Expires

HTTP头可以触发它，但不要使用

Expires

——使用

缓存控制

）

缓存控制

（由源服务器返回）主要用于浏览器，但CloudFront在尝试为每个对象计算适当的TTL时也会观察它

最小TTL

在CloudFront将从原点的

缓存控制

头根据上述条件推断的值上建立一个下限，较小的值向上舍入。如果您的源站返回（例如：

缓存控制：private、no Cache、no store

），则TTL应为0。。。但是CloudFront将该对象的内部TTL设置为0或

最小TTL中的较大值

如果响应具有（例如）
缓存控制：max age=15
，则browers和CloudFront将为该对象计算15秒的TTL。如果（例如）
最小TTL
设置为300，则CloudFront将忽略原点指定的15秒，并将对象的内部TTL设置为300秒。浏览器仍将使用15秒，因为CloudFront不会修改
缓存控制
响应标题

tl；dr:
Minimum TTL
是CloudFront将分配给对象的最小内部TTL值，而不管原始响应中的值会导致它计算较低的值。将此设置从默认值0更改为高级选项。它没有设置CloudFront缓存对象所需的最短时间