AWS AWS Control Tower 着陆区的多账户策略 - AWS Control Tower
与 AWS 多账户指南保持一致建立架构良好的环境的指导方针具有完整多账户 OU 结构的 AWS Control Tower 示例关于 Root

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

AWS AWS Control Tower 着陆区的多账户策略

AWS Control Tower 客户经常寻求有关如何设置 AWS 环境和账户以获得最佳效果的指导。AWS 创建了一组统一的建议，称为多账户策略，以帮助您充分利用自己的 AWS 资源，包括 AWS Control Tower 着陆区。

从本质上讲，AWS Control Tower 充当与其他 AWS 服务配合使用的编排层，这些服务可帮助您实施针对 AWS 账户和的多 AWS 账户建议。 AWS Organizations在您的着陆区设置完毕后，AWS Control Tower 将继续协助您在多个账户和工作负载中维护您的公司策略和安全实践。

大多数着陆区会随着时间的推移而发展。随着 AWS Control Tower 着陆区中组织单位 (OU) 和账户数量的增加，您可以通过有助于有效组织工作负载的方式扩展 AWS Control Tower 的部署。本章提供规范性指导，说明如何根据 AWS 多账户策略规划和设置您的 AWS Control Tower 着陆区，并随着时间的推移对其进行扩展。

有关组织单位最佳做法的一般性讨论，请参阅组织单位的最佳实践 AWS Organizations。

AWS 多账户策略：最佳实践指南

AWS 架构良好的环境的最佳实践建议您将资源和工作负载分成多个 AWS 账户。您可以将 AWS 账户视为独立的资源容器：它们提供工作负载分类，并在出现问题时缩小爆炸半径。

AWS 账户的定义

AWS 账户充当资源容器和资源隔离边界。

注意

AWS 账户与通过联邦或 AWS Identity and Access Management (IAM) 设置的用户账户不同。

关于 AWS 账户的更多信息

AWS 账户可以隔离资源并遏制 AWS 工作负载面临的安全威胁。账户还提供了一种计费和工作负载环境管理机制。

该 AWS 账户是为您的工作负载提供资源容器的主要实现机制。如果您的环境架构良好，则可以有效地管理多个 AWS 帐户，从而管理多个工作负载和环境。

AWS Control Tower 设置了一个架构良好的环境。它依赖于 AWS 账户以及账户 AWS Organizations，这些账户可以帮助管理可能跨多个账户的环境更改。

架构良好的环境的定义

AWS 将架构良好的环境定义为以 landing zone 开头的环境。

AWS Control Tower 提供了一个自动设置的着陆区。它会对环境中的多个账户实施控制措施，以确保遵守您的公司指导方针。

着陆区的定义

landing zone 是一个云环境，它提供了一个推荐的起点，包括默认账户、账户结构、网络和安全布局等。在 landing zone 中，您可以部署利用您的解决方案和应用程序的工作负载。

建立架构良好的环境的指导方针

以下各节将介绍架构良好的环境的三个关键组成部分是：

  • 多个 AWS 账户

  • 多个组织单位 (OU)

  • 精心策划的结构

使用多个 AWS 账户

一个账户不足以搭建一个架构良好的环境。通过使用多个帐户，您可以最好地支持您的安全目标和业务流程。以下是使用多账户方法的一些好处：

  • 安全控制-应用程序具有不同的安全配置文件，因此它们需要不同的控制策略和机制。例如，与审计师交谈并指向托管支付卡行业 (PCI) 工作负载的单一账户要容易得多。

  • 隔离：账户是安全保护的单位。可以在不影响其他人的情况下将潜在的风险和安全威胁控制在一个账户中。因此，出于安全考虑，您可能需要将账户彼此隔离开来。例如，您的团队可能具有不同的安全配置文件。

  • 许多团队 — 团队有不同的职责和资源需求。通过设置多个帐户，团队不会像使用同一个帐户时那样互相干扰。

  • 数据隔离-将数据存储隔离到一个帐户有助于限制有权访问数据并可以管理数据存储的人数。这种隔离有助于防止未经授权泄露高度私密的数据。例如，数据隔离有助于支持对《通用数据保护条例》(GDPR) 的遵守。

  • 业务流程 — 业务部门或产品通常具有完全不同的目的和流程。可以建立个人账户来满足企业的特定需求。

  • 账单 — 账户是在账单级别分开项目的唯一途径，包括转账费用等。多账户策略有助于跨业务部门、职能团队或个人用户创建单独的可计费项目。

  • 配额分配 — AWS 配额是按账户设置的。将工作负载分成不同的账户可以为每个账户（例如项目）提供明确的个人配额。

使用多个组织单位

AWS Control Tower 和其他账户编排框架可以进行跨账户界限的更改。因此， AWS 最佳实践涉及跨账户变更，这可能会破坏环境或破坏其安全性。在某些情况下，变更可能影响整体环境，而不仅仅是政策。因此，我们建议您至少设置两个必备账户，即制作和暂存账户。

此外，出于管理和控制的目的， AWS 账户通常被分组为组织单位 (OU)。OU 旨在跨多个账户执行策略。

我们的建议是，您至少要创建一个不同于生产环境的预生产（或暂存）环境，并具有不同的控制和策略。生产和暂存环境可以作为单独的 OU 创建和管理，并按单独的账户计费。此外，您可能还需要设置沙盒 OU 来进行代码测试。

在 landing zone 中为 OU 使用精心策划的结构

AWS Control Tower 会自动为您设置一些 OU。随着您的工作负载和需求随着时间的推移而扩大，您可以扩展原始的 landing zone 配置以满足您的需求。

注意

示例中给出的名称遵循设置多账户 AWS 环境的建议 AWS 命名约定。在设置了着陆区后，您可以通过在 OU 详情页面上选择 “编辑” 来重命名 OU。

建议

在 AWS Control Tower 为您设置了第一个必需的 OU（安全 OU）之后，我们建议在您的着陆区再创建一些组织单元。

我们建议您允许 AWS Control Tower 再创建至少一个名为沙盒组织单元。此 OU 适用于您的软件开发环境。如果您选择沙盒组织单元，AWS Control Tower 可以在创建着陆区期间为您设置沙盒 OU。

您可以自己设置另外两个推荐的 OU：基础架构 OU，用于包含您的共享服务和网络帐户，以及一个用于包含生产工作负载的 OU，称为工作负载 OU。您可以通过组织单位页面上的 AWS Control Tower 控制台在着陆区域中添加其他 OU。

除了自动设置的 OU 之外，推荐的 OU

  • 基础架构 OU — 包含您的共享服务和网络帐户。

    注意

    AWS Control Tower 不会为您设置基础设施 OU。

  • Sandbox OU — 软件开发 OU。例如，它可能有固定的支出限额，或者可能未连接到生产网络。

    注意

    AWS Control Tower 建议您设置沙盒 OU，但它是可选的。它可以在配置 landing zone 时自动设置。

  • 工作负载 OU-包含运行您的工作负载的帐户。

    注意

    AWS Control Tower 不会为您设置工作负载组织单位。

有关更多信息，请参阅 AWS Control Tower 的生产入门组织。

具有完整多账户 OU 结构的 AWS Control Tower 示例

AWS Control Tower 支持嵌套的 OU 层次结构，这意味着您可以创建满足组织要求的分层 OU 结构。您可以根据 AWS 多账户策略指南构建一个 AWS Control Tower 环境。

您还可以构建一个更简单、更扁平的 OU 结构，该结构性能良好，并且符合 AWS 多账户指南。仅仅因为您可以构建分层 OU 结构，并不意味着必须这样做。

链接页面上的图表显示已创建了更多基础 OU 和更多 OU。这些 OU 可以满足更大规模部署的额外需求。

在 “基础 OU” 列中，在基本结构中添加了两个 OU：

  • Security_Prod OU — 为安全策略提供只读区域以及漏洞安全审计区域。

  • 基础设施 OU — 您可能希望将之前建议的基础架构 OU 分成两个 OU，即 Infrastructure_Test（用于预生产基础架构）和 Infrastructure_Prod（用于生产基础架构）。

在 “其他 OU” 区域中，基本结构中又添加了几个 OU。以下是随着环境的发展，建议创建的下一个OU：

  • 工作负载 OU — 以前推荐但可选的工作负载 OU 已分为两个 OU，即 Workloads_Test（用于预生产工作负载）和 Workloads_Prod（用于生产工作负载）。

  • PolicyStaging OU — 允许系统管理员在完全应用控制和策略之前对其进行测试。

  • 已暂停的 OU — 为可能已被暂时禁用的帐户提供位置。

关于 Root

根不是 OU。它是管理账户以及组织中所有 OU 和账户的容器。从概念上讲，根包含所有 OU。它无法删除。在 AWS Control Tower 中，您无法在根级别管理已注册的账户。取而代之的是管理 OU 中的已注册账户。有关有用的图表，请参阅 AWS Organizations 文档。