CloudFront 通过 CloudFront TTL 设置在源处使对象过期与调用无效时有何实际区别？
一般思路是，您可以使用 TTL 来设置策略，CloudFront 使用该策略来确定可以从 CloudFront 缓存中提供每个对象且无需与源进一步交互的最长时间。
默认 TTL：当源未提供相关Cache-Control指令时，对象可以保留在 CloudFront 缓存中而不会被视为过时的最长时间。 CloudFront 不会向响应添加任何Cache-Control标头。
最小 TTL：如果源提供的缓存控制：s-maxage 值(或者，如果不存在，则为缓存控制：最大期限值)小于此值，CloudFront 将忽略它，并假定它可以在缓存中保留对象不超过此值。 例如，如果最小 TTL 设置为 900，但响应包含Cache-Control: max-age=300，CloudFront 将忽略 300，并可能将对象缓存长达 900 秒。Cache-Control标头不会修改，而是在收到时返回给查看器。
最大 TTL：如果源提供Cache-Control指令，指示对象的缓存时间可能超过此时间，CloudFront 将忽略该指令，并假定从缓存中继续提供对象的时间不得超过最大 TTL。
请参阅 Amazon CloudFront 开发人员指南 中的指定对象在 CloudFront 边缘缓存中保留的时间(过期)。
因此，这三个值控制 CloudFront 用于确定缓存响应是否仍然"足够新鲜"以返回到后续查看器。 这并不意味着 CloudFront 会在 TTL 过期后清除缓存的对象。 相反，CloudFront可能会保留该对象，但在到期后不会提供该对象，除非先向源发送请求以查看对象是否已更改。
CloudFront 不会主动检查已过期对象的新版本的来源 - 它仅检查是否在缓存中再次请求这些对象，然后确定已过期。 当它这样做时，它通常会使用If-Modfied-Since这样的指令发送条件请求。 这为源提供了响应304 Not Modified的选项，这会告知 CloudFront 缓存的对象仍然可用。
有时会出现的一个误解是，TTL 指示 CloudFront 缓存对象多长时间。 这不是它所做的。 它告诉 CloudFront 允许缓存响应多长时间，而无需对源进行重新验证。 CloudFront 中的缓存存储没有相关费用，并且根据定义，缓存是临时的，因此，很少请求的对象可能会在其 TTL 到期之前从缓存中清除。
如果边缘站点中的对象不经常被请求，CloudFront 可能会逐出该对象(在其到期日期之前删除该对象)，以便为最近请求的对象腾出空间。
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
在下一个请求中，CloudFront 将再次从源请求对象。
另一个误解是CloudFront的缓存是整体式的。 其实不然。 每个全局边都有自己独立的缓存，将对象缓存在请求它们的边中。 每个全局边缘还有一个上游区域缓存(在最近的 EC2 区域中;每个区域可能有多个，但未记录在案)，对象也将存储在其中，从而允许附近的其他全局边缘在最近的区域缓存中查找对象，但 CloudFront 不会在内部进一步搜索缓存对象。 为了性能，它只是在缓存未命中时转到原点。
了解 CloudFront 如何与区域边缘缓存配合使用。
失效完全不同，旨在谨慎使用 - 只有 AWS 账户每月提交的前 1000 条失效路径是免费的。 (路径可以匹配多个文件，路径/*匹配分发中的所有文件)。
失效请求具有创建失效时的时间戳，并向所有区域发送一条消息，指示它们按照以下行执行某些操作(没有记录确切的算法，但这准确地描述了净效应)：
- 从缓存中删除与
${path}匹配的任何文件(如果这些文件是在${timestamp}之前缓存的，并且 - 同时，由于这可能需要一些时间，如果您收到任何与
${timestamp}之前缓存的文件匹配${path}的请求，请不要使用缓存的文件，因为它们不再可用。
一旦整个网络收到消息，失效请求就被视为完成。 失效本质上是一种幂等操作，从某种意义上说，使实际上不存在的文件无效并不是错误，因为失效告诉边缘使此类文件无效(如果它们存在)。
由此可见，正确的行动方针不是选择一个或另一个，而是适当地使用两者。 设置您的 TTL(或选择"使用源缓存标头"并将源服务器配置为始终以适当的值返回它们)，然后仅在必要时使用失效来清除缓存中的选定内容或所有内容，如果您犯了错误或对站点进行了重大更改，则可能需要这样做。
但是，最佳做法是不指望失效，而是在对象更改时使用缓存破坏技术。 缓存无效化意味着更改所请求的实际对象。 例如，在最简单的实现中，这可能意味着您将 HTML 中的/pics/cat1.png 更改为/pics/cat2.png而不是在需要新图像时将新图像保存为/pics/cat1.png。 将一个文件替换为同一 URL 上的另一个文件的问题在于浏览器也有缓存，并且可能会继续显示旧图像。
另请参阅使对象失效。
另请注意，主 TTL 不用于错误响应。 默认情况下，404 Not Found等响应会缓存 5 分钟。 这是最小错误缓存 TTL，旨在减轻源服务器接收可能继续失败的请求，但只会失败几分钟。
如果我们正在查看实际差异：
- CloudFront TTL：您可以控制在 CloudFront 将另一个请求转发到您的源之前，对象在 CloudFront 缓存中保留的时间。
- 无效：使边缘缓存中的对象失效。下次查看器请求对象时，CloudFront 将返回到源以提取对象的最新版本。
所以主要区别在于速度。如果部署应用程序的新版本，则可能需要立即失效。