几周前亚马逊宣布他们已经降低了内容的有效期：
Amazon CloudFront Lowers Minimum Content Expiration Period
您现在实际上可以将 CloudFront 中的 TTL 设置为 0。所以我的问题是，为什么将 TTL 设置为 0 的 CloudFront 分配很有用。对我来说，这意味着根本没有缓存，所以每个请求到达 CloudFront 最终会到达源头。
我错过了什么？
【问题讨论】：
标签： amazon-web-services cdn amazon-cloudfront
Amazon CloudFront 的这个新特性实际上对许多用例都非常有用，因为 命中原点 的工作方式与乍一看有点不同，而且不一定是问题，相反;虽然此功能已较早发布，但它与最近发布的 Amazon CloudFront - Support for Dynamic Content 一起发布，例如对于手头的问题：
可变生存时间 (TTL) - 在许多情况下，动态内容要么是 不可缓存或在很短的时间内可缓存，也许 只需几秒钟。过去，CloudFront 的最小 TTL 是 60 分钟，因为所有内容都被认为是静态的。新的最小 TTL 值为 0 秒。 如果您将特定来源的 TTL 设置为 0， CloudFront 仍将缓存来自该源的内容。 然后会 使用 If-Modified-Since 标头发出 GET 请求，从而给出 源有机会表明 CloudFront 可以继续使用 缓存的内容，如果它在原点没有改变。 [强调我的]
换句话说，使用 0 的 TTL 主要意味着 CloudFront 将缓存控制权限委托给源，即源服务器决定 CloudFront 是否缓存对象以及是否缓存对象多长时间；请特别注意，带有 If-Modified-Since 标头的 GET 请求 并不一定意味着对象本身是从原点检索的，而是原点可以（并且应该）返回 @987654323 @ 适用时：
表示资源自上次请求后未被修改。 [...] 使用它可以节省服务器和服务器上的带宽和重新处理 客户端，因为只有头数据必须发送和接收 与正在重新处理的整个页面进行比较 服务器，然后使用服务器和客户端的更多带宽再次发送。 [强调我的]
请参阅 Mark Nottingham 的优秀 Caching Tutorial，详细了解 HTTP 缓存控制的机制和优势，这是 HTTP 架构中非常重要且有效的部分。
了解所有这些部分如何协同工作确实有点困难，因此Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration) 中的指定 CloudFront 为下载分发缓存对象的最短时间部分中的表格试图总结以下情况时的影响在 CloudFront 的上下文中应用，有或没有 TTL = 0。
【讨论】：
请注意，亚马逊不是说“TTL 为 0”，而是说“最小 TTL 为 0”。这是非常不同的。上面的描述非常可取，但不能保证 Cloudfront 确实做到了。
根据我现在的经验，我可以看到缓存的图像在边缘停留了几分钟，而我的原点已经改变了。
所以，我认为说“最小 TTL 为 0”可能更像是“亚马逊没有严格的意图将其保存在缓存中”，也许“它会经常重新获取”。
对于网络用户发布新内容的 CMS 等应用程序，我认为 TTL-0 仍然不够。您仍然必须从 CMS 调用失效，或者为不同的版本号使用不同的路径。
【讨论】：
CloudFront 可以与证书管理器结合使用，为 S3 网站添加 HTTPS 支持。您可能想要这个，但零缓存。
【讨论】：
另一个用例是，如果您想使用 lambda edge https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html 操作不可缓存内容请求的标头。示例x-api-key。
【讨论】：