CloudFormation重建曾用名栈时backend-prod卡REVIEW_IN_PROGRESS无事件问题咨询

旧栈名残留的猜想是否成立 #

你的猜测大概率完全命中问题根因。
CloudFormation栈卡在REVIEW_IN_PROGRESS状态、且无对应事件记录，最典型的触发场景就是同名旧栈未被完全清理、处于异常锁死状态。如果是新栈创建流程本身的参数错误、权限不足等问题，不管故障出在哪个环节，至少会生成一条栈创建的初始事件，不会出现完全无记录的情况。

旧栈残留猜想的验证方法 #

• 拉取当前账号下全量CloudFormation栈列表，不要仅筛选状态为CREATE_COMPLETE、UPDATE_COMPLETE的正常栈，要覆盖DELETE_FAILED、ROLLBACK_COMPLETE、REVIEW_IN_PROGRESS等所有异常状态的历史栈，直接检索backend-prod栈名，确认是否存在残留记录。
• 执行CLI命令校验栈实际状态：aws cloudformation describe-stacks --stack-name backend-prod，如果能正常返回栈的元数据，但调用describe-stack-events接口拉取对应栈事件时返回空结果，基本可以判定存在栈状态锁死的残留问题。
• 核对pipeline执行日志中创建backend-prod栈步骤返回的原始StackId，如果该ID和控制台查到的残留历史栈ID完全一致，就可以100%确认是pipeline在创建新栈时命中了已存在的同名旧栈，直接触发状态校验卡死。

跨服务查询故障原因的渠道 #

• 通过CloudTrail的审计事件检索，直接筛选backend-prod相关的CloudFormation API调用记录。不管是旧栈残留触发的权限拦截、参数校验失败、资源关联冲突，这类被CloudFormation栈事件流忽略的报错，都会在CloudTrail的API返回结果中留存完整错误信息。
• 核对当前账号对应区域的CloudFormation服务配额，部分同名栈触发的全局资源关联、栈数量超限问题，不会推送到CloudFormation的栈事件列表，但会在CloudTrail的错误响应字段中明确标注错误码。
• 直接查看pipeline部署步骤的原始API返回值，很多部署流水线会截断CloudFormation返回的“目标栈已存在、状态不匹配无法继续部署”类提示，仅展示步骤卡在等待状态，不会把底层报错直接透传到前端界面。

问题的具体解决步骤 #

• 确认存在旧栈残留后，先对残留的backend-prod栈执行强制删除。如果旧栈之前卡在DELETE_FAILED状态，需要先手动解绑栈下关联的孤立资源（比如旧栈遗留的S3桶、IAM角色、安全组等），为CloudFormation授予对应资源的删除权限，直到该栈的所有元数据记录被完全从控制台清除。
• 残留栈彻底清理完成后，重新触发pipeline的部署流程，正常情况下backend-prod栈会生成全新的StackId，从CREATE_IN_PROGRESS状态开始走全流程，事件列表也会正常输出每一步的执行记录。
• 临时应急方案：如果业务需要快速恢复部署，可在pipeline.yaml配置中为backend-prod栈增加全局唯一的标识后缀（比如拼接当前部署批次的时间戳），绕开同名栈的冲突校验，先保障部署流程跑通，后续再择期清理历史残留的栈记录。

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