如何审计AWS SQS队列的消息消费方？CloudTrail无日志怎么办？

核心原因说明 #

CloudTrail默认不会记录ReceiveMessage、DeleteMessage这类消息消费相关的API操作，这是因为这类操作属于高频调用，默认不记录是为了避免日志量过大和成本上升。

实现审计的具体方案 #

1. 开启SQS的CloudTrail数据事件记录 #

手动配置CloudTrail，针对目标SQS队列启用数据事件记录：

• 进入CloudTrail控制台，找到对应的跟踪（Trail）
• 在数据事件配置中，添加SQS服务，指定目标队列的ARN
• 勾选记录ReceiveMessage、DeleteMessage等需要审计的操作
• 保存配置后，后续的消费操作会被记录到CloudTrail日志中

2. 注入自定义消息属性补充身份信息 #

如果需要更细粒度的追踪，可让消息生产者或消费者在处理消息时添加自定义属性：

• 注入调用者的IAM角色/用户ID
• 记录消费端的实例ID、ECS任务ID等标识
  这种方式可配合CloudTrail日志，实现更完整的链路追踪

3. 通过Lambda代理消费并记录身份 #

若队列消费逻辑允许，可利用Lambda作为中间消费层：

• 配置Lambda作为SQS队列的触发器
• 在Lambda代码中，通过context.identity获取调用者身份（如通过API Gateway触发的场景），或记录Lambda执行时的IAM角色信息
• 将身份信息与消息处理日志一同写入CloudWatch Logs，方便后续查询审计

注意事项 #

• 开启CloudTrail数据事件会产生额外的日志存储和处理成本，建议按需筛选需记录的操作，避免不必要开销
• 对于AMS（AWS Managed Services）环境，需确认自身有足够权限配置CloudTrail数据事件，或联系AMS管理员协助配置

内容的提问来源于stack exchange，提问作者Joey Yi Zhao