我读到 Cloudfront 在不活动几天后将文件从其缓存中逐出。
你有官方消息来源吗？
这是官方的回答：
如果边缘站点中的对象不经常被请求，CloudFront 可能会驱逐该对象（在其到期日期之前移除该对象），以便为最近请求的对象腾出空间。
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
缓存对象没有保证的保留时间，需求低的对象更有可能被驱逐……但这不是您可能没有考虑的唯一因素。驱逐可能不是问题，也可能不是唯一的问题。
CloudFront 缓存的对象就像薛定谔的猫。这是一个松散的类比，但我正在使用它：一个对象是否在任何给定时刻“在云端缓存中”并不是一个是或否的问题。
CloudFront 在 37 个城市大约有 53 个edge locations（您的浏览器连接和物理存储内容的地方）。一些主要城市有 2 或 3 个。到达云端的每个请求都会（通过 DNS）路由到理论上最理想的位置——为简单起见，我们将其称为“最接近”您所在位置的边缘。
Cloudfront 的内部运作不是公开信息，但基于观察和presumably authoritative sources 的普遍共识是这些边缘位置都是独立的。它们不共享缓存。
例如，如果您在德克萨斯（美国）并且您的请求通过并被缓存在德克萨斯州达拉斯/沃思堡，并且如果您的任何请求都可能到达达拉斯边缘的任何一个的可能性相同位置，然后直到您 两次 未命中同一对象，您的下一个请求将是未命中的几率约为 50/50。如果我从我所在的位置请求相同的对象（我根据经验知道该对象往往会通过印第安纳州的南本德），那么我的第一个请求失败的几率是 100%，即使它缓存在达拉斯。
所以一个对象要么不在缓存中，要么不在缓存中，因为没有“the”（单个、全局）缓存。
CloudFront 对您的浏览器“最近”边缘的确定也可能会随着时间而改变。
CloudFront 确定最近边缘的机制似乎是动态和自适应的。整个 Internet 拓扑的变化可能会改变哪个边缘位置倾向于接收从给定 IP 地址发送的请求，因此在几个小时的过程中，您连接的边缘可能会发生变化。影响特定边缘的维护或中断或其他问题也可能导致来自给定源 IP 地址的请求被发送到与典型边缘不同的边缘，这也可能给您留下对象被驱逐的印象，因为新边缘的缓存会与旧的不同。
查看响应标头，无法确定哪个边缘位置处理每个请求。但是，此信息在CloudFront access logs 中提供。
我有一个获取和调整大小的图像服务，每天处理大约 750,000 张图像。它落后于 CloudFront，我的命中/未命中率约为 50/50。这当然不是 CloudFront 的错，因为我的图像池超过 800 万张，观众遍布世界各地，而且我的 max-age 指令比你的短。自从我上次分析日志以确定哪些“未命中”以及如何出现意外（尽管当我这样做时，肯定有一些，但它们的数量并非不合理）以来，已经有一段时间了，但这很容易做到，因为日志会告诉您每个响应是命中还是未命中，以及识别边缘位置...因此您可以对其进行分析以查看此处是否真的存在模式。
我的服务将其所有输出内容存储在 S3 中，当有新请求进来时，它首先向 S3 存储桶发送快速请求，以查看是否有可以避免的工作。如果 S3 返回结果，则该结果将返回到 CloudFront，而不是再次执行所有获取和调整大小的工作。请注意，由于 CloudFront 未命中的数量，我没有实现该功能......我从一开始就设计了它，甚至在我在 CloudFront 后面测试它之前，因为 - 毕竟 - CloudFront 是一个 缓存，根据定义，缓存的内容几乎是易变和短暂的。
更新：我在上面说过，通过检查来自 CloudFront 的请求标头来识别转发特定请求的边缘站点似乎是不可能的......但是，似乎有一些可能通过检查传入请求的源 IP 地址来确定准确度。
例如，如果我从家里访问我的站点，则通过 CloudFront 发送到我的一个源服务器的测试请求从 54.240.144.13 到达，或者当我从办公室访问站点时从 205.251.252.153 到达——这些位置只是一个相距几英里，但在州边界的相对两侧并使用两个不同的 ISP。这些地址的反向 DNS 查找会显示这些主机名：
server-54-240-144-13.iad12.r.cloudfront.net.
server-205-251-252-153.ind6.r.cloudfront.net.
CloudFront 边缘站点以最近的主要机场命名，外加一个任意选择的编号。对于iad12 ...“IAD”是华盛顿特区杜勒斯机场的国际航空运输协会 (IATA) 代码，因此这很可能是弗吉尼亚州阿什本的边缘位置之一（它有三个，大概有不同的最后的数字代码，但我无法仅从这些数据中确认）。对于ind6，“IND”与印第安纳州印第安纳波利斯的机场相匹配，因此这强烈表明此请求来自印第安纳州南本德边缘位置。此测试的可靠性取决于 CloudFront 维护其反向 DNS 条目的一致性。没有记录在任何给定的边缘位置可能有多少独立缓存；假设只有一个，但可能不止一个，这会增加非常少量请求的未命中率，但会消失在大量请求的混合中。