触发SSM参数存储变更的AWS EventBridge规则无法正常工作

以下是针对该问题的实际排查和解决步骤：

1. 先确认SSM事件是否真的到达默认事件总线 #

如果EventBridge规则没触发，首先要排除"事件根本没发出来"的可能：

• 给默认事件总线开启CloudWatch日志记录：进入EventBridge控制台 → 选择默认EventBus → 点击"编辑" → 启用"日志记录"，指定一个CloudWatch日志组。之后操作SSM参数（增/删/改），去日志组里查看是否有source: aws.ssm的事件。
  • 如果日志里没有对应的事件，说明SSM没发送事件，直接跳转到步骤4；
  • 如果日志里有事件，但规则没触发，说明是规则的匹配问题，跳转到步骤2。

2. 验证事件模式的准确性 #

控制台生成的模式看似正确，但可以先简化模式做测试：

• 把事件模式改成只匹配source：

  {
    "source": ["aws.ssm"]
  }
  

  然后操作SSM参数，看规则是否触发。如果触发了，说明原模式里的detail-type匹配有问题——此时查看CloudWatch日志里的实际事件，确认detail-type的准确值（比如是否有拼写差异）。
• 如果简化模式还是没触发，检查规则的区域是否和SSM参数所在区域完全一致，跨区域的事件不会自动流转到其他区域的总线。

3. 检查参数操作的触发条件 #

• 如果是通过CLI/SDK调用SSM API（比如PutParameter），确认是否加了--no-notification参数。这个参数会禁止发送变更事件，手动在控制台操作默认不会带这个参数，但脚本里可能误加。
• 确认参数的类型（String/Secure/StringList）不影响事件发送——三种类型的参数变更都会触发事件，无需额外配置。

4. 排查事件发送的底层限制 #

• 如果是AWS Organizations成员账号，检查组织的SCP（服务控制策略）是否限制了SSM发送事件的权限，比如是否存在阻止ssm:SendNotification或者events:PutEvents的策略。
• 检查账号的服务配额：虽然概率极低，但如果events:PutEvents的配额耗尽，也会导致事件无法发送到总线，可以在AWS配额控制台查看相关指标。

5. 规则目标的额外验证 #

如果规则的CloudWatch指标显示"触发次数"不为0，但目标没执行，那是目标的权限问题（比如Lambda的执行角色没有被EventBridge调用的权限），但你的问题是规则完全没触发，这条可以暂时忽略。

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