对于那些不知道 AWS Organization 服务的人:AWS Organization 允许您创建新的 AWS 账户并从您用于创建它们的账户(主账户)中集中管理这些账户。

每个账户都有自己的账户 ID、资源和资源限制,就像您可能从 AWS 获得的任何其他账户一样。

组织服务(在主账户中)也可用于在层次结构中组织这些账户,并对特定账户或组织层次结构的部分设置限制和策略。

本文将帮助您提出如何将工作负载分配到不同 AWS 账户的基本原理。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--4HyTv0q1--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/i/pqgccvs574vkpim9yopc.png)

在上图中,您可以看到一个示例帐户结构,分为 3 个组织单位(development、shared 和 production)。可以将任意数量的帐户添加到这些组织单位。组织结构可能比上述复杂得多,一些公司使用它来管理 500 多个帐户。

使用多个帐户有很多好处:

• 数据治理:将数据存储在不同的帐户中可以轻松控制谁可以访问哪些数据。例如,考虑 GDPR 管理的数据:通过仅向需要访问的人提供访问权限,很容易保持_- 并证明您是-_ 控制权。

• 安全边界:安全控制(例如 IAM 权限)通常仅适用于特定类型的资源。为这些资源创建和维护特定权限可能是一项艰巨的任务。通过将更多关键资源移动到不同的帐户,您可以将这些控制应用于整个帐户(或帐户组)。有关更多信息,请阅读:服务控制策略

• 可扩展性:如果您有多个开发团队在同一个 AWS 账户上工作,您可能会更快地遇到 AWS 服务限制。示例:一个账户中最多可以包含 100 个存储桶。如果每个团队都有自己的 AWS 账户,那么每个团队就有 100 个存储桶。此外,团队将能够在需要时就可以移除哪些存储桶做出正确的决定。

• 有限的爆炸半径:每隔一段时间,更改可能会带来不必要的副作用。限制这些副作用就是我们所说的限制爆炸半径。驻留在同一帐户中的资源更有可能相互混淆或在技术上相互影响。将您的系统划分为多个帐户会大大减少您的爆炸半径。

• 成本监控:AWS 组织内的所有账户都计入包含该组织的账户。但是,您得到的是对每个帐户花费的分析(无需进行标记!)。通过这种方式,您可以精确监控特定开发团队或系统的支出,并为这些账户设置预算警报。

即使您没有大量帐户,将开发帐户与生产帐户分开可能仍然有意义。以正确的方式开始有助于您在未来发展并保持对 AWS 资源的控制。

跨账户资源访问

我们刚刚了解了设置多帐户的好处。不过,特别是硬安全边界也有一个缺点:当跨账户访问资源时,您现在明确需要允许其他账户访问这些资源。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--Z8gMGAvx--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/i/s63uk4fe13owwfqrlzhd.png)

在此示例中,账户 B 允许账户 A 访问资源

• 在左侧看到identity policy:大多数使用 AWS 的开发人员都知道这是他们作为用户承担的角色或分配给 lambda 或其他可执行文件的角色。此身份策略需要包含账户 B 中资源的完整 ARN。

• 在右侧,您会看到资源还有一个策略:resource policy。所有资源都有一个资源策略,该策略指定允许谁访问该资源。默认情况下,资源策略允许从同一账户内访问,但为了跨账户边界访问资源两个策略都需要允许访问。

有关 IAM 策略和权限的更多信息,请参见:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

提出多账户策略

我们了解到,拥有多个账户可以帮助我们控制 AWS 资源,但也有缺点。因此,重要的是要提出何时将资源分成不同账户的理由。

开发生产账户

将开发资源与生产资源分开是有意义的:

1. 在开发新功能时,您不想意外影响生产系统。

2. 您的生产系统可能包含机密或 GDPR 管理的数据,默认情况下您不希望向开发人员公开这些数据。

通过将开发和生产帐户拆分到不同的组织单位,您将能够:创建防止表在生产中被删除的策略、限制对数据的访问或在开发人员访问生产资源时通知管理员(打破玻璃角色)。

每个团队的开发帐户

在开发 OU 中创建开发账户时,每个团队有 1 个 AWS 账户是有意义的。这样,团队成员可以拥有广泛的权限,修复他们在自己的帐户中遇到的任何限制或问题,并且不会妨碍其他开发团队。

每个系统的生产帐户

在创建生产帐户时,请尝试围绕(子)系统设计这些资源,其中资源高度依赖于彼此,并且可能需要一起更改和部署。就像设计微服务一样。当在这些系统之间存在依赖关系时,您可以使用 API Gateway 和 HTTP 端点作为解耦这些服务的通用方式。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--GZ2G8JsA--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev -to-uploads.s3.amazonaws.com/i/ct8y6vg7v9r6j443j82w.png)

对于只应在您的组织内公开的 API Gateway 端点,您还可以使用资源策略。同样,调用者身份和 API 网关资源策略都需要允许访问。为了使其正常工作,调用者需要向 HTTP 请求添加 AWS V4 签名。

共享账户

将资源存储在共享帐户中也有不同的动机。下面的一些例子:

共享服务帐户

包含可重用的功能/服务/资源。

益处:

• 将您重复使用的资源存储在一个中心位置可以更轻松地管理这些资源。

审核记录帐户

包含 Cloudtrail、Config 和 GuardDuty 等服务的集中式日志记录。

益处:

• 存储审计日志使其易于访问。

• 对审计日志的访问也可能仅限于您的安全官等角色。

应用程序登录帐户

包含所有应用程序的集中式日志记录和指标数据。

益处:

• 存储所有应用程序功能的日志记录和指标可以轻松访问、关联和转发日志。

• 一个设置警报和提醒值班开发运维工程师的地方。

用户帐户

包含 IAM 用户或与 SSO 解决方案的集成。

益处:

• 通过拥有一个包含所有用户的帐户,可以轻松控制允许您的用户承担的 IAM 角色。

安全帐户

包含密码、api 密钥、证书、公钥等。

益处:

• 集中存储机密可让您在需要时轻松轮换机密。

• 拥有存储这些机密的特定帐户可以限制访问。示例:可能仅允许您的安全官访问此帐户。

使用 IaC 管理您的 AWS 组织

AWS 提供了多种解决方案来设置 AWS 组织(Landing Zones、Landing Zones V2 和 AWS Control Tower)。这些解决方案的共同点是,它们允许您创建 AWS 组织和账户结构,以及使用账户工厂或账户自动售货机预置 AWS 资源的基线。但是,这些服务都不允许您使用基础设施即代码(也称为 IaC)来管理您的 AWS 组织。但是,开源托管工具 AWS Organization Formation(或 org-formation)可以。

组织形成允许您将 AWS 组织的定义置于源代码控制之下,并创建一个自动化流程来应用更改。自动化对您的 AWS 组织进行更改的过程可以消除手动工作、不一致和错误。自动化构建基础架构还允许您实施保护措施,例如对更改进行同行评审。

看看:https://github.com/OlafConijn/AwsOrganizationFormation

欢迎问题、星号、拉取请求和示例! <3