通过Lambda+Boto3从EC2上传日志到S3异常：返回200但S3无文件

下面是几个关键排查方向，按优先级推进：

1. 先确认Lambda权限是否足够 #

• 必须给Lambda执行角色配置 s3:PutObject权限，且要明确指定目标S3桶的ARN，别用宽泛的通配符，示例策略如下：

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": "s3:PutObject",
              "Resource": "arn:aws:s3:::你的目标桶名/*"
          }
      ]
  }
  

• 同时检查是否存在组织级SCP限制，或者S3桶的自定义策略是否拒绝了Lambda角色的上传请求。

2. 明确Lambda无法直接访问EC2本地文件系统 #

• Lambda运行在AWS托管的隔离容器中，根本读不到EC2本地的日志文件（比如/var/log/xxx.log这类路径），如果你的代码是直接读取EC2本地文件，这是核心问题。
  • 可行替代方案：让EC2先把日志同步到CloudWatch Logs/S3，再由Lambda处理；或者用SSM Run Command触发EC2自行执行上传逻辑，Lambda仅负责触发该命令。
• 如果是通过API等其他方式获取日志，检查代码中是否存在文件路径错误、读取内容为空的情况，且别把异常全部静默捕获，否则会出现返回200但实际未执行上传的情况。

3. 检查代码的错误处理是否“掩盖了问题” #

• 很多开发者会写这样的代码：捕获所有异常后直接返回200，导致上传失败也无报错提示，比如：

  try:
      s3_client.put_object(Bucket='错误的桶名', Key='log.txt', Body=content)
  except Exception:
      return {'statusCode': 200}
  

• 建议在代码中添加详细日志，用logging模块记录文件读取结果、上传请求参数、异常堆栈信息，然后去CloudWatch Logs查看Lambda的执行日志，直接定位具体失败原因。

4. 核对Lambda与EC2的运行环境差异 #

• 比如EC2使用Python 3.11，而Lambda运行时是Python 3.9，部分SDK方法可能存在兼容性问题；或者代码依赖第三方库，EC2上已安装但Lambda未打包成层，导致运行失败。

5. 排查S3桶的配置细节 #

• 确认桶是否开启了版本控制，是否上传的文件在历史版本中未被注意；或者查看S3桶的访问日志，检查是否有Lambda的上传请求被拒绝（4xx状态码），这能直接定位权限或配置问题。

内容的提问来源于stack exchange，提问作者neeson.lee