一些背景知识。我想在 eu-west-1 区域使用 EBS 在固态磁盘上设置运行 Ubuntu 14.04 LTS (HVM) 的 64 位 AWS EC2 实例。
在撰写本文时，我在 AWS 控制面板快速启动中提供了Ubuntu Server 14.04 LTS (HVM), SSD Volume Type - ami-f95ef58a。
在 AWS 社区 AMI 中搜索ami-f95ef58a显示此图像为ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-20160114.5 - ami-f95ef58a。因此，这似乎是 2016 年 1 月 14 日发布的 AMI。
然而，如果我搜索http://cloud-images.ubuntu.com/locator/ec2/网站并使用选择框来缩小我的选择范围以满足我的要求，我看到：
eu-west-1 trusty 14.04 LTS amd64 hvm:ebs-ssd 20160314 ami-58cc762b hvm
我认为更高版本（ami-58cc762b）会比快速设置中提供的版本更好。
这让我想到为什么会有这么多 14.04 LTS 版本？当然，LTS 不会改变，所以拥有一个固定的静态 AMI 并在启动时更新它不是更好吗？
AMI 实例是否不断生成以包含补丁和更新，以便管理员不必修改基础安装？
如果是这样，为什么 AWS 不在快速设置中提供最新的 AMI，而是提供过期两个月的 AMI？
答案1
AMI 是静态映像，无法更改。即使可以更新，它们不应该是（至少不是公共 AMI）。
原因是自动化部署依赖于精确已知的基础设施和环境。假设我有一段代码依赖于 AMI 上预安装的某个库，并且我知道该代码适用于当前 AMI。如果我创建一个 CloudForamtion 模板来启动具有该 AMI ID 的实例并运行该段代码，那么它应该总是工作。永远。
然而，如果允许 AMI 进行“更新”，并且该更新导致库发生更改，那么我的代码可能会或者可能不会与库的最新版本兼容，可能会导致代码失败。库更新是否出于善意（即修复错误）并不重要；它需要由应用程序编写器更新 AMI，而不是 AMI 维护者。
如果您使用 CloudFormation 之类的工具来管理您的环境，那么 AMI ID 将存储在您的模板中（最好是版本控制！），并在您准备好测试新版本时进行更新。与新 AMI 的兼容性应该像任何新功能一样进行彻底测试。