更换实例所用的 AMI，相当于在服务照常运行的同时更换它的地基。做得不好意味着中断；做得好，用户 几乎察觉不到。好消息是：业界已有成熟的模式，能让这次迁移既安全又可逆。
共同的基础是：不去改动运行中的实例，而是用新 AMI 启动新实例，再有控制地转移流量。
迁移之前：先把地基铺好
- 在与生产完全一致的预发环境里测试新 AMI。
- 可靠的健康检查：定义那些能真正确认新实例健康的检查项。
- 回滚方案：把上一个版本和回退步骤都准备好。
- 可观测性：备好指标与告警，以便第一时间发现退化。
零停机的迁移策略
| 策略 | 工作方式 | 适合场景 |
|---|---|---|
| 滚动更新 | 分批、逐步替换实例 | 处于 Auto Scaling Group 中的服务 |
| 蓝绿部署 | 起一套新环境，然后一次性切换流量 | 需要瞬时回滚的迁移 |
| 金丝雀发布 | 把一小部分流量导向新版本 | 以低风险在生产中验证 |
三种在不中断服务的前提下更换 AMI 的模式。
滚动更新
你把 Launch Template 更新为新 AMI，Auto Scaling Group 就会分批替换实例：先起新的，等它们 通过健康检查，再撤下旧的。做法简单，也不需要额外基础设施，只是会有一段时间两个版本并存。
蓝绿部署
你用新 AMI 起一套并行环境（green），同时现有环境（blue）继续对外服务。等 green 验证通过， 就在负载均衡器或 DNS 层把流量切过去。一旦出问题，几秒钟就能切回 blue。这是回滚最快的模式， 代价是要临时占用双倍资源。
金丝雀发布
你把一小部分流量导向使用新 AMI 的实例，然后观察。如果指标稳住，就逐步把比例提高到 100 %。 这能把意外问题的影响半径压到最小。
迁移之后
- 在宣布迁移成功之前，先盯一段合理时间的指标与日志。
- 把旧 AMI 标记为弃用，免得被误启动。
- 记录已上线的版本，以及这次变更的原因。
- 不要立刻删掉旧镜像：留着，以备回滚之需。
常见问题
要做到零停机，哪种策略最好？
蓝绿部署回滚最快；滚动更新更简单也更省钱；金丝雀通过在生产中验证把风险压到最低。选哪种，取决 于你的风险承受度与基础设施预算。
迁移是不是必须把基础设施翻倍？
只有蓝绿部署需要，而且只是暂时的。用滚动更新或金丝雀，你复用同一个组、逐步替换实例，不必复制 整个环境。
怎样确保我能退回去？
保留上一个 AMI 及其 Launch Template，定义可靠的健康检查，并在开始迁移之前把回滚流程演练一遍。
在 imaxe.cloud，我们为镜像做版本管理，让版本之间的迁移既可预期又可逆。
蓝绿部署滚动更新金丝雀自动伸缩部署
