我遇到了问题并试图在论坛中回答这些问题，但没有任何成功。
为了生成缩略图，我设置了以下架构： S3帐户原始图像 使用NGINX和Thumbor的Ubuntu服务器 的Cloudfront
用户将原始图像上传到S3，将在请求前通过带有Cloudfront的Ubuntu Server上传：
http://cloudfront.account/thumbor-server/http://s3.aws ...
最重要的是，我们经常在Cloudfront中丢失对象，我希望它们在缓存中保留360天。 我通过Cloudfront URL获得以下回复：
Cache-Control:max-age=31536000
Connection:keep-alive
Content-Length:4362
Content-Type:image/jpeg
Date:Sun, 26 Oct 2014 09:18:31 GMT
ETag:"cc095261a9340535996fad26a9a882e9fdfc6b47"
Expires:Mon, 26 Oct 2015 09:18:31 GMT
Server:nginx/1.4.6 (Ubuntu)
Via:1.1 5e0a3a528dab62c5edfcdd8b8e4af060.cloudfront.net (CloudFront)
X-Amz-Cf-Id:B43x2w80SzQqvH-pDmLAmCZl2CY1AjBtHLjN4kG0_XmEIPk4AdiIOw==
X-Cache:Miss from cloudfront
重新刷新后，我得到：
Age:50
Cache-Control:max-age=31536000
Connection:keep-alive
Date:Sun, 26 Oct 2014 09:19:21 GMT
ETag:"cc095261a9340535996fad26a9a882e9fdfc6b47"
Expires:Mon, 26 Oct 2015 09:18:31 GMT
Server:nginx/1.4.6 (Ubuntu)
Via:1.1 5e0a3a528dab62c5edfcdd8b8e4af060.cloudfront.net (CloudFront)
X-Amz-Cf-Id:slWyJ95Cw2F5LQr7hQFhgonG6oEsu4jdIo1KBkTjM5fitj-4kCtL3w==
X-Cache:Hit from cloudfront
我的Nginx回复如下：
Cache-Control:max-age=31536000
Content-Length:4362
Content-Type:image/jpeg
Date:Sun, 26 Oct 2014 09:18:11 GMT
Etag:"cc095261a9340535996fad26a9a882e9fdfc6b47"
Expires:Mon, 26 Oct 2015 09:18:11 GMT
Server:nginx/1.4.6 (Ubuntu)
为什么Cloudfront不按指示存储我的对象？ Max-Age设定？ 非常感谢提前。
答案 0 :(得分：8)
您的第二个请求显示该对象确实已缓存。我假设你看到了，但问题并没有说清楚。
Cache-Control: max-age仅指定任何特定边缘位置的Cloudfront Cache中对象的最长年龄。保证对象保持不存在的最小时间间隔......毕竟，Cloudfront是缓存，根据定义，它是易变的。
如果不经常请求边缘位置中的对象，CloudFront可能会逐出对象 - 在对象到期日之前删除该对象 - 为更受欢迎的对象腾出空间。
- http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
此外，没有Cloudfront作为整体具有对象副本的概念。每个边缘位置的缓存看起来都独立于其他位置运行，因此看到来自不同Cloudfront边缘位置的相对流行对象的多个请求并不罕见。
如果您正在尝试调解后端服务器上的负载，可能需要在其前面放置一些您控制的缓存，如清漆，鱿鱼，另一个nginx或自定义解决方案，我是如何在我的系统中完成这项工作的。
或者，您可以在处理后将每个结果存储在S3中，然后配置现有服务器以检查S3，首先，在尝试再次调整对象大小之前。
那么为什么会有一个记录在案的“最小”TTL？
在上面引用的同一页上，你也会发现：
对于Web分发，如果向对象添加Cache-Control或Expires标头，还可以指定CloudFront在将另一个请求转发到源之前将对象保留在缓存中的最短时间。
我可以看到为什么这个，以及评论中引用的提示词，下面......
在CloudFront将另一个请求转发到您的来源以确定更新版本是否可用之前，对象在CloudFront缓存中的最短时间（以秒为单位）。
......似乎与我的答案相矛盾。然而，没有矛盾。
简单来说，最小ttl为Cache-Control: max-age的内部解释建立了一个较低的边界，覆盖 - 在Cloudfront内 - 由原始服务器发送的任何较小的值。服务器说缓存它1天，最多，但配置的最小ttl是2天？ Cloudfront会忘记它在max-age标题中看到的内容，并且可能无法在接下来的2天内再次检查原点，而不是在1天后再次检查。
缓存的性质决定了对所有明显模糊性的正确解释：
您的配置会限制Cloudfront可以提供对象的缓存副本的时间长度，以及它不应该继续从缓存中返回对象的时间点。他们没有强制Cloudfront必须维护缓存副本多长时间，因为Cloudfront MAY可以随时驱逐一个对象。
如果您正确设置了Cache-Control:标头，Cloudfront会将较大的max-age或您的最小TTL视为您希望它们在不咨询原始服务器的情况下提供缓存副本的最长时间再次。
随着您的网站流量增加，这应该不会成为一个问题，因为您的对象会更“受欢迎”，但从根本上说，没有办法要求Cloudfront维护对象的副本。