AWS CloudFormation嵌套Auth栈部署失败，无明确错误原因

以下是针对该问题的具体排查方案：

• 单独部署认证栈模板
  跳过主栈嵌套逻辑，直接用CLI部署认证栈的模板文件：

  aws cloudformation deploy --template-file auth-stack.yml --stack-name test-auth-stack
  

  这种方式能绕开主栈的层级限制，获取更直接的错误输出——很多时候主栈的日志会隐藏子栈的详细失败原因。

• 检查Cognito UserPool配置细节
  重点核对以下配置项：

  • 用户名属性：是否设置了冲突的唯一性验证规则（比如同时要求邮箱和手机号唯一但逻辑矛盾），或属性格式不符合AWS要求
  • 密码策略：是否满足最低要求（比如长度≥6位，包含大小写/数字/特殊字符的组合）
  • 资源名称：当前AWS区域内是否已存在同名的Cognito UserPool，CloudFormation不允许创建同名资源，部分场景下日志不会明确提示
  • 高级安全配置：如果启用了风险检测或自适应认证，是否配置了正确的IAM角色权限

• 查看CloudFormation控制台的事件历史
  登录AWS控制台进入CloudFormation服务，找到失败的认证栈（即使已删除，也能在「已删除的栈」列表中找到），查看事件列表的详细信息。控制台的事件日志通常比CLI输出更具体，会明确指出如“UserPool名称已存在”或“密码策略无效”等问题。

• 验证部署权限
  确认执行部署操作的IAM用户/角色拥有完整的Cognito资源创建权限，至少需要包含cognito-idp:CreateUserPool、cognito-idp:CreateUserPoolClient（若包含客户端资源）等权限。权限不足时，CloudFormation可能仅提示资源创建失败，不会明确说明权限问题。

• 检查参数传递的正确性
  如果认证栈依赖主栈传递的参数，核对参数值是否符合要求：比如参数长度是否超出UserPool名称的128字符限制，是否包含不允许的特殊字符，或参数类型不匹配（如将数字类型传递给字符串参数）

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