Terraform创建AWS CloudWatch日志订阅过滤器触发Lambda时的循环报错与权限问题

1. 当前配置的问题与循环原因 #

你遇到的重试循环完全是配置项写错导致的，具体有两处核心错误：

• 权限的source_arn格式完全错误。CloudWatch日志组的ARN固定以arn:aws:logs:为服务前缀，你误写成了arn:aws:apigateway:，和实际CloudWatch发起调用时携带的真实来源ARN完全不匹配，导致Lambda端鉴权永远不通过。
• 触发重试循环的逻辑：创建订阅过滤器时，CloudWatch Logs服务会先验证对目标Lambda的调用权限，因为ARN不匹配导致鉴权失败，Terraform收到创建接口返回的可重试错误，就会反复发起创建请求，直到5分钟操作超时。

除此之外你观察到的控制台权限缺少StringEquals类型的AWS:SourceAccount条件，是因为Terraform的aws_lambda_permission资源没有显式传入账号ID参数，默认不会自动补全这个条件，和控制台自动生成的带账号隔离的权限策略有差异。

修正后的正确配置示例：

resource "aws_cloudwatch_log_subscription_filter" "sub" {
  name            = "test"
  log_group_name  = "/aws/apigateway/id/stage"
  destination_arn = "arn:aws:lambda:myRegion:111:function:myFunction"
  filter_pattern  = ""
}

resource "aws_lambda_permission" "allow_cloudwatch_to_call" {
  statement_id  = "AllowExecutionFromCloudWatch"
  action        = "lambda:InvokeFunction"
  function_name = "myFunction"
  principal     = "logs.myRegion.amazonaws.com"
  # 修正为CloudWatch日志组的标准ARN格式，替换错误的apigateway前缀
  source_arn    = "arn:aws:logs:myRegion:111:log-group:/aws/apigateway/id/stage:*"
  # 补充账号校验条件，和控制台自动生成的策略保持一致
  source_account = "111"
}

修正以上配置后，CloudWatch创建订阅过滤器时的权限校验就会正常通过，Terraform的循环重试问题会直接消失。

注意：同区域部署时推荐使用带区域标识的日志服务主体logs.<region>.amazonaws.com，不要只用通用的logs.amazonaws.com，否则容易出现额外的鉴权兼容问题。

2. 单权限覆盖多日志组的实现方法 #

完全可以通过一条权限规则覆盖所有10个订阅过滤器，不需要重复创建10条Lambda权限，有两种安全的配置方式：

• 如果所有目标日志组没有统一的命名前缀：将source_arn设置为当前账号下所有日志组的通配规则，比如arn:aws:logs:myRegion:111:log-group:*，同时必须显式加上source_account = "111"的校验条件，避免其他账号的日志组获得调用权限。
• 如果目标日志组有统一的命名路径（比如都属于API Gateway的日志路径/aws/apigateway/*）：可以将通配范围缩小到对应路径，比如source_arn = "arn:aws:logs:myRegion:111:log-group:/aws/apigateway/*"，在覆盖所有日志组的同时缩小权限范围，符合最小权限原则。

不要为了简化配置将source_arn设置为完全通配的*，这种配置会开放Lambda给所有AWS服务、所有账号调用，存在极高的安全风险。

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