AWS ASG如何实现新旧EC2并行的非阻塞蓝绿部署更新策略

你需要的非阻塞、带独立测试窗口的新旧EC2实例并行蓝绿更新模式完全可以落地，CloudFormation原生单ASG滚动更新策略无法直接满足该需求，目前已有大量生产环境落地案例。

• 你当前配置的autoScalingRollingUpdate属于强阻塞更新逻辑：新实例启动后，CloudFormation会等待实例发送成功信号直到pauseTime超时，整个栈的更新流程会卡在UPDATE_IN_PROGRESS状态，直到所有批次实例替换完成或回滚，完全做不到“测试期间部署流程不阻塞”的要求。
• 你查到的WillReplace属性属于资源更新元数据标记，仅用于更新预览时提示该资源是否会被替换，无法修改滚动更新的底层执行逻辑，不能实现你要的效果。

目前生产环境常用的实现路径主要有两种，都不需要依赖第三方工具：

方案1：双ASG蓝绿架构（推荐，稳定性最高） #

• 核心逻辑是放弃单ASG滚动更新逻辑，维护两套配置完全独立的Auto Scaling组：蓝组承载当前线上流量的EC2_old实例，绿组承载待上线的EC2_new实例，两组实例同时挂载到负载均衡目标组，通过流量权重控制切流节奏。
• 执行流程：
  • CloudFormation触发更新时，首先创建新版本对应的绿组ASG，将期望实例数配置为与蓝组一致，新实例启动完成后先将绿组在目标组的流量权重设为0，此时所有线上流量仍由旧实例承载，新旧实例处于并行运行状态。
  • 绿组实例就绪后CloudFormation直接将栈状态标记为UPDATE_COMPLETE，不会等待后续测试流程，15-30分钟的验证窗口由独立的CI/CD流水线或定时调度逻辑触发，不会阻塞CloudFormation本身的栈流程。
  • 测试通过后逐步将绿组流量权重调整至100%，观察业务指标无异常后，等待1-2个业务低峰周期再删除蓝组资源；如果测试失败，直接销毁绿组ASG即可，全程线上流量无感知。
• 该方案可以通过CloudFormation自定义资源（Lambda实现）配合负载均衡权重调整能力落地，不需要改动现有业务部署逻辑。

方案2：单ASG临时扩容改造（改造成本最低） #

如果不想维护两套ASG，可以基于现有单ASG做轻量改造：

• 首先删除模板中原生的autoScalingRollingUpdate更新策略，完全弃用CloudFormation内置的滚动更新逻辑。
• 触发更新前，先给所有正在运行的EC2_old实例开启ScaleIn缩容保护，再更新ASG的启动模板/启动配置版本，将ASG期望实例数调整为原有值的2倍，ASG会自动启动等量的EC2_new实例，此时新旧实例并行运行。
• 新实例启动完成后，CloudFormation的栈更新流程就已经执行完成，不会阻塞后续操作；新实例可以绑定独立的测试入口，预留15-30分钟做验证。
  • 测试通过：将线上流量切到新实例，移除旧实例的缩容保护，把ASG期望实例数调回原有值，ASG会自动缩容掉所有旧实例。
  • 测试失败：直接把ASG期望实例数调回原有值，移除新实例的缩容保护，ASG会自动回收所有新启动的待验证实例，线上业务无影响。

你当前使用的原生滚动更新配置如下，该配置天生带阻塞属性，无法适配蓝绿并行的需求：

updatePolicy = {
    autoScalingRollingUpdate: {
        maxBatchSize: 1,
        minInstancesInService: 1,
        pauseTime: "PT1H",
        waitOnResourceSignals: true,
        suspendProcesses: [
            "HealthCheck",
            "ReplaceUnhealthy",
            "AZRebalance",
            "ScheduledActions",
            "AlarmNotification"
        ]
    }
};

• 新旧实例并行阶段，建议临时挂起ASG的AZRebalance进程，避免ASG自动跨可用区调度实例打乱部署节奏，等更新完成后再恢复该进程。
• 15-30分钟的测试窗口逻辑不要写在CloudFormation模板的等待逻辑里，交给独立的流水线或定时事件处理，才能保证CloudFormation栈更新流程不会被阻塞。
• 如果用单ASG方案，记得给新老实例打不同的版本标签，方便后续切流、缩容时精准筛选实例。

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