AWS EBS使用immutable deployment时实例重复替换原因排查

在AWS环境配置基于*immutable deployment（不可变部署）*的版本升级流程时，整体运行基本正常，但存在固定异常：旧Auto Scaling Group（ASG）删除完成后，新创建的实例会被再次触发替换重载。

该异常不属于不可变部署的原生流程逻辑，本质是新ASG下的实例在旧ASG下线收尾阶段未通过健康校验，或被账号内其他自动化规则判定为异常，触发了自动替换逻辑。
不可变部署的标准流程为：启动临时ASG部署新版本→实例通过健康校验后接入流量→下线并删除旧ASG→流程结束，正常情况下旧ASG删除后不会再触发新实例替换。

按故障出现概率从高到低排序：

• 平台健康检查规则配置
  优先核对部署服务自带的健康检查配置：确认健康检查宽限期时长是否匹配应用实际启动耗时，健康检查路径、成功状态码、超时阈值配置是否正确，是否关闭了健康检查忽略开关。如果是Elastic Beanstalk环境，还要登录实例确认aws-elasticbeanstalk-healthd服务正常运行，没有被自定义镜像、启动脚本误停。
• ASG与负载均衡器的健康检查冲突
  核对ASG自身的健康检查类型：如果配置为ELB类型健康检查，需要同步核对负载均衡器/目标组的健康检查间隔、不健康阈值、宽限期参数，避免负载均衡侧健康检查规则比部署服务更严格，在应用尚未完全启动就绪时就标记实例不健康，触发ASG自动替换。
• 额外自动化规则冲突
  排查ASG是否绑定了自定义生命周期钩子、Lambda事件触发器，同时核对账号内是否配置了AWS Config合规规则、Systems Manager自动化运维规则、ASG实例刷新任务，这类规则如果在旧ASG删除后执行实例合规校验，很容易和部署流程冲突，触发非预期的实例替换。
• 部署策略参数配置错误
  核对不可变部署的Health check success threshold（健康检查成功阈值）、Minimum healthy instance percentage（最小健康实例占比）参数，如果阈值设置过低，会导致临时ASG中尚未完全启动成功的实例被误判定为部署合格，等旧ASG删除、全量流量切到新实例后才暴露服务异常，触发实例替换。
• 自定义启动逻辑异常
  如果使用了自定义AMI，或者通过配置文件定义了实例启动后置脚本，需要确认脚本总执行时长是否超过健康检查宽限期，是否存在脚本在系统启动完成后才触发服务重启的逻辑——这类问题会导致实例接入流量后短时间服务不可用，被健康检查判定为异常触发替换。

排查效率提示：优先拉取被替换实例的系统日志，Elastic Beanstalk环境直接看/var/log/eb-engine.log、/var/log/healthd/daemon.log，普通ASG场景看/var/log/cloud-init.log和业务服务日志，先定位实例被标记为不健康的具体时间点和直接原因，再对应核对配置，效率远高于逐项盲查。

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