在AWS Lambda+API Gateway场景下，动态内容更新时如何失效CloudFront缓存？

针对你用CloudFront作为API Gateway反向代理，想要缓存高频访问但低频更新的API内容，同时在内容更新时失效对应缓存的需求，这里有几种AWS生态下实用的方案，你可以根据更新频率和业务场景选择：

1. 直接创建CloudFront缓存无效化请求 #

这是最直观的主动失效方式，当API内容更新完成后，主动通知CloudFront删除指定路径的缓存条目，让后续请求直接从API Gateway拉取新内容。

• 操作方式：
  • 控制台操作：进入CloudFront控制台，找到你的分发实例，切换到「无效化」标签页，点击「创建无效化」，输入要失效的路径（支持通配符，比如/api/your-static-endpoint/*），提交即可。
  • CLI命令执行：

    aws cloudfront create-invalidation --distribution-id YOUR_DISTRIBUTION_ID --paths "/api/your-static-endpoint/*"
    

  • SDK调用：使用AWS各语言SDK的CreateInvalidation接口，参数与CLI一致。
• 注意事项：无效化是异步执行的，通常需要1-5分钟生效；AWS每月提供1000次免费无效化请求，超出后按次数计费，非常适合每周/每月更新的低频场景。

2. 使用版本化路径或查询参数 #

通过给API路径添加版本标识，让CloudFront自动将新内容识别为不同的缓存键，无需主动失效旧缓存，旧缓存会随TTL自然过期。

• 具体做法：
  • 路径版本化：比如原API路径是/api/system-config，更新后改为/api/v2/system-config，同时同步更新前端调用的路径，CloudFront会缓存新路径的内容，旧路径缓存到期后自动清除。
  • 查询参数版本化：在请求URL后追加版本参数，比如/api/system-config?version=202405，每次更新内容时修改版本号，CloudFront会将不同参数的请求视为独立缓存条目。
• 适用场景：适合更新周期固定、可以提前规划版本号的API，无需手动操作无效化，运维成本更低。

3. 利用Cache-Control头和验证机制（被动失效） #

在API Gateway返回的响应中设置合理的Cache-Control头，配合ETag或Last-Modified字段，让CloudFront自动验证内容是否更新，从而被动更新缓存。

• 操作步骤：
  • 在Lambda或API Gateway集成响应中，设置Cache-Control: max-age=604800（比如7天，匹配你的每周更新频率），告知CloudFront缓存内容的有效期。
  • 同时返回ETag（内容的哈希值）或Last-Modified（内容最后更新时间）字段。当内容更新时，API返回新的ETag或更新后的Last-Modified值。
  • CloudFront在缓存过期前收到请求时，会携带If-None-Match（对应ETag）或If-Modified-Since（对应Last-Modified）头去API Gateway验证，若内容已更新，就拉取新内容并更新缓存。
• 优势：无需主动操作失效，减少运维成本，适合不需要立即生效更新的场景。

4. 用Lambda@Edge实现灵活的缓存逻辑 #

如果你的更新触发条件比较复杂（比如需要根据数据库标记、外部事件判断是否更新），可以用Lambda@Edge在CloudFront边缘节点触发自定义逻辑，动态控制缓存失效。

• 示例场景：
  • 在Origin Request触发器中，检查存储在S3的更新标记文件（比如s3://your-bucket/update-flags/system-config），如果标记存在，就设置Cache-Control: no-cache强制从源拉取新内容，同时删除标记文件；如果标记不存在，就正常使用缓存。
  • 当你更新API内容后，只需上传这个标记文件，后续请求就会自动触发缓存更新。
• 优势：支持完全自定义的缓存逻辑，适合复杂业务场景，但需要编写Lambda代码，有一定开发成本。

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