如何在CI/CD流水线中处理CloudFormation更新限制？

针对CloudFormation无法处理的非原子更新（比如Api Gateway路由参数重命名、跨栈依赖的复杂变更），无需手动操作的成熟处理方案如下：

1. 配置带审批节点的多阶段流水线 #

在CI/CD工具（如CodePipeline、GitLab CI）中搭建专属的分步更新流水线，将整个多步流程拆分为流水线的不同阶段，同时嵌入人工审批环节满足企业QA管控要求：

• 阶段1：执行移除旧资源（如旧路由）的CloudFormation变更集并部署
• 阶段2：触发人工审批（由QA或运维团队确认第一步操作生效、业务无异常）
• 阶段3：执行添加新资源（如修改后的新路由）的CloudFormation变更集并部署
• 阶段4：再次触发人工审批，验证新资源功能正常
  所有操作都在受控的流水线环境中执行，彻底规避本地手动部署的安全风险。

2. 拆分变更集分步执行 #

将复杂更新拆解为多个独立的CloudFormation变更集，在CI/CD流程中依次提交执行，中间加入自动化验证步骤替代人工检查：

• 第一步生成并执行移除旧路由的变更集：

  aws cloudformation create-change-set --stack-name my-api-stack --change-set-name remove-old-route --template-body file://remove-old-route.yaml
  aws cloudformation execute-change-set --change-set-name remove-old-route --stack-name my-api-stack
  

• 自动验证：调用Api Gateway的测试接口，确认旧路由已无法访问
• 第二步生成并执行添加新路由的变更集，完成后续部署
  这种方式无需拆分代码提交，所有变更逻辑都在同一个代码版本中，通过变更集实现分步操作，减少人工干预的同时保证流程可控。

3. 采用蓝绿部署策略 #

针对跨栈依赖或高风险的更新场景，用蓝绿部署替代分步修改：

• 保留运行中的旧版本CloudFormation栈（蓝栈），基于更新后的模板部署新版本栈（绿栈）
• 在绿栈上完成QA验证，确认新路由等资源功能正常后，切换流量（如Api Gateway域名解析、负载均衡转发规则）到绿栈
• 验证业务完全切换正常后，再删除旧的蓝栈
  这种方式彻底避免了中间步骤的复杂性，同时保证业务零中断，完全符合企业的QA验证流程。

4. 封装自定义部署脚本 #

编写Shell或Python脚本，将多步更新逻辑、验证步骤封装为一个可执行单元，在CI/CD流水线中直接调用：

• 脚本内置CloudFormation部署命令、资源状态检查（如查询Api Gateway路由是否存在）、业务验证逻辑
• 加入条件判断，只有当前步骤执行验证通过后，才继续推进下一步操作
• 脚本与CloudFormation模板一起纳入代码仓库版本化管理，确保所有操作可追溯、无人工操作风险

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