日均300万次GET请求(Amazon S3 USE2-Requests-Tier2)异常原因排查求助

• Athena/Glue相关操作异常：你提到的每2小时触发的Athena查询是高概率诱因。如果查询的表对应S3路径下存在大量细碎小文件（比如单文件小于128MB的CSV/Parquet分片）、SQL未添加分区裁剪逻辑，单次查询可能扫描数万甚至数十万级S3对象，每扫描一个对象就对应一次GET请求。若EventBridge规则配置错误导致Lambda实际运行频率远高于2小时一次，或是Glue爬虫任务配置了高频自动运行扫描元数据，很容易达到日均百万级请求量。
• Lambda代码逻辑Bug：若业务Lambda中存在错误的递归遍历S3前缀、异常重试无退避限制的逻辑，就算日活用户少，单次异常触发就可能短时间产生数万次请求。另外如果Lambda配置了无上限失败重试策略，单次下载失败可能重复发起几十次GET请求。
• AWS后台自动服务操作：若你配置了S3 Inventory、跨区域/同区域复制、S3访问日志同步、第三方监控工具拉取S3对象数据、S3 Access Grants周期性校验，这类后台操作产生的GET请求不会计入业务侧主动调用的统计中，很容易被忽略。
• 闲置资源未清理：未下线的测试环境脚本、CI/CD自动化流程、历史同步/爬虫任务持续拉取S3资源，也会持续产生请求。
• S3批量操作配置错误：如果曾配置过S3 Batch Operations的批量读取类任务，任务未正常结束或是配置了循环执行，也会持续产生大量GET请求。

• 开启S3服务器访问日志：给所有疑似产生请求的S3存储桶开启服务器访问日志，日志会记录每一次请求的请求时间、请求方ARN、源IP、操作类型、请求对象路径、返回状态码。日志落地到指定日志桶后，可以直接用Athena建表查询，统计请求量最高的请求方ARN，即可直接定位请求发起方。
  开启日志的AWS CLI命令示例：

  aws s3api put-bucket-logging \
    --bucket <业务桶名称> \
    --bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"<日志桶名称>","TargetPrefix":"s3-access-logs/"}}'
  

• 通过Cost Explorer缩小排查范围：在Cost Explorer中筛选美东2区、S3服务、USE2-Requests-Tier2费用项，按资源ID、标签维度分组，即可直接看到是哪一个存储桶产生的超量请求。
• 对比监控时间线验证诱因：给存储桶开启1分钟粒度的S3请求次数云监控指标，对比EventBridge触发Lambda的时间点，查看请求量峰值是否和Lambda运行时间完全对齐，即可直接验证Athena查询是否是请求来源。
• 查询CloudTrail事件统计调用方：在CloudTrail控制台搜索s3:GetObject事件，筛选近7天的事件记录，按请求身份ARN统计调用次数，即可直接找到调用量最高的身份。

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