为何Lambda@Edge结合CloudFront生成的S3预签名URL在过期前始终相同，而普通Lambda每次生成不同？

这是Lambda@Edge结合CloudFront使用时非常典型的缓存行为问题，我来帮你理清背后的逻辑和解决办法：

核心原因：CloudFront的缓存机制 #

当你把代码部署到Lambda@Edge（绑定在CloudFront的请求阶段）时，CloudFront会默认缓存Lambda返回的响应（也就是你的302跳转和预签名URL）。只要后续的请求和第一次的请求具有相同的缓存键（通常包含请求路径、查询参数、部分请求头），CloudFront就会直接返回缓存的响应，而不会再次触发Lambda@Edge执行。

而普通Lambda函数每次调用都是独立的，没有上层的缓存层干预，所以每次都会重新执行代码生成新的预签名URL——毕竟S3预签名URL的签名会包含当前的时间戳（基于ExpiresIn计算出的过期时间），参数相同的情况下，不同时间生成的URL必然不同。

如何让预签名URL每次调用都变化？ #

如果你确实需要每次请求都生成新的预签名URL，可以通过以下方式解决：

• 修改CloudFront缓存策略，强制不缓存该路径的响应
  进入CloudFront控制台，找到对应的分发和行为，将缓存策略设置为**“不缓存”**（或者自定义缓存策略，设置缓存TTL为0）。这样每次请求都会触发Lambda@Edge执行，自然会生成新的URL。

• 让缓存键包含唯一标识，避免缓存命中
  比如要求客户端请求时携带一个随机的查询参数（如?nonce=随机字符串），然后在CloudFront的缓存键设置中包含这个查询参数。这样每次请求的缓存键都不同，CloudFront就会每次都调用Lambda@Edge生成新的URL。

• 验证小技巧
  你可以先手动测试：在访问CloudFront域名时，每次添加一个不同的随机查询参数（比如https://your-cloudfront-domain.com/path?rand=123、https://your-cloudfront-domain.com/path?rand=456），这时候应该能看到每次返回的预签名URL都是不同的——这就验证了缓存是问题的根源。

补充说明 #

其实从功能角度来说，只要预签名URL在过期时间内有效，重复使用同一个URL是完全没问题的，S3会正常处理请求。如果你没有特殊的业务要求（比如需要追踪每个请求的URL），保持CloudFront的缓存反而能减少Lambda@Edge的调用次数，降低成本并提升响应速度。

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