关于CloudFront部署过程及缓存失效时机的技术咨询

我在AWS上搭建了Web应用：后端托管在Elastic Beanstalk，前端存储于S3桶，两者均通过CloudFront作为CDN分发。目前我遵循一套固定的部署流程，但对CloudFront变更的时序逻辑和缓存失效的操作时机存在疑问。

我的部署流程：

• 复制Elastic Beanstalk后端环境
• 在复制的后端环境部署变更内容
• 将前端变更推送至S3桶的staging文件夹
• 修改CloudFront分发的源配置，使其指向更新后的S3内容与新后端环境
• 等待CloudFront部署完成
• 执行CloudFront缓存失效操作

我的疑问集中在修改CloudFront源到执行缓存失效的这段时间：

1. CloudFront部署期间具体会发生什么？这是否会影响更新后前端内容的可访问性？
2. 是否必须等待CloudFront部署完成后再启动缓存失效流程？还是修改源后即可直接执行缓存失效？

回答 #

1. CloudFront部署期间的行为及对前端访问的影响 #

CloudFront部署配置变更时，本质是把新的分发配置同步到全球所有边缘节点，这个同步过程通常需要5-15分钟。在同步完成前，全球边缘节点会处于新旧配置混合生效的状态：部分节点已应用新配置，另一部分仍在使用旧配置。

对你的场景而言，只要前端变更已推送到S3的staging文件夹，且CloudFront源已指向该路径，部署期间不会导致前端内容不可访问：

• 已同步新配置的边缘节点，会直接从新的S3路径拉取更新后的前端内容；
• 未同步完成的节点，仍会拉取旧的前端内容。
  唯一的影响是，这段时间内不同地区的用户可能会看到新旧版本的内容，直到所有节点完成配置同步。

2. 缓存失效的触发时机 #

不需要等待CloudFront部署完成再执行缓存失效，甚至可以在修改完CloudFront源配置后立即启动缓存失效流程，两者并行操作也没问题。

原因在于，CloudFront的配置同步和缓存失效是两个独立的执行流程：

• 提前触发的缓存失效指令，会和新配置一起同步到边缘节点；
• 当边缘节点完成配置同步后，一旦收到用户请求，会因为缓存失效指令的存在，直接跳过旧缓存，去新的源路径拉取最新内容。

注意：缓存失效的路径要精准，比如全量更新时用/*清除所有缓存，仅部分文件变更时则指定具体文件路径，这样能提升失效操作的效率，也能减少不必要的资源消耗。

内容的提问来源于stack exchange，提问作者Alexandre_Bon