来源: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
此示例包含的代码作为为大型基础设施构建 Terraform 配置的示例，该基础设施使用：
2个AWS账户
2个地区
2 个独立的环境（prod 和 stage 什么都不共享）。 每个环境都位于一个单独的 AWS 账户中，并跨越 2 个区域之间的资源
每个环境都使用来自 Terraform Registry 的不同版本的现成基础设施模块 (alb)
每个环境都使用相同版本的内部模块modules/network，因为它来自本地目录
在此处描述的大型项目中，使用 Terragrunt 的好处变得非常明显。请参阅Code Structures examples with Terragrunt。
非常适合基础设施在逻辑上分离的项目（单独的 AWS 账户）
适合不需要修改 AWS 账户之间共享的资源（一个环境 = 一个 AWS 账户 = 一个状态文件）
适合不需要编排环境之间的变化
适合基础设施资源因环境而异且无法一概而论时（例如，在一个环境或某些地区缺少某些资源）
随着项目的增长，让这些环境彼此保持最新状态将变得更加困难。 考虑使用基础设施模块（现成的或内部的）来完成可重复的任务。
来源: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
此示例包含的代码作为为小型基础设施构建 Terraform 配置的示例，其中不使用外部依赖项。
非常适合入门和按需重构
非常适合小型资源模块
适用于小型和线性基础设施模块（例如，terraform-aws-atlantis）
适用于少量资源（少于 20-30）
如果资源数量不断增加，所有资源的单一状态文件会使使用 Terraform 的过程变慢（考虑使用参数 -target 来限制资源数量）
来源: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
此示例包含的代码作为为中型基础设施构建 Terraform 配置的示例，该基础设施使用：
2个AWS账户
2 个独立的环境 (prod 和 stage 什么都不共享)，每个环境都位于一个单独的 AWS 账户中
每个环境都使用来自 Terraform Registry 的不同版本的现成基础设施模块 (alb)
每个环境都使用相同版本的内部模块modules/network，因为它来自本地目录
非常适合基础设施在逻辑上分离的项目（单独的 AWS 账户）
适合不需要修改 AWS 账户之间共享的资源（一个环境 = 一个 AWS 账户 = 一个状态文件）
适合不需要编排环境之间的变化
适合基础设施资源因环境而异且无法一概而论时（例如，在一个环境或某些地区缺少某些资源）
随着项目的增长，让这些环境彼此保持最新状态将变得更加困难。考虑使用基础设施模块（现成的或内部的）来完成可重复的任务。
这些示例显示的是 AWS 提供商，但示例中显示的大部分原则可以应用于其他公共云提供商以及其他类型的提供商（DNS、DB、监控等）。
很少资源，没有外部依赖。 单个 AWS 账户。 单一区域。 单一环境。
Yes
多个 AWS 账户和环境，使用 Terraform 的现成基础设施模块。
Yes
许多 AWS 账户，许多地区，迫切需要减少复制粘贴、自定义基础设施模块、大量使用组合。 使用Terraform。
WIP 生产中
very-large
多个提供商（AWS、GCP、Azure）。 多云部署。 使用Terraform。
No
medium
多个 AWS 账户和环境，现成的基础设施模块，使用 Terragrunt 的组合模式。
No
large
许多 AWS 账户，许多地区，迫切需要减少复制粘贴、自定义基础设施模块、大量使用组合。 使用 Terragrunt。
No
very-large
多个提供商（AWS、GCP、Azure）。 多云部署。 使用 Terragrunt。
No