本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
为全球扩张制定战略
调查
我们很乐意听取你的意见。请通过简短的调查
AWS
在全球扩张 AWS 时，安全保障服务
以下问题很常见，只有您可以根据自己的用例回答这些问题：
-
我客户的个人数据需要存放在哪里？
-
我的客户数据存储在哪里？
-
个人数据如何以及在何处跨境？
-
跨区域的人或服务访问数据是否构成传输？
-
我怎样才能确保没有外国政府访问我客户的个人数据？
-
我可以在哪里存储我的备份以及热点或冷站点？
-
为了将数据保存在本地，我是否应该在我提供服务的每个区域都有一个 AWS 着陆区？ 或者我可以使用现有的 AWS Control Tower 着陆区？
对于数据驻留要求，不同的架构部署可能更适合不同的组织。有些组织可能要求其客户的个人数据保留在特定区域内。如果是这样，您可能会担心如何在履行这些义务的同时普遍遵守法规。无论情况如何，在选择多账户部署策略时都需要考虑多个因素。
要定义关键的架构设计组件，请与您的合规和合同团队密切合作，以确认个人数据在何处、何时以及如何交叉的要求 AWS 区域。确定哪些内容符合数据传输条件，例如移动、复制或查看。此外，了解是否必须实施特定的弹性和数据保护控制措施。备份和灾难恢复策略是否需要跨区域故障转移？ 如果是，请确定您可以使用哪些区域来存储备份数据。确定是否对数据加密有任何要求，例如用于生成密钥的特定加密算法或专用硬件安全模块。在与合规利益相关者就这些主题达成一致后，开始考虑针对您的多账户环境的设计方法。
以下是您可以用来规划 AWS 多账户策略的三种方法，按基础设施隔离的升序排列：
同样重要的是要记住，隐私合规可能不仅限于数据主权。查看本指南的其余部分，了解应对许多其他挑战的可能解决方案，例如同意管理、数据主体的请求、数据治理和人工智能偏见。
带有托管区域的中央着陆区
如果您想在全球范围内扩张，但已经在中建立了多账户架构 AWS，那么通常需要使用相同的多账户着陆区 (MALZ) 来管理其他账户。 AWS 区域在此配置中，您将继续从您创建登录区域的现有 AWS Control Tower 着陆区（Landing zone）运营基础设施服务，例如日志记录、账户工厂和一般管理。
对于生产工作负载，您可以通过将 landing zone 扩展到新区域来操作区域部署。 AWS Control Tower 通过这样做，您可以将 AWS Control Tower 治理范围扩展到新的区域。这样，您就可以将个人数据存储在特定的托管区域内，数据仍存储在受益于基础设施服务和 AWS Control Tower 治理的账户中。在中 AWS Organizations，包含个人数据的帐户仍会汇总到专门的个人数据OU下，其中所有数据主权保护措施 AWS Control Tower 都在那里实施。此外，特定于区域的工作负载包含在专用账户中，而不是在多个区域建立可能包含相同工作负载的生产账户。
这种部署可能是最具成本效益的，但要控制跨区域的个人数据流动 AWS 账户 ，还需要考虑其他因素。请考虑以下事项：
-
日志可能包含个人数据，因此可能需要进行一些额外的配置来包含或编辑敏感字段，以防止在聚合期间进行跨区域传输。有关控制跨区域日志聚合的更多信息和推荐做法，请参阅本指南集中式日志存储中的。
-
在 AWS Transit Gateway 设计中考虑隔离 VPCs 和适当的双向网络流量。您可以限制允许和批准哪些 Transit Gateway 附件，也可以限制谁或什么可以更改 VPC 路由表。
-
您可能需要阻止云运营团队成员访问个人数据。例如，包含客户事务数据的应用程序日志可能被认为比其他日志源具有更高的敏感性。可能需要额外的批准和技术护栏，例如基于角色的访问控制和基于属性的访问控制。此外，在访问方面，数据可能会受到居住限制的约束。例如，一个区域 A 中的数据只能从该区域内访问。
下图显示了带有区域部署的集中式着陆区。
区域着陆区
与非物质工作负载相比，拥有多个 MALZ 可以完全隔离处理个人数据的工作负载，从而帮助您实现更严格的合规要求。 AWS Control Tower 默认情况下可以配置集中式日志聚合，因此可以简化。使用这种方法，您无需为使用需要编辑的单独日志流进行日志记录而保留异常。您甚至可以为每个 MALZ 设立一个专门的本地云运营团队，这限制了运营商访问本地驻留的机会。
许多组织分别部署了位于美国和欧盟的 landing zone。每个区域 landing zone 都有单一的、全面的安全态势和对区域内账户的相关管理。例如，在一个 MALZ 的工作负载中 HSMs 可能不需要使用专用加密个人数据，但在另一个 MALZ 中可能需要使用专用加密功能。
尽管此策略可以扩展以满足当前和未来的许多需求，但重要的是要了解与维护多个策略相关的额外成本和运营开销 MALZs。有关更多信息，请参阅AWS Control Tower 定价
下图显示了两个区域中不同的着陆区。
AWS 欧洲主权云
一些组织要求将其在欧洲经济区 (EEA) 运营的工作量与在其他地方运营的工作量彻底分开。在这种情况下，可以考虑AWS 欧洲主权云
AWS 欧洲主权云在物理和逻辑上都与现有云分开 AWS 区域，同时提供相同的安全性、可用性和性能。只有位于欧盟的 AWS 员工才能控制 AWS 欧洲主权云的运营和支持。如果您有严格的数据驻留要求， AWS 欧洲主权云会将您创建的所有元数据（例如角色、权限、资源标签和他们用来运行的配置 AWS）保留在欧盟。 AWS 欧洲主权云还具有自己的计费和使用量计量系统。
对于这种方法，您将使用与上一节 “区域着陆区” 中类似的模式。但是，对于您向欧洲客户提供的服务，您可以在 AWS 欧洲主权云中部署专用的MALZ。
