使用CloudFront CDN搭配Lambda Imgproxy出现429请求过多错误

核心原因排查 #

CloudFront返回批量429但直接访问Lambda URL正常，核心是请求并发模式差异导致的：

• 浏览器直接访问时，并发请求数被限制在6-8个，Lambda的并发能力能轻松应对；
• CloudFront作为代理，会一次性转发大量请求到Lambda，瞬间打满Lambda的并发额度或触发函数URL的速率限制；
• 若CloudFront缓存未生效，所有请求穿透到Lambda，进一步放大并发压力。

具体解决步骤 #

1. 检查并调整Lambda并发配置 #

• 查看CloudWatch中Lambda的Throttles指标，确认是否是Lambda触发了节流；
• 提高预留并发：比如设置为50（根据实际请求量调整），避免突发批量请求打满默认的突发并发；
• 若函数处理大图片耗时久，优化imgproxy的处理逻辑（比如降低默认压缩比、调整图片格式），减少单请求执行时间，降低并发堆积。

2. 优化CloudFront缓存策略 #

• 为图片配置合理的Cache-Control响应头（比如max-age=86400），让CloudFront缓存静态资源，减少回源请求；
• 在CloudFront行为的缓存策略中，确保包含imgproxy的关键查询参数（如w、h、fit等），保证不同处理参数的图片能被正确缓存，避免重复回源；
• 查看CloudFront的CacheHitRate指标，验证缓存是否生效。

3. 调整CloudFront源站并发控制 #

• 在CloudFront源配置中，降低自定义源的并发连接数（比如设为50），让CloudFront分批次转发请求，避免瞬间冲击Lambda；
• 配置CloudFront的重试策略：对429错误启用指数退避重试，给Lambda足够的时间释放并发资源。

4. 检查Lambda函数URL的速率限制 #

• 进入Lambda函数的“函数URL”配置页，确认是否设置了过低的速率限制（比如每秒10次请求），如果有则调高或暂时关闭，验证是否解决问题。

5. 验证请求流日志 #

• 开启CloudFront访问日志，查看429错误的来源：
  • 若响应来自Lambda：重点优化Lambda并发或函数URL限制；
  • 若响应来自CloudFront：检查CloudFront的区域请求阈值（少见），或源站响应超时导致的重试累积。

快速验证方案 #

1. 临时将Lambda预留并发设为100，重新测试批量加载，若429消失，说明是Lambda并发不足；
2. 手动修改一张图片的CloudFront URL，添加缓存控制参数，验证是否能被缓存，若能则调整全局缓存策略。

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