【发布时间】：2019-08-01 22:48:09
【问题描述】：
人们在决定编写 1 个大型 CF 模板还是嵌套许多较小的 CF 模板时会考虑哪些因素？我想到的用例是基于 RDS 的，我需要定义 RDS 实例、VPC 安全组、参数和选项组以及执行一些自定义 lambda 资源。
我的直觉是这应该分开，也许是按资源类型，但我想知道这方面是否有普遍接受的做法。
【问题讨论】：
【发布时间】：2019-08-01 22:48:09
【问题描述】：
我当前的设置需要部署 VPC（带端点）、RDS 和应用程序（API 网关、Lambda）。我将它们分解为
- VPC 堆栈：一个共享资源，每个区域有 1 个 VPC，具有公有和私有子网、VPC 终端节点、S3 存储桶、NAT 网关、ACL、安全组。
- RDS 堆栈：我可以在一个 VPC 中拥有多个 RDS 集群，因此将其分开是有意义的。此外，这是在 VPC 之后创建的，因为它需要私有子网、安全组等 VPC 资源。此集群由多个应用程序堆栈共享。
- 应用程序堆栈：这会部署 API 网关和 Lambda（基本上是一个无服务器应用程序），并将上述 RDS 集群作为数据库。
所以，总的来说，我几乎遵循@Milan Cermak 所描述的内容。但就我而言，这些部署是在需要时完成的（不是 CD 的一部分），因此 exported 参数存储在 AWS Systems Manager 的参数存储中。
【讨论】：
-
将导出的参数存储到系统管理器中也是我正在尝试的事情。很高兴看到其他人也在使用这种方法。
-
感谢系统管理员的指点。现在可能对我的需求没有用，但将来绝对值得考虑。
我目前的经验法则是按部署单元划分资源 - 一起部署，一起部署。
我希望拥有最小的可部署堆栈，因为它可以快速部署或在出现问题时失败。我不虔诚地遵守这条规则。例如，我经常将 Lambda 组合在一起（即使是不相关的，取决于项目的大小），因为它们仅在代码/配置更改时才会更新，而且我倾向于推送只有一个 Lambda 更改的小更新。
我还经常有一堆共享资源（Fn::Import-ed）在其他堆栈中使用，例如 KMS 密钥、共享 S3 存储桶等。
请注意，我为每个堆栈设置了一个 CD 进程，因此是规则。
【讨论】：
-
这很有帮助，谢谢，尤其是关于部署方法与共享资源的评论。