很多团队把 AMI 当成「建一次就忘掉」的东西。问题会在几个月后浮现：几十份没有标签的镜像、没人 敢确认能不能删的 EBS 快照，以及一张莫名其妙不断上涨的账单。管理 AMI 的生命周期，意味着把 它当成一个软件产物来对待：有诞生、有版本、有成熟期、有弃用，也有退役。
良好的镜像治理能降低成本、提升安全——不会有人误启动一份一年前、没打补丁的镜像——并让合规审计 变得轻松。
阶段一 —— 有意义的版本管理
版本管理是脊梁。没有它，「最新那份好用的 AMI」只是走廊里的口头约定，而不是可查的事实。我们 建议采用一套可读且一致的方案。
- 带版本的名称：例如
imaxe-ubuntu22-nginx-2026.07.1，包含产品、基线与日历版本。 - 必备标签：
Version、GitCommit、BuildDate、Owner、Environment、CISLevel、Status。 - 不可变：一个版本，一份产物。 永远不要修改已发布的 AMI；创建新版本即可。
- 中心化登记：用 AWS Systems Manager Parameter Store 保存「当前生产 AMI」的 ID，让你的 Launch Template 按引用读取。
阶段二 —— 端到端加密
AMI 的数据存放在 EBS 快照里。如果没有加密，任何一份治理不善的副本都是潜在的泄露。加密应当是 常态，而不是例外。
- 默认加密：在账户与区域层面开启 EBS encryption by default。
- 由你管理的密钥（CMK）：使用自己的 KMS 密钥，而非 AWS 默认密钥，以掌控权限与轮换。
- 复制即重新加密：把 AMI 复制到另一个区域或账户时，顺势用目标密钥重新加密。
- 用 KMS grant 共享：把 AMI 分发给其他账户时，以最小权限策略授予密钥访问。
阶段三 —— 弃用：先预警，再删除
AWS 允许给 AMI 打上带日期的弃用（deprecated）标记。从那一刻起，它在默认搜索中不再出现， 但对显式引用它的人依然可用。这是「在用」与「已删除」之间那个体面的中间态：你发出了预警、给了 迁移的余量，也不会弄坏别人的部署。
阶段四 —— 自动清理（以及快照的隐藏成本）
钱就藏在这里。当你删除一份 AMI 时，它关联的 EBS 快照并不会自动删除。这正是存储账单神秘 增长的头号原因。一套退役策略必须先注销 AMI，随后删除它留下的孤儿快照。
- 保留策略：保留最近 N 个版本（比如最近三个），其余退役。
- 用云能力自动化：Amazon Data Lifecycle Manager（DLM）可以按策略管理镜像的创建与删除。
- 围猎孤儿快照：定期审计没有关联 AMI 的快照并清除。
- 绝不盲删：退役前先确认没有活跃实例或 Launch Template 依赖这份 AMI。
生命周期一览表
| 阶段 | 关键动作 | 工具或服务 |
|---|---|---|
| 创建 | 可复现的构建与打标签 | Packer / EC2 Image Builder |
| 加密 | 用 CMK 加密快照 | AWS KMS + EBS 默认加密 |
| 分发 | 跨区域或跨账户复制与重新加密 | AMI copy / AWS RAM |
| 在用 | 登记当前 ID | SSM Parameter Store |
| 弃用 | 打上带日期的弃用标记 | ec2 enable-image-deprecation |
| 退役 | 注销并删除快照 | DLM / 定时脚本 |
AMI 治理的六个阶段，以及如何把它们自动化。
你应该盯住的指标
- 在用 AMI 的平均年龄：越低，补丁越新。
- 孤儿快照数量及其每月成本。
- 已加密 AMI 的比例，目标是 100 %。
- 从关键 CVE 到新镜像发布的时间，也就是补丁的 MTTR。
常见问题
我都把 AMI 删了，为什么 EBS 账单还在涨？
因为注销 AMI 并不会删除它的快照。你必须显式删除。定期审计孤儿快照；它们通常是最大的隐藏成本。
把加密过的 AMI 共享给另一个账户安全吗？
安全，只要你通过特定 grant、以最小权限授予对 KMS 密钥的访问。没有这份访问权限，目标账户根本 无法启动该镜像。
一份 AMI 该保留多少个版本？
取决于你的回滚需求与合规要求，但保留最近两到四个版本，通常是回滚保障与成本之间不错的平衡。
在 imaxe.cloud，我们的镜像从源头就带着版本管理与加密，好让它们的生命周期可预期、可审计。
