为何CloudWatch触发Lambda时boto3 head_object拿不到已存在的S3元数据？

问题原因排查方向 #

1. IAM权限条件限制

你在控制台手动测试Lambda时使用的是模拟执行上下文，而CloudWatch事件触发时是Lambda实际运行的生产上下文。如果Lambda执行角色关联的S3访问策略附加了源IP、请求来源等条件限制，Lambda运行时的动态出口IP不在允许列表内，就会导致head_object请求被403拒绝。你代码中捕获了所有异常直接设置exists=False，从表现上看就像是无法读取到元数据。
建议先在异常捕获块中打印完整错误信息，确认是否为权限类错误：

except Exception as e:
    print(f"错误类型：{type(e).__name__}, 错误详情：{str(e)}")
    exists = False

2. 触发事件传入的桶/对象键参数错误

手动测试时你大概率是直接传入了正确的桶名和对象键，而CloudWatch事件触发时，你是从事件Payload中解析参数，很容易出现以下问题：

• 如果触发事件来源是S3事件通知，对象键默认是URL编码格式，比如空格会转义为%20、中文会转义为百分号编码的字符串，未做解码处理的话查询的就是不存在的对象，自然拿不到元数据
• 事件Payload解析错误导致桶名/对象键带了多余的前缀、后缀，实际查询了错误的资源
  建议在函数入口处打印传入的bucket和key参数，和实际存在的S3对象信息做对比。

3. 对象版本/访问路径不匹配

如果你的S3桶开启了版本控制，手动测试时默认访问的是最新版本对象，要是CloudWatch事件中携带了旧版本的versionId参数，用该版本ID查询的旧版本对象本身就没有对应的first元数据，就会出现问题。
另外如果桶配置了S3访问点、前缀路由规则，也可能导致手动测试和自动触发时访问的实际资源路径不一致。

4. 区域配置不匹配

手动测试时boto3客户端默认继承你控制台所在的区域配置，如果Lambda执行环境没有显式指定S3服务区域，使用了默认区域或者全局端点，跨区域访问S3时也可能出现元数据读取异常，建议初始化S3客户端时显式指定桶所在区域：

s3_client = boto3.client('s3', region_name='替换为你的桶实际所在区域，例如cn-north-1')

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