假设我已经从一个EC2实例创建了一个AMI。现在，我可以手动将其添加到LB中，或者让AutoScaling组为我做这件事（基于我提供的条件）。到目前为止一切都很好。
现在，假设我的开发人员添加了一个新功能，我在现有实例上提取了新代码。请注意，AMI在这一点上没有更新，并且仍然具有旧代码。我的问题是，我应该如何处理这种情况，以便当自动缩放组从我的AMI创建一个新实例时，它将使用最新的代码。
我想到了两种方法，如果你有其他解决方案，请告诉我：
a） 随时更新AMI；这意味着无论何时出现拉取请求，都应该删除旧的AMI并用新的AMI替换。
b） 在AMI上有一个启动脚本（cloudinit），它将在初始启动时从存储库中提取最新的代码。（通过在实例上存储存储库凭据并直接从git中提取代码）
以下哪种方法更好？如果两者都不好，那么实现这一目标的最佳实践是什么？
假设任何事情（几乎）都可以使用API使用AWS实现自动化；它将再次归结为手头的特定用例。
一开始，人们会建议安装和配置一个基本的AMI，其中包含必要的软件包，并拥有下载源代码的init脚本。这里需要计算的非常重要的因素是签出或提取代码、配置实例并使其准备就绪所花费的时间。如果这个时间段非常长，那么使用这种策略进行自动缩放是个坏主意。由于预热时间与自动缩放相结合；云观察的统计数据将导致不同的现实[可能是/可能不是-但概率不是零]。这时您可能会考虑经常烘焙一个新的AMI。这将使您能够最大限度地减少实例为对抗交通的战争做准备所花费的时间。
我建议测量一下，看看哪一个都方便又划算。拆除实例并使用AMI重新启动需要花费真金白银；然而，这是你需要做出的权衡。
虽然，我已经回答得很少了；因为。问题也不大。
人们已经开始使用Chef，Ansible，Puppet来执行配置管理。这些工具总共增加了不同级别的自动化；你也想探索一下这个选项。类似的方法是使用Docker或其他容器。
a） 随时更新AMI；意味着只要有pull请求，旧的AMI应该被删除并替换新的。
您不应该将源代码存储在AMI中。这带来了一场维护噩梦，以及您已经发现的自动缩放问题。
b） 在AMI上有一个启动脚本（cloudinit），该脚本将提取首次启动时存储库中的最新代码。（通过存储实例上的存储库凭据并直接提取代码从git）
以下哪种方法更好？如果两者都不好，那么实现这一目标的最佳实践是什么？
您的第二项，即在服务器启动时下载源代码，是正确的方法。
其他选项是使用Amazon CodeDeploy或其他部署服务来部署更新。部署服务还可以用于将更新部署到现有实例，同时允许新实例在启动时自动下载最新代码。