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

GAMEOPS02-BP01 采用多账户策略，将不同的游戏和应用程序隔离到自己的账户中

设计一个能够指导基础设施部署的客户结构，使其符合每个环境的安全、隔离和运营需求。通过限制对环境的访问并只允许在其中使用必需的 AWS 服务来隔离环境至关重要，因为生产环境处于封锁状态，而开发和测试环境则宽松，允许进行实验。强烈建议进一步隔离每个环境中的主要子系统，并将多个环境使用的公共服务 AWS 账户 单独托管和管理。

在未建立这种最佳实践的情况下暴露的风险等级：高

实施指导

采用多账户策略，将不同的环境（例如开发、测试、暂存、生产和共享服务）隔离给个人 AWS 账户，从而缩小事件的范围。 AWS 考虑 AWS Organizations 集中管理您的层次结构 AWS 账户 以进一步简化操作，并有选择地定义和应用账户级别和组织单位级（OU 级别）的策略。通过设计符合您的开发和生产工作流程需求的适当组织单位和 AWS 账户 结构，您可以优化成本并增强可扩展性。

实施步骤

中部署的游戏系统 AWS 应使用多个经过逻辑组织的帐户，以提供适当的隔离，从而缩小问题的爆发半径并随着游戏基础设施的扩展而简化操作。 AWS 账户 主机游戏基础架构通常分为以下逻辑环境：

对于开启的游戏基础架构 AWS，建议为每个游戏环境（开发、测试、暂存和生产）创建单独的帐户，以及用于安全、日志记录和中央共享服务的帐户。

通常，管理有限数量的基础架构资源（通常为几百台或更少的服务器）的小型游戏开发工作室可能会 AWS 账户 为每种环境创建一个服务器（例如，一个制作账户、一个开发账户和一个暂存账户）。但是，随着游戏基础设施或团队规模的增长，这种简化的模型可能无法很好地扩展。

在设置这些环境时，请考虑许多 AWS 服务在特定区域内共享整个账户的资源和 API 级服务配额。在确定如何对账户进行逻辑组织时，必须考虑这一点。 AWS 账户 只会因使用部署到其中的服务而产生成本。因此，这提供了一种有效减少资源争用和服务配额的方法，尤其是在您的游戏不断发展以及越来越多的开发者需要访问权限来构建和管理资源的情况下。

根据我们与大型游戏开发工作室合作的经验，这些工作室通常运营着数千台服务器，数百名开发者访问资源，我们建议您设计一个更精细的账户结构，让支持您的游戏的各个应用程序拥有自己的开发、测试、暂存和制作帐户。由于规划和迁移实时系统的复杂性，在游戏启动后重新设计 AWS 多账户策略既困难又耗时，因此在确定正确的多账户结构时，请考虑未来的扩展需求。 

您可以使用AWS Organizations设置层次结构和分组 AWS 账户，并定义组织单位（OUs），以便通过服务控制策略（）将常见的 OU 级别策略应用于它们。SCPs AWS Organizations 随着资源的增长和扩展，集中管理和治理您的环境。您可以通过编程方式创建新账户并分配资源，对账户进行分组以组织工作流程，将策略应用于账户或群组进行管理，并通过对账户使用单一付款方式来简化账单。此外，Organizations 还与其他服务集成，因此您可以定义组织中各个账户的中央配置、安全机制、审计要求和资源共享。

AWS Control Tower提供了一种设置和管理安全的多账户环境（称为 landing zon e）的简单方法。Control Tower 使用创建您的着陆区 AWS Organizations，带来持续的账户管理和治理，以及基于与成千上 AWS万客户迁移到云端的过程中合作的经验实施最佳实践。 AWS ConfigAWS Trusted Advisor、和AWS Security Hub CSPM是提供账户卫生状况的汇总或集中视图的服务。

这种隔离可帮助您为每个游戏环境设置自定义或个人权限和护栏。生产账户应具有必要的护栏、访问限制、监控和警报以及安全工具，而非生产账户可能不需要相同级别的护栏和权限。非生产环境可以自动化，以便在下班后关闭资源并节省成本。在这种精细度级别上进行账户分离可以直接监控每个支持游戏的环境的基础架构成本。

以下是游戏公司的多账户结构示例，该结构使用 AWS Organizations 和组织单位 (OUs) 在逻辑上 AWS 账户 分组为不同的环境和工作室。在此示例中， OUs 用于根据账户的环境，然后根据运营环境的工作室对账户进行分组。这演示了如何创建嵌套层次结构，以允许将单独的应用程序和游戏部署到其环境中各自的账户中（描绘为 OUs），如果您开发和运营多个游戏，这将非常有用。请参阅本支柱资源部分提供的文档和白皮书，了解在组织多账户策略时可以考虑的其他策略。

根据上面的讨论，下面的示例图假设游戏工作室（组织）的开发管道由 4 个阶段（开发、测试、试运行和制作）组成。对于给定的游戏 (game1)，每个环境 (OU) 都有单独 AWS 账户 的游戏服务、专用游戏服务器、社交服务和网络服务器。每个子系统中运行的资源 AWS 账户 都与相应的子系统相关。通常，使用这种开发管道的每款游戏都会为其复制这种或类似的结构 AWS 账户。

除了这些以游戏为中心的环境外 OUs，还有共享服务 OU 和安全 OU。这些 OUs 应该是整个组织的，而不是针对每个单独的游戏。这样，游戏就会消耗开发工具、数据和分析的共享服务，如本例所示。然后，将应用程序和系统日志发送到安全 OU 中的日志 AWS 账户 设置。