我们计划使用非“预烘焙”的 AMI EC2 实例。即，当它们启动时，它们是 AWS linux 的裸安装。我们的引导过程将引入我们需要的各种安装，例如 python、tomcat。我们将有最少 3 个实例和最多 8 个实例。
鉴于这些要求，使用 Puppet/Chef 会比使用 Amazon Cloud Formation (CloudInit) 有用吗？
我能看到的最好的情况是，如果我们使用 Puppet，那么我们将拥有更容易审计的声明式编程，以查看发生了什么而不是脚本。CloudInit 也有一个 16k 的脚本大小限制，我们可能会也可能不会遇到。
是否有人出于特定原因从 CloudInit 迁移到 Puppet 或 Chef，他们可以在此处提供以回答我的问题？
比 CloudInit 有优势吗？是的，当然，其中很多！
当然，您可以编写自上而下运行一次 CloudInit 脚本来配置服务器。但是当您需要更改配置文件、添加用户、更新包或安装新包时会发生什么？您最终将登录服务器或为此编写脚本，并且不可避免地会出现服务器的不协调状态。
CloudInit 不是配置管理。如果您选择开始使用配置管理软件，只需使用 cloud init 完成一项任务：引导 Puppet/Chef/other 代理。
Puppet 不仅可以帮助您自动安装包、设置 ssh 密钥或调整 Tomcat 堆。它确保了事物的状态。当开发人员在凌晨 3 点对 Java 应用程序进行故障排除并更改您的 Tomcat 配置时，Puppet 会将其更改回来。您可以快速更改所有节点或节点组的 Python 版本，如果有人安装了不同的版本，Puppet 会将其更改回来。
当您的应用程序堆栈发生更改并且您开始使用 RabbitMQ、Jetty 或新的 RDBMS 时，您可以轻松地在数万或数千台服务器上测试和部署更改。
使用配置管理软件还有许多其他原因，例如后端报告、审计和安全合规性。
配置管理的全部意义在于以可预测和一致的方式启动机器。当您仅限于 AWS 时，CloudFormation 和 cloudinit 非常棒（尽管调试 CloudFormation 模板是一种痛苦的体验），但是对于同时使用数据中心资源和 AWS、本地测试环境或开发机器的应用程序呢？
如果你纯粹存在于 AWS 中，我想你可以只使用 cloudinit 而没有别的，但我不相信这对于任何规模的应用程序都是现实的（例如，Netflix 使用他们编写的 OSS 技术预烘焙他们的 AMI并向全世界发布；请查看此视频了解详情）。高可用性应用程序是跨区域的，通常基于 VPC，倾向于跨 VPN 备份到数据中心，这甚至不涉及演示、登台、测试或开发环境。作为负责配置机器的人，我最不想做的事情就是重复工作或在调试多种配置方法时陷入困境。
因此厨师或木偶。它们适用于 AWS 和适用于我的数据中心一样好，适用于我的运行Vagrant的开发机器也适用于我偶尔需要的演示环境。我宁愿从 cloudinit 启动 Chef 或 Puppet，也不愿同时维护 cloudinit 和 Chef 或 Puppet。
对于丢弃的服务器，比如说在自动缩放组后面运行，我会说 cloudinit 可能就足够了。linux shell 脚本或 windows powershell 脚本应该可以解决问题。
如果它是您计划管理的长期运行的服务器，则可能是厨师、木偶或码头工人可能会给您带来优势，如已接受的答案中所述。如果您在使用它们后看不到优势，那么您可能不需要该工具。
根据我的经验，使用 AWS 提供的开箱即用的 GUI 工具可以轻松完成一些简单的事情，但是当您处理更复杂的事情时，您会开始发现您可以做的事情是有限的他们的工具。
此时，您可以停下来，也可以找到其他工具（如 Chef 或 Puppet）来帮助您实现更复杂的目标以及做更简单的事情。
你的选择。