部署.NET CI/CD AWS Quick Start管道遇CloudFormation NotStabilized错误求助

• 定位未稳定的资源
  登录CloudFormation控制台，找到失败的堆栈，查看事件标签页，追踪最后几个失败的资源条目，确定具体是哪个资源（EC2实例、CodePipeline、CodeBuild项目或VPC组件等）未完成初始化。重点关注状态停留在CREATE_IN_PROGRESS且长时间无进展，最终触发超时的资源。

• 检查资源依赖与配额限制

  • 核对相关AWS服务的配额：比如EC2实例数量、CodePipeline管道数、CodeBuild并发构建数、VPC弹性IP/子网数量等，在AWS控制台的服务配额页面对应服务下查看，配额不足就提交提额申请。
  • 排查资源依赖阻塞：比如IAM角色权限不足导致后续资源无法创建，或者VPC安全组、NACL配置限制了资源对外通信，使得实例无法完成初始化脚本执行。

• 查看资源详细日志

  • 若涉及EC2实例超时：登录已创建的EC2实例，查看/var/log/cloud-init.log或/var/log/cfn-init.log，里面记录了用户数据脚本的执行细节，排查是否有脚本执行失败、依赖下载超时等问题。
  • 若涉及CodePipeline/CodeBuild超时：进入对应服务控制台，查看管道执行历史或构建日志，确认是否有阶段卡壳（比如源码仓库授权失败、构建环境初始化超时）。

• 调整CloudFormation模板超时配置（可选）
  找到模板中对应资源的CreationPolicy或Timeout属性，比如EC2实例CreationPolicy里的ResourceSignal超时时间，适当延长（比如从默认15分钟调至30分钟）。如果用的是Quick Start嵌套模板，需定位到对应子模板的资源定义修改。

• 手动干预未完成的资源

  • 若确定是EC2实例用户数据脚本卡住，可手动登录实例完成剩余配置，再通过cfn-signal命令发送成功信号，让堆栈继续执行。
  • 若CodePipeline阶段卡壳，手动触发重试或修复阶段配置（比如重新授权源码仓库）后，继续堆栈创建。

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