AWS环境下未使用SQS却用量偏高，如何排查异常流量来源

SQS无队列但用量偏高的排查方向 #

• 查询CloudTrail的SQS相关事件记录，CloudTrail默认留存90天内的全量AWS服务API调用日志，重点筛选ListQueues、SendMessage、ReceiveMessage、DeleteQueue这类操作，确认是否有测试脚本、第三方工具、配置错误的其他服务还在持续调用SQS接口，哪怕目标队列已经被删除，API请求本身也会被计入SQS用量。
• 切换AWS控制台的所有常用区域，逐一检查是否有遗漏的未删除SQS队列，控制台默认仅展示当前区域的资源，跨区域创建的队列不会在当前区域的列表中显示。
• 检查是否有残留的关联服务配置，比如之前测试SQS时绑定的Lambda触发器、EventBridge规则、CloudWatch告警等，这类配置会持续尝试向已删除的队列推送事件，无效请求同样会产生调用用量。

S3流量来源排查方案 #

• 开启目标S3桶的服务器访问日志功能，开启后所有对该桶的请求都会被记录到指定的日志存储桶中，日志包含请求源IP、请求类型、调用身份、请求资源等完整信息，可直接统计SAM部署相关请求的占比。
• 进入Cost Explorer控制台，按S3服务筛选后，分别按「使用类型」「资源标签」「API操作」维度拆分用量数据，SAM部署通常会产生大量的PutObject、GetObject、ListBucket操作，可直接匹配对应操作的用量占比。
• 筛选CloudTrail的S3服务API调用事件，可直接查看每个请求的发起身份（比如SAM CLI对应的IAM用户/角色）、请求时间、操作的桶和对象，可直接确认高用量是否由SAM部署导致。
• 比对本地SAM CLI的部署日志，统计每次部署上传的资源包大小、部署频次，和S3的出入网流量、请求次数数据做交叉验证。

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