跨账号STS角色假设时CloudWatch Events触发SNS失败排查求助

我之前也踩过跨账号CloudTrail+CloudWatch Events配置的坑，结合你的场景，给你梳理几个关键排查方向：

1. 先确认CloudTrail是否真的捕获到了AssumeRole事件 #

• 检查CloudTrail的事件选择器：确保勾选了Write类型事件（AssumeRole属于Write操作），且没有排除STS服务。
• 验证S3桶日志权限：存储CloudTrail日志的跨账号S3桶，要确认桶策略允许CloudTrail所属账号写入（你大概率已经配置，但再核对下更稳妥）。
• 直接查看S3日志文件：在存储日志的桶里找最近的日志，搜索AssumeRole关键词，确认是否有对应的事件记录。如果日志里都没有，CloudWatch Events肯定收不到信号。

2. 修正CloudWatch Events的事件模式 #

你的现有模式有几个明显的问题：

• eventSource字段不完整：必须写全sts.amazonaws.com，拼写截断会直接导致匹配失败。
• 缺少具体API名称：只匹配STS服务范围太广，要加上eventName: ["AssumeRole"]精准定位角色假设操作。
• 正确的事件模式示例：

  {
    "source": ["aws.sts"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventSource": ["sts.amazonaws.com"],
      "eventName": ["AssumeRole"]
    }
  }
  

• 如果要监控特定跨账号的假设行为，还可以额外添加detail.userIdentity.accountId: ["目标账号ID"]缩小范围。

3. 确认CloudTrail与CloudWatch Events的跨账号集成配置 #

这是跨账号场景最容易忽略的环节：

• CloudWatch Events不会自动读取S3里的CloudTrail日志，必须在CloudTrail配置里开启「发送事件到CloudWatch Events」，并指定目标账号的CloudWatch Events（如果两者不在同一账号）。
• 跨账号时，需要在CloudTrail所属账号配置IAM策略，允许CloudTrail服务向目标账号的CloudWatch Events发送事件；同时目标账号的CloudWatch Events规则也要有接收权限。

4. 检查CloudWatch Events规则的基础状态与权限 #

• 确认规则处于启用状态：有时候配置后不小心禁用，直接导致不触发。
• 验证目标SNS权限：如果规则的目标是SNS主题，要确保SNS的访问策略允许CloudWatch Events服务主体（events.amazonaws.com）执行SNS:Publish操作。

5. 用测试事件验证匹配逻辑 #

CloudWatch Events自带测试功能，可以快速定位问题：

• 从CloudTrail日志里复制一条真实的AssumeRole事件记录（如果日志里存在的话）。
• 在规则页面点击「测试事件」，粘贴这条事件，查看是否匹配成功。如果测试匹配失败，说明事件模式还有问题；如果匹配成功，那问题出在事件流的传递环节（比如CloudTrail没把事件推送到CloudWatch Events）。

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