在 CloudFront 中更改“源路径”需要很长时间才能生效答案

【问题标题】：Changing "Origin Path" in CloudFront takes very long to kick in在 CloudFront 中更改“源路径”需要很长时间才能生效
【发布时间】：2017-08-27 20:59:39
【问题描述】：

我们有一个托管在 S3 中并通过 CloudFront 交付的静态站点。该网站可以运行，但推出更新需要相当长的时间——数小时或更长时间。具体来说，更改原点路径并没有像期望的那样快速反映在边缘位置上。

这是我们正在努力实现的目标......

我们的 S3 存储桶配置为托管网站。它存储同一站点的多个版本。每个 git 标签都有一个子目录。例如：

/git-v1
/git-v2
/git-v3
..

目标是告诉 CF 根据 Origin Path 设置开始提供网站的新版本。我们不想使旧对象失效，只需通过创建一个新目录并将 CF 指向它来继续推进版本。 CloudFront Distributions 下的状态长时间显示“已部署”，但边缘站点继续忽略新的源路径。

任何关于如何让 CF 更快地开始服务新子目录的想法将不胜感激。

【问题讨论】：

更改源路径设置后，是否要清除 CloudFront 缓存？
这是我感到困惑的部分。我没有更新现有对象。根据 CF 手册，“使对象无效会从 CloudFront 边缘缓存中删除它们。一种更快、更便宜的方法是使用版本化的对象或目录名称。”那么，不应该只更改源路径吗？
他们所说的版本控制类型涉及更改所请求的实际 URL，例如您的网页请求 style-v1.css，然后您将其更改为 style-v2.css。但是在您的场景中，请求 URL 永远不会改变，所以我认为 CloudFront 将继续提供对象的旧版本，直到缓存过期。
是的，只要有可能，我们就通过 URL 路径进行版本控制，这种方法效果很好，但这种情况是站点根目录的主/索引页面。我想清除缓存是唯一的途径......

【解决方案1】：

Origin Path 设置应用于请求之后缓存被检查...而不是之前。当 URI 中请求的对象不在缓存中时，从 Origin 服务器请求该对象。此时，Origin Path 会添加到传入请求路径之前，然后发送到 origin。缓存基于传入请求路径。¹

设置本身会很快生效，通常在几秒钟内，但不会清除缓存。

如果这只是为了对根页面进行版本控制，您可以将原始路径留空，将默认根对象更改为新的根对象，然后使/ 无效。或者，您可以继续做您正在做的事情，并在进行更改后使/* 无效。免费失效限制为每月 1000 次，但使 /*（或任何通配符）失效仅计为 1 次失效，无论通配符匹配多少对象。

¹ 传入请求路径还指的是在 Lambda@Edge 查看器请求触发器修改后的路径（如果适用）。

【讨论】：