CloudFormation是AWS提供的强大工具，可通过单个API调用以编程方式创建AWS资源堆栈，例如应用程序的Web层、高性能计算群集或整个应用程序堆栈。它非常强大。特别是与Chef、Puppet或cloud-init结合使用时，使用它肯定被认为是一种良好的AWS实践。调试它让我痛苦不堪。
拿一个生产示例来说：库存中的MongoDB群集模板对我无效。我不知道原因。我相信这通常是一些简单的东西。我的问题不在于我找不出错在哪里。而在于它需要花费20到30分钟才能失败，然后再花费三到四分钟来删除，假设它完全正确地删除资源。
我错过了什么吗？我知道有--disable-rollback标志，并像氧气一样使用它。很久以前我就学会了用cfn-signal包装退出消息，并像从沉没的船上扔下去的压舱物一样进行抛出。我如何使模板调试过程更快，还是我永远卡在半小时后才发现我的错误？
aws cloudformation validate-template命令。它仅验证模板是否为有效的JSON或YAML格式，并不验证键和值的正确性（例如，不检查键名错字）。aws cloudformation validate-template。 - Christopheraws cloudformation validate-template命令来验证模板是否为有效的JSON或YAML格式，但它并不检查键和值是否正确（例如不会检查键中是否存在拼写错误）。 - Daniel KatsProperty validation failure: [Length of value {XYZ} for property {/RepositoryDescription} is greater than maximum allowed length {100}]。根据 validate-template 命令，这不是问题，但 UI 返回此错误。 - 030另一个选择是在一年后将这些模板抽象为第三方库，例如troposphere。该库可以为您构建JSON负载，并沿途执行许多验证。这也解决了"管理1000行JSON文件真的很痛苦"的问题。
在使用复杂堆栈中的任何单独CloudFormation资源之前，确保您彻底了解该资源的创建/更新/删除行为的全部范围，包括使用限制和典型启动/拆除时间，先通过在较小的、独立的堆栈中测试它们的行为来加深理解。
AWS::CloudFront::Distribution资源有时需要30-60分钟才能完成创建/更新/删除，而AWS::EC2::SecurityGroup可以在几秒钟内更新。在执行堆栈创建/更新时，如果任何单个资源出现故障，将会导致堆栈回滚整个一组资源更改，这可能会不必要地销毁其他成功创建的资源，并在构建具有长依赖资源图的复杂堆栈时需要很长时间。
解决方法是通过较小的更新批次分步骤构建您的堆栈，逐个添加资源。这样，当资源创建/更新失败时，回滚不会导致整个堆栈的资源被销毁，而只会销毁最新更新中更改的一组资源。
请务必监视堆栈更新进度, 查看堆栈事件，以便在执行创建/更新时进行调试单个资源问题的起点。
AWS CloudFormation linter 提供了除 aws cloudformation validate-template 之外的额外静态分析。
它会通知您哪些资源类型和实例类型在某些区域不可用，将属性值与允许值进行验证，捕获循环资源依赖关系、语法错误、模板限制等等
除了命令行界面 (CLI) 外，最流行的机制之一是安装编辑器插件，例如 Visual Studio Code 扩展程序，它会在每次保存文件时运行 linter。
其他机制如此处所述的 Git 预提交钩子。
对于JetBrains的IDE（IntelliJ IDEA PhpStorm WebStorm PyCharm RubyMine AppCode CLion Gogland DataGrip Rider Android Studio），有一个AWS CloudFormation插件，支持对JSON和YAML CFN模板进行深度检查。
"Parameters" : {
"SingleGroup": { "Type": "AWS::EC2::SecurityGroup::Id", ...},
"GroupList": {"Type": "List<AWS::EC2::SecurityGroup::Id>", ...}
}
--disable-rollback和cfn-signal的好处？ - Chris Halcrow