AWS账户出现来源不明的S3 Get/Put异常请求排查咨询

首先澄清你对CloudWatch排查的顾虑：CloudWatch默认生成的监控、日志数据全部存储在CloudWatch服务自身的存储集群中，不会自动写入S3；只有你手动配置CloudWatch Logs到S3的导出任务、或者主动开启S3服务日志写入目标桶时，才会产生S3侧的Put请求，排查阶段只要不开启这两个手动配置，完全不会产生干扰排查结果的额外请求。

零额外请求开销的前置排查 #

这几步不需要开通任何额外服务、不会产生任何新的S3请求，优先操作：

• 进入S3控制台，逐个打开你留存的2个非公有存储桶，切换到「监控」标签页，查看S3默认免费上报的请求维度指标，先确认异常Get/Put请求是否真的打到了这两个现存桶上，同时能看到请求的时间分布、错误率分布。
• 逐个检查存储桶的「属性」配置页，确认是否残留开启了生命周期规则、跨区域复制规则、S3 Inventory清单配置、智能分层自动转换配置，这类S3内置的托管功能运行时，会自动产生Get/Put类请求计数，不需要你手动触发操作。
• 打开IAM控制台，查看「访问顾问」和「CloudTrail 事件历史」（CloudTrail默认免费留存90天管理事件，不需要额外开通），筛选S3相关的操作记录，就能直接看到是哪个IAM用户、角色、AWS服务在发起S3调用，这里的日志全部存在AWS对应服务侧，不会写入S3。

低干扰精准定位方案 #

如果前置排查没找到来源，可以开启S3服务器访问日志做精准定位，注意配置规则避免干扰：

• 单独新建一个完全独立的私有存储桶专门存放访问日志，不要把日志投递目标设置为你当前存在异常请求的2个业务桶，同时给这个日志桶配置最严格的私有访问权限、禁止公网访问。
• 给待排查的2个桶开启服务器访问日志，投递目标选刚才新建的专用日志桶。这个配置产生的Put请求只会被统计到专用日志桶上，完全不会和待排查桶的异常请求计数混淆，不会干扰排查结果。
• 开启日志后等待1-2小时，下载日志文件即可查看每一条请求的源IP、调用身份、请求接口、User-Agent标识，直接定位来源：
  • 如果请求源是AWS内部服务IP，对应检查是否残留了之前测试时未删除的关联资源，比如静态网站托管配套的CloudFront分发、Route53别名记录、Lambda@Edge函数、ACM域名验证配置，这类资源删除桶后如果没同步清理，会周期性发起重试请求。
  • 如果是公网未知来源IP，大概率是之前测试时公网暴露过桶信息、或者IAM访问密钥泄露被扫描，直接给对应桶添加临时Deny规则拦截对应IP段，同时轮换所有长期访问密钥即可。
  • 如果请求量极低（每天几十次级别），一般是AWS Config、Security Hub、Trusted Advisor这类账户安全/配置扫描服务的自动盘点请求，属于正常现象，不会产生大额账单。

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