迁移AWS账号后Serverless Image Handler间歇性500错误修复

这不是S3资源迁移不完整的问题，核心是Serverless Image Handler（以下简称SIH）v6版本升级后，冷启动、缓存策略、权限配置三类问题叠加导致的，和你观察到的现象完全匹配：

• 两类curl请求返回结果不一致的原因：SIH v6默认搭配CloudFront做内容协商，带accept: image/*头的<img>标签请求会走图片实时处理Lambda链路；带text/html优先级更高的导航请求，会被CloudFront规则直接路由到S3源站返回原图，根本不触发图片处理逻辑，所以不会报错。
• 故障图片数随时间递减、等待后自动恢复的原因：SIH v6重构了Lambda运行时，冷启动耗时是v5.2的4-6倍（1.2s-2s），刚迁移完所有图片都没有处理缓存，首次请求触发冷启动+拉取源图+实时转码时，很容易触发超时/限流返回500；一旦某张图片被成功处理，结果会同时写入CloudFront边缘缓存和S3缓存桶，后续请求直接读缓存不再走Lambda，所以故障量会随着访问量积累自然下降。
• 新AWS账号的默认Lambda并发配额较低，短时间内大量未缓存图片请求打进来时，会触发Lambda节流，进一步放大500错误的概率。

• 第一时间查SIH关联Lambda函数的CloudWatch日志，筛选500错误对应时间段的日志，基本能看到两类典型错误：Task timed out after X seconds（冷启动/处理超时）、Rate exceeded（Lambda并发节流），可以直接确认问题。
• 随机选一张故障图片，连续发起3次和<img>标签请求头完全一致的curl请求，如果第一次返500、后两次返200，即可100%确认是首次处理链路的问题，和源文件完整性无关。
• 核对SIH Lambda的执行角色权限：v6版本相比v5.2新增了缓存回写逻辑，需要角色绑定新S3桶的s3:PutObject权限，如果漏配该权限，处理后的图片无法写入缓存，每次请求都要重新走Lambda处理，会大幅提升报错概率。

即时止血（10分钟内生效） #

• 将SIH关联Lambda的内存配置从默认1024MB提升到2048MB：Lambda内存配置和CPU、网络带宽线性挂钩，调整后冷启动耗时可降到500ms以内，单张常规图片处理耗时压到200ms内，直接降低超时概率。
• 给Lambda配置10-20个预配置并发实例，彻底消除冷启动带来的首次请求超时问题。
• 将API Gateway对接Lambda的集成超时从默认5s调整到10s，给大尺寸图片的首次处理留足冗余时间。
• 调整CloudFront缓存键策略，将Accept头加入缓存键白名单，避免不同Accept头的请求缓存串扰，解决导航请求和图片请求命中不同缓存的问题。

长期彻底解决 #

• 写简单脚本遍历S3源桶内的所有图片，按照网站实际使用的裁剪、尺寸参数主动发起请求预热，提前把处理结果写入缓存层，不要等用户访问触发首次处理——靠自然流量预热的速度极慢，低流量图片可能数周都不会被触发处理，会长期存在首次访问报错的问题。
• 如果Lambda部署在VPC内，确认配置了S3的VPC网关端点，避免Lambda走公网拉取源图增加耗时。
• 预热前先抽取不同格式、尺寸的测试图片，验证v6版本的处理效果（压缩率、裁剪逻辑、色彩空间）和旧v5.2版本一致，避免批量预热后图片效果不符合预期。

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