我正在将应用程序迁移到 Amazon，ElasticBeanstalk 似乎是正确的工具。
此应用程序需要一些未安装在默认 AMI 中的软件包，我找到了两种为我的应用程序生成完整环境的方法：
自定义 AMI：只需将一些包添加到默认 AMI 并将其保存为我的自定义 AMI。
Docker容器：使用支持Docker的亚马逊镜像，提供Dockerfile，让亚马逊构建和部署镜像。
我的问题是，推荐的选项是什么？
我担心与自动缩放相关的性能或部署时间（会有多个实例）
我想知道是否有人知道真正的利弊或每个选项（理论上两个选项都是“相等的”）。 我也知道这两种方法（自定义 AMI 和 Docker），但从未在高负载环境中尝试过。
经过一段时间尝试不同的选择后，我有足够的信息来回答自己。
我发现更好的是 Elastic Beanstalk 而不是使用自定义 AMI，然后使用 ebextensions 自定义实例 使用 ebextensions，您可以完全自定义您的实例（包、文件……一切）。好处是您的实例将自动更新并且您不会失去对实例的控制。缺点是你必须使用亚马逊弹性豆茎。
我还注意到 docker 是一个不必要的额外层。对开发非常有用，但对生产有点头疼，因为你失去了对实例的控制。
我的选择（根据我的个人经验）是使用默认的 amazon ami，然后使用 ebextensions 自动自定义它们。
有关为 Elastic Beanstalk 创建自定义 AMI 的AWS 文档 包含有关如何正确创建自定义 AMI 的步骤。介绍很好地讨论了 AMI 与配置文件的优缺点：
如果您需要安装标准 AMI 中未包含的大量软件，则在您的环境中启动实例时，自定义 AMI 可以缩短配置时间。
使用配置文件非常适合快速一致地配置和自定义您的环境。但是，在环境创建和更新期间应用配置可能会开始花费很长时间。如果你在配置文件中做了很多服务器配置，你可以通过制作一个已经有你需要的软件和配置的自定义 AMI 来减少这个时间。
自定义 AMI 还允许您对难以实施或需要很长时间才能在配置文件中应用的低级组件（例如 Linux 内核）进行更改。要创建自定义 AMI，请在 Amazon EC2 中启动 Elastic Beanstalk 平台 AMI，根据您的需要自定义软件和配置，然后停止实例并从中保存 AMI。
它显然因用例而异，但听起来一般推荐的方法是使用配置，除非你需要大量修改你的环境以至于启动时间成为一个因素。还应该考虑他们的团队可能需要将配置文件与应用程序代码分开。