首次创建Cognito用户池时关联Lambda函数遇AccessDenied问题求助

我之前也碰到过这个一模一样的坑！核心问题是Terraform资源创建的时序不对，导致Cognito调用Lambda时权限还未生效，下面给你详细拆解：

为什么首次创建会报AccessDenied？ #

当你在同一份Terraform配置里同时定义Cognito用户池、Lambda触发器，以及Lambda的调用权限时，Terraform默认的资源依赖推断可能出问题：它可能先把用户池和Lambda触发器关联起来，再创建允许Cognito调用Lambda的权限。这时候Cognito尝试触发Lambda时，对应的IAM权限还没生效，自然就抛出了AccessDenied错误。

举个直观的场景：你的配置里有aws_cognito_user_pool、aws_lambda_permission、aws_cognito_user_pool_trigger三个资源，但Terraform没意识到触发器必须等权限创建完成才能部署，导致时序颠倒。

为什么移除再关联就正常？ #

当你手动移除触发器再重新关联时，那个允许Cognito调用Lambda的aws_lambda_permission已经存在了。这时候Cognito去触发Lambda，权限已经完全生效，所以就能正常运行了。

解决办法（亲测有效） #

1. 显式设置资源依赖（最可靠） #

在你的aws_cognito_user_pool_trigger资源里添加depends_on参数，明确让它等Lambda权限创建完成后再部署。示例代码如下：

# 定义Cognito用户池
resource "aws_cognito_user_pool" "main" {
  name = "my-user-pool"
  # 其他配置...
}

# 定义Lambda函数
resource "aws_lambda_function" "pre_sign_up" {
  filename      = "lambda.zip"
  function_name = "pre-sign-up-trigger"
  role          = aws_iam_role.lambda_exec.arn
  handler       = "index.handler"
  runtime       = "nodejs18.x"
  # 其他配置...
}

# 给Lambda添加允许Cognito调用的权限
resource "aws_lambda_permission" "cognito_trigger" {
  statement_id  = "AllowCognitoInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.pre_sign_up.function_name
  principal     = "cognito-idp.amazonaws.com"
  source_arn    = aws_cognito_user_pool.main.arn
}

# 关联触发器，明确依赖权限资源
resource "aws_cognito_user_pool_trigger" "pre_sign_up" {
  user_pool_id = aws_cognito_user_pool.main.id
  trigger_type = "PreSignUp"
  lambda_arn   = aws_lambda_function.pre_sign_up.arn

  # 关键：确保权限先创建完成
  depends_on = [aws_lambda_permission.cognito_trigger]
}

2. 检查隐式依赖是否生效 #

如果你的aws_lambda_permission里的source_arn直接引用了用户池的ARN（如上面示例），function_name引用了Lambda的名称，Terraform理论上会自动推断依赖关系：先创建用户池和Lambda，再创建权限，最后创建触发器。但如果你的配置里用了变量或者其他间接引用，可能导致隐式依赖失效，这时候显式的depends_on就更稳妥。

额外检查点 #

• 确认aws_lambda_permission的principal是cognito-idp.amazonaws.com，别拼写错误；
• 确认source_arn是用户池的完整ARN，不是用户池ID，否则权限范围不匹配。

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