我想知道将所有 IAM 角色和策略放入嵌套堆栈中的一个模板中以使它们更易于维护是否更有意义，或者是否好的做法是说无论出于何种原因这是相当有害的，并将策略放在创建资源的特定模板中。哪种方式更好。为了良好的秩序，我会使用 ONE 模板，因为这个想法似乎没问题。如能分享这方面的经验，我将不胜感激。
梅西·
我们最近使用云形成对整个 AWS 基础设施进行了模板化。而且，我会使 IAM 角色和策略更接近应用程序堆栈，而不是在一个模板中。我会试着解释我的理由。
我们为每个TeamEnv都有一个单独的AWS账户。
What is a TeamEnv?
如果我们有 3 个团队，例如 A、B 和 C。 以及 3 种环境，例如开发、暂存和生产。
然后我们有9个TeamEnv：A-Dev，A-Staging，A-Prod等，适用于其他团队。因此，我们总共有 9 个 AWS 账户。这样做是为了设定问责制和资源的透明度。
而且，这就是我们是如何做到的。我们将堆栈分为以下几类：
常见的 AWS Cloudformation 堆栈
TeamEnv 特定的 AWS Cloudformation Stacks
常见的 AWS Cloudformation堆栈：这些是所有团队及其环境通用的堆栈：
IAM 子用户账户堆栈- 此堆栈创建具有管理员访问权限的IAM 子账户。
通用 VPC堆栈 - 此堆栈根据公司的标准创建 VPC 及其组件。
VPC 对等堆栈- 此堆栈用于对等 VPC。
VPC 对等角色堆栈- 此堆栈创建对等所需的 VPC 角色。
特定于团队的堆栈：
ELB堆栈 - 它依赖于通用 VPC堆栈，并从中导入导出的值，如VPCId。
服务特定堆栈- 它依赖于通用 VPC堆栈和ELB 堆栈，并导入各种导出值。 我们为每个微服务提供一个堆栈，它包含将服务带入就绪状态所需的一切。它包括 s3 存储桶、SQS、实例角色等。
这就是我们管理 IAM 角色和策略的地方。它更易于管理和审核。
但是，事后看来，我会为 IAM 策略保留一个单独的堆栈，这些策略在其他角色中常用和引用，以避免重复的内联策略。