S3 PutObject事件触发Lambda调用次数异常问题排查

并发限流排查（最高优先级） #

当前配置的Lambda预留并发仅为30，远低于高并发上传场景的需求，优先核对以下指标：

• 查看CloudWatch中Lambda的Throttles（节流次数）、ConcurrentExecutions（并发执行数）指标：如果调用量陡降的时间段内，ConcurrentExecutions长期顶在30的阈值线，同时Throttles指标持续上涨，说明事件因并发配额不足被Lambda节流。S3事件通知默认重试规则为失败后带指数退避重试2次，重试时仍无可用并发则事件直接丢弃；未单独配置失败投递目标的话，丢弃事件无留存无法回溯。
• 若未配置预留并发，需核对账号级Lambda总并发配额（默认1000），确认同账号下其他函数是否占用了大量并发，导致当前函数被节流。

S3事件通知规则排查 #

• 检查筛选规则：确认配置的前缀、后缀匹配规则覆盖所有实际上传路径，不存在规则遗漏导致部分Put请求未被捕获。
• 检查事件类型匹配：S3对象创建类事件包含PutObject、POST Object、CopyObject、CompleteMultipartUpload（分片上传完成）四类，若仅勾选了PutObject事件，走分片上传、POST上传、拷贝上传的对象都不会触发Lambda，这类遗漏很容易造成近半调用缺失。
• 检查重叠规则：如果同存储桶下存在前缀、后缀范围重叠的多条事件通知规则，S3会将匹配事件投递到其中一个目标，不会重复投递；若其他重叠规则绑定了SQS、SNS或其他Lambda函数，会分流走部分事件。
• 检查触发权限：确认S3服务端有权限调用目标Lambda，权限配置错误会导致事件投递失败，S3会缓存权限错误结果，后续对应路径的事件会直接跳过投递。

事件投递链路排查 #

• 确认触发链路是否为S3直连Lambda：如果中间经过SQS、SNS、EventBridge转发，需额外排查中间节点配置：
  • 若经过SQS触发Lambda：Lambda的SQS事件源映射默认批量拉取消息，单批次最多拉取10条消息，1次Lambda调用可处理多条S3事件，此时Lambda调用数必然小于实际Put请求数；需同时核对SQS消息保留周期、死信队列配置，确认是否存在消息过期丢弃。
  • 若经过SNS/EventBridge：检查订阅状态是否正常、是否配置了消息过滤策略丢弃部分事件、目标重试策略是否配置正确。
• 若配置了S3事件通知死信队列，直接查看死信队列中的失败事件，可直接获取事件投递失败的具体原因，缺失的调用量基本与死信队列堆积的事件量匹配。

实际有效请求量核对 #

• 拉取CloudTrail中PutObject相关事件日志，筛选HTTP返回码为200的成功请求数，排除客户端侧重试的失败请求：客户端统计的请求量往往包含网络超时、权限错误等场景下的自动重试，这类失败请求不会触发S3事件。
• 核对是否存在高频覆盖写同一个对象Key的场景：短时间内对同一个对象Key多次发起Put请求时，S3可能合并重复Key的事件，但该场景仅在单Key写入QPS极高时才会出现。

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