CloudWatch Rule权限正确可触发但无法调用Lambda（BOTO3创建场景）

优先核查Lambda的资源调用策略（Boto3创建流程最常见的踩坑点） #

• 注意区分两类完全独立的Lambda权限：一类是Lambda执行阶段依赖的IAM执行角色权限，另一类是允许外部服务调用Lambda本身的资源策略权限，后者不属于执行角色的权限覆盖范围，哪怕执行角色权限配的再高，缺了这部分授权，CloudWatch也会被Lambda拦截调用请求。
• 控制台手动创建CloudWatch规则关联Lambda的流程中，AWS会自动帮你补上这部分授权；但通过Boto3编写脚本创建规则的流程不会自动附带这个配置，是90%以上同类问题的根因。
• 具体校验逻辑：确认Lambda的资源策略中，存在允许服务主体events.amazonaws.com、以对应CloudWatch规则的完整ARN为源，执行lambda:InvokeFunction的授权条目。如果缺失，可以通过Boto3调用Lambda的add_permission接口补上配置，示例代码：

lambda_client.add_permission(
    FunctionName="你的Lambda函数名称",
    StatementId="cw-rule-invoke-lambda-perm-001", # 同一Lambda下要保持唯一
    Action="lambda:InvokeFunction",
    Principal="events.amazonaws.com",
    SourceArn="对应CloudWatch事件规则的完整ARN"
)

排查Rule目标配置的匹配错误 #

• 检查Boto3配置目标时传入的Lambda ARN是否准确：常见问题包括填入了已删除的Lambda版本/别名的ARN、跨账号场景下漏填了对方账号ID的ARN、拼写错误导致的ARN匹配失效。这类问题会直接导致CloudWatch在发起调用时找不到对应的目标资源。
• 检查目标配置中是否自定义了输入转换规则、或硬编码的输入载荷：如果载荷格式不符合Lambda的入参校验逻辑，会导致请求到达Lambda后第一时间抛出执行异常，这类报错可以在Lambda自身的执行日志流中直接查到对应栈信息。

匹配CloudWatch调用链路的日志定位根因 #

• 对照CloudWatch事件规则的监控指标交叉校验：在规则的指标面板中确认Invocations指标和你感知的“规则可正常触发”的时间点匹配，同时查看FailedInvocations指标的分类：
  • 如果报错归类为ClientError：基本指向权限校验不通过、目标ARN不存在这类客户端配置问题
  • 如果报错归类为TargetExecutionFailed：说明CloudWatch已经成功将请求发送到Lambda，错误来自Lambda函数内部的执行逻辑，直接检索Lambda对应的CloudWatch执行日志即可定位具体报错点
• 排除误判场景：如果你是通过手动点击控制台的“测试”按钮触发的规则，不代表定时调度链路是正常的；可以检查规则配置的状态值，确认是ENABLED状态，避免出现“手动触发能通、定时调度因为规则未启用完全不跑，但你误以为规则一直正常触发”的认知偏差。

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