如何在CodeBuild失败时删除CloudFormation堆栈？

针对你遇到的Lambda超时限制问题，我整理了几个实用的方案，帮你实现测试失败后自动删除动态生成的环境：

方案一：用Step Functions替代Lambda处理长时间任务 #

Lambda的5分钟超时确实会限制长耗时的资源清理操作，而Step Functions支持最长1年的执行时长，完美适配CloudFormation栈删除的需求：

• 先创建一个Step Functions状态机，里面包含调用CloudFormation DeleteStack API的任务，还可以加上重试逻辑（比如栈删除失败时自动重试几次）。
• 配置CloudWatch事件，监听CodePipeline中测试Stage的失败事件（事件类型选CodePipeline Pipeline Execution State Change，过滤条件设为状态是FAILED且对应你的测试Stage），触发这个状态机。
• 如果需要额外的前置逻辑（比如确认测试失败的具体原因），可以在状态机里先调用一个短时间运行的Lambda处理，再执行删除栈的任务。

方案二：优化Lambda逻辑，避免同步等待超时 #

如果还是想继续用Lambda，可以调整执行逻辑，不让它同步等待删除完成：

• 让Lambda只负责触发CloudFormation的删除操作，调用DeleteStack API后立即返回，不需要等待栈删除结束——毕竟CloudFormation删除是异步执行的，Lambda没必要一直挂着等。
• 要是需要监控删除结果，可以配置CloudWatch事件监听CloudFormation栈的状态变化（比如栈变为DELETE_COMPLETE或DELETE_FAILED），再做后续的告警或处理，但核心是Lambda不用卡在删除流程上。
• 另外检查下你的CloudFormation模板，尽量避免依赖循环、冗余资源，让栈删除的速度更快，减少超时风险。

方案三：在CodePipeline内直接添加失败清理Stage #

利用CodePipeline本身的阶段过渡逻辑，把清理流程整合到流水线里：

• 给你的测试Stage设置失败后的过渡动作，指定跳转到一个专门的清理Stage。
• 这个清理Stage可以用CloudFormation部署动作，在配置里把ActionMode设为DELETE_ONLY，直接触发栈删除；也可以用自定义Lambda动作（同样用异步触发删除的方式）。
• 这样一旦测试失败，CodePipeline会自动进入清理Stage，不需要依赖外部的CloudWatch事件，流程更闭环。

额外注意事项 #

• 确保执行清理操作的IAM角色拥有足够权限：不仅要有CloudFormation删除栈的权限，还要能删除栈内所有关联的资源（比如EC2、S3、RDS等）。
• 如果有多个测试环境栈，可以给它们统一打上标签，清理时通过标签批量删除，提升效率。
• 给清理操作添加日志和告警，比如栈删除失败时触发SNS通知，避免残留资源浪费成本。

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