为金融服务企业启用新的 AWS 区域

金融服务机构 (FSI)，包括银行、支付处理商、资本市场公司和全球保险公司，通常在一个 AWS 区域开始他们的云之旅。他们通常选择离其主要业务最近的区域。随着时间的推移，他们在基础之上建立了多层复杂性：治理框架、安全控制、网络架构、身份联合和合规证据管道，所有这些都调整到一个区域。然后触发器到了。监管机构、运营弹性授权或数据驻留规则迫使他们进入新的 AWS 区域，时间表是由监管机构而不是企业制定的。《数字运营弹性法案》（DORA）要求欧盟金融实体证明跨区域故障转移。Ring-fencing 规则要求受监管实体将关键银行数据保存在司法管辖范围内，从而强制进行数据隔离。跨境银行法规定了客户数据的存放位置。对于这些机构来说，启用新区域并不是一个绿地建设。它正在按照监管截止日期复制成熟、受管控的环境，同时涉及治理、安全、身份、网络、DNS、计算、运营和每个应用程序团队。

金融服务版本更难，原因有两个：审查和排序。错过控制不是错误；这是审计师或主管会举报的发现。拒绝策略、多区域日志记录和加密策略都必须在第一个工作负载到达之前，而不是之后。这项工作也井然有序：治理门安全、安全门户网络、网络门户 DNS。错过序列就会停滞几个星期。本博客提供了一个结构化框架，介绍了每个工作流、治理、安全、网络、DNS、计算、CI/CD 和运营，展示了哪些阻碍了哪些内容以及团队可以在何处并行工作。

在本博客中，我们提供了以从业者为中心的指南，介绍如何在金融服务企业 AWS 环境中启用新的 AWS 区域。我们将详细介绍每个工作流程，从最初的治理批准到网络、安全、运营和工作负载就绪，重点介绍团队遇到的注意事项、依赖关系和常见陷阱。我们还将关键监管要求与架构决策对应起来，以便您的团队可以将合规义务追溯到特定的实施选择。本指南适用于云基础工程团队、云架构师和金融服务领域的基础设施负责人。它可以帮助这些团队规划和执行区域扩张，同时满足监管部门的期望。

每个企业环境都不一样。这个博客不是规范性的。它是一个结构化的考虑框架。

治理和规划

在任何技术工作开始之前，区域扩张通常必须经过组织的治理流程。此流程因客户而异，但通常从架构审查委员会 (ARB) 批准开始。你需要提交一份正式请求，记录业务理由，从预算和风险授权的角度来看，这为所有后续工作提供了保障。

在流程的早期，您应该让利益相关者了解 “区域支持” 对您的组织意味着什么。启用是否仅意味着网络连接和控制平面扩展？它是否包括部署日志基础设施等共享服务？提早设置此定义可防止以后出现范围歧义。

服务可用性是另一个关键的验证步骤。并非所有的 AWS 服务在每个地区都可用。在承诺使用某个区域之前，请验证您的工作负载所依赖的服务是否在该区域可用。使用 AWS 区域服务清单作为起点。服务内部的可用性也有所不同。验证目标区域是否提供您的工作负载所需的亚马逊弹性计算云 (Amazon EC2) 实例系列，包括相关的处理器架构和生成。

必须尽早解决监管和数据驻留要求。有关任何监管影响，请咨询您的合规团队。HIPAA、GDPR、GxP 等要求或支付处理器的 PCI DSS 等行业特定要求限制了数据的存放位置、处理方式或某些服务是否需要额外的控制。例如，一些跨国组织在 A WS IAM 身份中心使用不透明的标识符而不是电子邮件地址。这种方法可以帮助根据特定司法管辖区的数据保护规则保护个人身份信息（PII）。

合规文档

如果您的组织在受监管的行业中运营，则向新地区扩张可能会触发合规文件要求。使用 AWS Artifact 访问涵盖新区域的合规性报告和认证，例如 SOC 1/2/3、PCI DSS、ISO 27001 和 HIPAA。并非所有合规计划都同时涵盖所有地区，因此请确认您的组织所依赖的认证明确包括目标地区。

如果您的合规团队维护分担责任矩阵或客户责任证据包，请对其进行更新以反映新的地区。审计师可能会要求提供证据，证明控制措施在所有范围内都得到了一致的应用。还要检查目标地区的合规性要求。相关义务可能包括通用数据保护条例、PCI DSS 范围扩大、GovCloud 的 FedRAMP 以及国别法规，例如 BaFin、MAS 或 FSA。

确保将您的审计和证据收集流程（无论是自动还是手动）配置为从第一天起就从新地区采集合规证据。

成本管理和可见性

扩展到新区域会引入新的成本维度，需要从一开始就对其进行跟踪和管理。验证您的成本分配标签是否已应用于新区域中的资源。如果成本归因依赖于 CostCenter、BusinessUnit 或 Environment 等标签，请通过标签政策强制执行这些标签。将这些政策纳入新地区的账户基准中。

创建或更新 AWS 预算以纳入新区域。考虑针对特定地区的预算，以追踪上涨成本并发现意外支出。添加异常警报，因为初始部署期间的意外支出可能表示配置错误或资源失控。

如果您使用 AWS 成本和使用情况报告 (CUR)，请验证报告管道是否包含新区域。查看亚马逊雅典娜查询、亚马逊 QuickSight 控制面板和任何第三方成本工具。CUR 是账户级别的，确实包括所有区域，但您的下游分析可能会按地区过滤，需要更新。

区域之间的数据传输会产生费用。常见驱动因素包括 AWS Transit Gateway 对等互连、亚马逊简单存储服务 (Amazon S3) 复制、亚马逊关系数据库服务 (Amazon RDS) 复制、亚马逊 DynamoDB 全局表和亚马逊 CloudWatch 日志转发。流向非本地 VPC 终端节点的流量可能会进一步增加成本。

有关多区域数据传输成本和架构模式的详细概述，请参阅 AWS 多区域功能参考。

如果您使用储蓄计划或预留实例，请检查您的现有承诺是否适用于新区域。计算节省计划可以灵活地跨区域，但是 EC2 实例节省计划和预留实例是特定区域的。您可能需要为新地区购买额外的承诺或调整您的承保策略。

为新区域启用 AWS 成本异常检测，以便尽早发现意外支出模式，尤其是在使用模式尚未确立的初始部署阶段。

控制和安全

核心优先事项是确保您的安全和合规状况扩展到新区域。这必须在部署工作负载之前发生，在没有可见性的情况下部署基础架构是一种重大风险。

组织政策

如果您使用 AWS 控制塔区域拒绝控制或自定义服务控制策略 (SCP)，请对其进行更新以包括新区域。确认只有经批准的区域才能访问。不仅要查看区域拒绝列表，还要查看任何引用特定区域的亚马逊资源名称 (ARN) 或资源标识符的 SCP。同样，请查看所有资源控制策略 (RCP) 以了解特定区域的限制，例如允许的区域列表、终端节点限制或资源级条件，这些限制需要更新以包括新区域。如果您不使用控制塔，则仍应通过自定义 SCP 实现区域级护栏，以防止在新区域中创建不受控制的资源。对于首次向新地区扩张的组织来说，这是采用控制塔或建立同等治理控制措施的机会。

审核您的 AWS 身份和访问管理 (IAM) 政策、权限边界和权限集，以获取资源 ARN 中硬编码的区域引用。尽管这在架构完善的环境中并不常见，但在实践中确实会发生，并且会静默地阻止新区域中的操作。

>提示：在启用之前，使用资产清单或云安全态势管理 (CSPM) 工具扫描特定地区的策略限制。示例包括 AWS 安全中心、AWS 配置和 AWS 系统管理器清单。

可见性和威胁检测

确认您在 AWS CloudTrail 中的组织跟踪已配置为多区域跟踪。如果是，则自动覆盖新区域。如果不是，则必须在更改启用该区域的 SCP 之前解决这个问题。在没有 CloudTrail 可见性的区域中运营会导致您的审计记录中出现漏洞，监管机构和内部安全团队将予以标记。

确认在新区域中启用 AWS 安全中心云安全状态管理 (CSPM)。亚马逊 GuardDuty、亚马逊 Inspector 和 Amazon Macie 是区域性服务。在新区域中启用和配置每项服务，并将其与现有的委派管理员账户集成。确保您的 AWS Config 资源记录器包含新区域，以便配置合规性评估涵盖部署在那里的资源。

第三方安全工具

验证第三方安全产品是否监控新区域并从中生成调查结果。示例包括 Palo Alto Prisma Cloud、Wiz 和 Orca。通知负责监控、检测和事件响应的安全运营中心 (SOC)。在您启动工作负载之前，请团队在新区域验证其工具。

如果您的环境依赖诸如带有性能复制集群的 HashiCorp Vault、CrowdStrike、Tanium 或 Qualys 之类的工具，请验证它们是否可以在新区域运行或可以到达新区域。

加密和密钥管理

查看您对多区域 AWS 密钥管理服务 (AWS KMS) 密钥的使用情况。如果新区域中的工作负载需要解密在其他区域加密的数据，例如用于跨区域备份恢复，则需要复制多区域密钥。

请注意，AWS 管理的密钥（由 AWS 服务自动创建的密钥）不能创建为多区域。如果您的工作负载目前依赖 AWS 管理的密钥进行加密，则需要迁移到客户管理的密钥 (CMK) 以启用跨区域解密。尽早规划此迁移，因为使用新的 CMK 重新加密现有数据可能很耗时，并且需要与应用程序团队进行协调。

一些组织要求 AWS CloudHSM 提供加密密钥材料所有权，并要求 FIPS 140-2 第 3 级合规性超出 KMS 提供的范围。CloudHSM 集群是区域性的。当工作负载需要本地加密操作或无法容忍远程集群延迟时，在目标区域创建集群。

如果您运营私有证书颁发机构 (CA) 基础设施，请决定新地区是否需要本地证书颁发。这适用于 AWS 私有 CA、基于 AWS Lambda 的发行工作流程以及与 DigiCert 等提供商的集成。评估证书颁发延迟和部署量。还要考虑短期证书轮换，以及灾难恢复模式是否需要在每个地区独立颁发。

账户出售和引导

无论您使用哪种账户自动售货解决方案，都必须对其进行更新以支持新区域。如果您使用适用于 Terraform 的账户工厂 (AFT)，请查看特定区域的 Terraform 提供商的账户自定义、特定区域的资源和 Jinja 模板迭代。如果您的全局自定义引用特定区域的资源，例如单个区域中的日志目标 ARN，则需要对这些资源进行参数化。

对于 Landing Zone Accelerator (LZA)，更新 global-config.yaml 或 accounts-config.yaml 以包括新区域。请注意，跨区域创建堆栈可能需要几个小时或更长时间，具体取决于账户数量和资源时间。如果您使用 AWS 控制塔自定义 (CFCT) 或自定义解决方案，请为您的工具应用等效的区域配置更新。

资源命名

Amazon S3 存储桶名称在全球范围内是唯一的。如果账户基准为访问日志或流日志创建存储桶，请在每个名称中包含区域标识符或其他唯一后缀。例如：alb-access-logs-111222333444-us-west-2。

组织结构

确定您的组织单位 (OU) 设计是否需要适应基于区域或基于地理位置的细分。一些组织在 OU 级别按地区划分工作负载，以在每个地理位置应用不同的 SCP，例如，欧盟和美国的数据处理控制措施不同。如果您现在运营的是单一工作负载 OU，则添加具有不同合规性要求的区域可能需要进行结构性更改。

如果 AWS 资源访问管理器 (AWS RAM) 在 OU 级别共享子网、传输网关或前缀列表，请查看这些共享。添加任何需要访问权限的新 OU。

联网

网络通常是区域扩展中最复杂、最耗时的工作流程。它涉及 IP 地址管理、混合连接、防火墙部署、DNS 等。

IP 地址规划

确定如何根据贵组织的 IP 地址管理 (IPAM) 计划为新区域分配 IP 地址空间。该方法取决于您现有的分配和连接模型。

如果已将大型连续超网分配给云使用，则将其细分为新区域。例如，从现有的 /10 或 /12 中分割区域配额。您不一定需要申请全新的配额。从现有的云超网中雕刻出一个区域区块，通常是 /12、/14 或 /16。将其分配给新区域的 Transit Gateway 或 AWS Cloud WAN 分段。

如果您使用的是 AWS Transit Gateway 对等互连，则每个区域的连续和可汇总范围很重要。Transit Gateway 对等互连使用静态路由，因此需要将每个区域的地址空间作为汇总路由通告给对等方。AWS Direct Connect Gateway (DXGW) 通过 IPv4 和 IPv6 的传输虚拟接口公布多达 100 个前缀。路由汇总可帮助多区域和多数据中心环境保持在此限制之内。如果公布的前缀超过 100，BGP 会话将进入空闲状态并撤回路由，AWS 不会自动通知您。因此，建议对公布的前缀数量发出警报。本地路由基础设施还受益于高效、可汇总的路由表。

如果您使用的是 AWS 云广域网，则会放宽连续性要求。Cloud WAN 动态处理分段之间的路由，不像 Transit Gateway 对等互连那样依赖静态对等路由。为了便于操作，您仍然需要干净、不重叠的地址空间，但是在分配地址方面有更大的灵活性。这是云广域网在多区域环境中的实际优势之一。Cloud WAN 不需要可汇总的路由。当组织缺少足够大以进行 /12、/14 或 /16 区域分配的连续超网时，这使得它很有用。

无论您的连接模式如何，如果您计划在本地或云地址空间之间路由流量，则新区域的 CIDR 范围都不得与现有的本地或云地址空间重叠。

>提示：使用 Amazon VPC IPAM 来集中规划、跟踪和审计您跨区域和账户的 IP 地址分配。这在区域扩张期间尤其有价值，因为在区域扩张中，地址空间分散可能会成为长期的运营负担。

混合连接

如果您在新地区或附近有数据中心并且需要专用连接，请尽早订购 AWS Direct Connect 连接。对于受监管的大型组织，配置可能需要几个月的时间，具体取决于内部流程、位置和提供商。该组织的网络团队将需要配置本地边界路由器，例如 Cisco ASR。他们还必须更新核心路由。

直接连接网关 (DXGW) 是一种全球架构。评估您现有的 DXGW 是否可以为新地区提供服务，或者是否需要新的区域。注意每个 Direct Connect 网关有六个中转网关的限制（默认、不可调整的配额，用于控制 DXGW 可以提供多少中转网关联）。增加并不总是得到批准，因为这些是共享的基础设施资源。

公交连接

对于基于 AWS Transit 网关的环境，请在您的集中式联网账户的新区域中创建一个新的传输网关。与现有的区域交通网关建立公交网关对等并配置静态路由。规划和创建对等连接的变更请求。

对于基于 AWS 云广域网的环境，Cloud WAN 可显著简化多区域连接，因为它专为全球网络管理而设计。添加新的区域分段在操作上通常不如公交网关对等互连那么复杂。如果使用检查，请为新区域配置网络功能组和服务插入。

共享 VPC 和检查

在新区域中创建所需的共享 VPC。这些通常包括终端节点 VPC、互联网入口 VPC 和带有 NAT 网关或第三方设备的互联网出口 VPC。此外，还要为第三方连接创建任何 DMZ vPC。

部署 AWS 网络防火墙或第三方防火墙设备进行东西向和南北向流量检查。确保对防火墙规则集进行审查和调整，以适应新地区的网络范围。如果使用集中式 VPC 终端节点，请在新区域中创建它们。

新区域引入了新的弹性 IP 地址 (EIP)。与维护出口 IP 允许列表的第三方和客户共享。如果您使用自带 IP (BYOIP)，请相应地规划地址分配。

为新区域的网络范围创建托管前缀列表，并确保通过 AWS RAM 将其共享给相应的 OU 和账户。如果您的组织使用 SD-WAN 进行分支机构或制造站点连接，请与您的网络团队进行协调。Cloud WAN 的无隧道通用路由封装 (GRE) 功能可以简化这一点，但仍需要规划。

DNS

DNS 通常是区域扩展中影响最大、最容易出错的方面。配置错误会导致成千上万的现有工作负载无法访问。

解析器基础架构

在新区域创建 Amazon Route 53 Resolver 入站和出站终端节点，或者利用 Route 53 配置文件，这些配置文件还解决 VPC 终端节点 DNS 解析问题。配置本地 DNS 基础设施，例如 BlueCat、Infoblox 或 Active Directory 条件转发器，以正确识别和路由新区域的查询。

命名规范

建立支持多区域操作的 DNS 命名规范。这对于运营一致性和自动化至关重要，必须在内部达成共识。常见模式包括以区域为前缀的命名，例如 us-west-2.prod.aws.customer.cloud，以服务为前缀的命名，例如 payments.us-west-2.aws.customer.cloud，或以环境为前缀的命名，例如 prod.eu-west-1.customer.cloud。

以前的单区域组织可能会使用诸如 app.customer.cloud 之类的固定名称。添加区域组件需要对共享基础设施和应用程序进行协调更改。

>严重：DNS 配置错误会使整个队列脱机。在生产变更之前进行彻底测试。

托管区域

为新区域确定您的 DNS 权限模型。您是否使用具有 VPC 关联的 Route 53 私有托管区域？您是否使用具有 NS 记录委托的公共托管区域？您是否通过转发规则将所有 DNS 转发给本地解析器，例如 BlueCat 或 Infoblox？

每种模型对添加新区域都有不同的含义。使用 Route 53 私有托管区域，您需要将新区域的 VPC 与现有区域关联起来，并考虑是否需要更新基于延迟或故障转移的路由策略。使用公共托管区域和 NS 委托，您可能需要为特定区域的终端节点分配新的子域名。使用本地转发时，您需要为新区域的 DNS 终端节点添加转发规则，并确保本地条件转发器能够识别新区域。无论采用哪种型号，在部署工作负载之前，都要确保新区域的 VPC 与正确的托管区域相关联，并且该分辨率端到端有效。

计算和映像管理

亚马逊系统映像 (AMI) 是区域资源。您计划在新地区部署的任何应用程序或服务都需要其 AMI 在该地区可用。如果您运营自定义映像工厂，请将其构建管道扩展到新区域，或者复制并验证那里的现有 AMI。映像应包含相同的强化操作系统配置和所需的安全代理。此处之所以称安全代理，是因为它们通常嵌入在所有工作负载共享的基础映像中，因此它们是任何部署的先决条件。

如果您通过映像共享账户跨账户共享 AMI 或使用 AMI 允许列表，请更新新区域的这些配置。常见方法包括使用集中式映像共享账户将 AMI 复制到每个区域并与工作负载账户共享，或者在部署时使用跨区域 AMI 副本。集中式方法提供了更好的治理和可审计性，而跨区域复制对于小型组织来说更简单。无论您使用哪种型号，都要确保目标区域中有 AMI 加密密钥。

CI/CD 和部署工具

如果您在 AWS 上使用自托管的 CI/CD 基础设施，请考虑在新区域部署运行器。跨区域部署延迟会增加 Ansible 剧本和其他部署脚本的执行时间。这对于数据驻留也很重要，因为某些监管框架可能会限制在处理敏感配置数据时部署自动化的执行位置。

查看您的 AWS CloudFormation 模板和 Terraform 模块，了解硬编码的区域参考信息、特定区域的资源限制或有关单区域运营的假设。查看基础设施即代码验证规则，了解可能拒绝新区域的特定区域检查。这包括开放策略代理（OPA）、HashiCorp Sentinel 和自定义扫描管道。

操作和可观察性

日志集中化

如果 Amazon CloudWatch 订阅筛选条件为集中式日志管道提供信息，请验证其区域资源是否存在于新区域。这些资源可能包括 Amazon Data Firehose、Amazon Kinesis 数据流和 AWS Lambda 转换。CloudWatch 日志组、订阅过滤器和 Firehose 交付流都是区域资源。

验证 VPC 流量日志、Amazon RDS 日志和 Amazon S3 访问日志是否已配置为从新区域运送到正确的集中目的地。确认 AWS CloudTrail 日志和 Amazon GuardDuty 调查结果已路由到日志存档账户中的集中式 Amazon S3 存储桶。

如果您使用 Splunk、Datadog、Dynatrace 或类似的第三方日志提取工具，请确定您当前的设置是从新区域提取日志还是需要本地部署。还要确定是否需要将其放大以处理额外的音量。

>建议：与其在每个地区部署日志基础设施，例如 Splunk 重型转发器或聚合器，不如考虑将日志存储集中在 Amazon S3 中并从单个位置提取日志。这降低了成本和运营复杂性。如果需要，您可以随时对摄取层进行故障转移。

监控和警报

CloudWatch 警报是区域性的。在新区域中复制标准警报配置，包括 CPU、磁盘和应用程序运行状况警报。还要重新创建亚马逊简单通知服务（亚马逊 SNS）集成、AWS Lambda 自动修复和 ServiceNow 票证工作流程。更新集中式 CloudWatch 仪表板或第三方监控仪表板，以纳入新区域的指标。

备份和灾难恢复

AWS 备份计划和保管库是区域性的。验证您在备份账户中的集中式备份保管库在新区域中是否有相应的保管库。确保配置备份计划以保护新区域中的资源，并确保在灾难恢复策略需要时配置跨区域备份复制规则。

标记

在部署资源之前更新 AWS 组织标签政策。例如，将新位置添加到 CountryCode 标签的允许值中。不这样做将导致标记失败，进而导致账单、成本分配和合规性报告缺口。

操作工具

将所需的配置数据复制到新区域。这可能包括 AWS 系统管理器参数存储参数、AWS 密钥管理器密钥以及本地所需或低延迟的 HashiCorp 保管库数据。与区域无关的参数（例如全局特征标志）可能不需要复制，但任何引用区域终端节点、ARN 或环境特定值的参数都需要复制。验证您的 IT 服务管理 (ITSM) 和配置管理数据库 (CMDB) 工具是否会自动发现新区域中的资源，或手动对其进行更新。

服务配额

当您在单一区域运营时，您的 AWS 服务配额可能会随着时间的推移而调整，随着工作负载的增加，通过支持案例增加。新区域以默认配额开始，这些默认配额可能不足以满足您的计划部署。

审核现有区域的配额增加情况，并将其与默认区域进行比较。使用服务配额 API 操作列表服务配额和获取服务配额来自动清点清单。常见示例包括亚马逊 EC2 vCPU 限制、弹性 IP 地址限制和亚马逊 VPC 限制。还要查看 AWS Lambda 并发性、亚马逊 RDS 实例、AWS KMS 密钥以及 Elastic Load Balancing 监听器和目标群组。

新区域主动增加申请量。不要等到部署失败。在部署工作负载之前，使用服务配额控制台或 API 请求增加新区域的配额。有些配额增加是自动批准的，但其他一些则需要人工审查，可能需要几天时间。

>提示：您可以使用 AWS 服务配额 API 在组织层面创建配额申请模板，这可以简化跨多个账户的这一流程。

请注意，有些配额是针对每个区域的每个账户的，例如 EC2 vCPU 限制，而另一些配额是针对每个账户的全球配额，例如 IAM 角色的数量。了解哪些配额需要针对特定地区进行增加。

特别注意直接连接和网络配额。默认情况下，一个 DXGW 支持六个 Transit Gateway 附件，但由于这些资源依赖于共享基础架构，因此增加并不总是获得批准的。还要考虑 DXGW 允许的前缀，每个 DXGW 的上限为 100 个，每个 VPC 的 VPC 终端节点以及每个区域的 Route 53 解析器终端节点。这些网络配额可能特别有影响力，在规划过程中经常被忽视。

操作顺序

许多工作流可以并行进行。例如，AMI 映像工厂工作可以与网络一起运行，安全工具可以在 SCP 更新后继续运行。其他任务有硬依赖关系。监管必须先于 SCP 变更，网络必须在 DNS 配置之前运行。在 CI/CD 运行器运行之前，DNS 必须进行解析。在部署工作负载之前验证所有先决条件。以下是推荐的高级序列：

-获得预算分配和风险授权的治理批准。同时，验证服务和实例类型的可用性，以确认该区域适用于您的工作负载。

-在通过 SCP 和 RCP 更新启用该区域之前，请验证 AWS CloudTrail。然后启用亚马逊 GuardDuty、AWS 安全中心、亚马逊检查器、第三方安全工具和 SOC 通知。

-更新着陆区和账户基准工具，例如 AFT、LZA 或自定义工具。

-在制定账户基准的同时，规划 CIDR 分配，并在需要时订购 Direct Connect。部署传输网关或云广域网连接、共享 VPC、VPC 终端节点、防火墙和出口堆栈。

-在联网正常运行后配置 DNS。

-扩展 AMI 映像工厂（可以与联网并行进行）。

-在联网和 DNS 完成后部署 CI/CD 运行器。

-配置操作和可观察性，包括日志管道、监控、备份和标记。

-验证上述所有内容后，启用账户自动售货和工作负载部署。

结论

每个环境都不一样，但金融服务的工作类别保持一致。按依赖顺序完成治理、控制、账户基准化、联网、DNS、计算、CI/CD 和运营。这降低了发射风险，并有助于从第一天起履行监管义务。

要使该框架发挥作用，请采取以下后续步骤。

-开展依赖关系映射练习：汇集云基础、网络、安全和运营负责人。映射可以并行运行的顺序拦截器和工作流。

-创建您的区域扩展操作手册：使用本指南作为框架，在其中填写您的工具、命名规范、CIDR 分配和合规性要求，并为每个域分配所有者。

-验证当前状态的准备情况：在启用新区域之前，审核您现有的多区域设置，包括 AWS CloudTrail、SCP 和服务配额。在此步骤中，团队会发现他们已经运行的区域存在差距。

-与您的 AWS 账户团队合作：您的解决方案架构师可以帮助评估区域准备情况，确定服务可用性差距，并将您与 AWS 网络和安全专家联系起来。

我们看到的最常见的错误是将区域支持视为一个团队的项目。成功的组织将区域支持作为一项跨职能计划运行。他们使用一个负责任的所有者、一个共享的依赖关系跟踪器和每周一次的协调会议，直到工作负载上线。有条不紊的区域扩张可增强弹性并缩小爆炸半径。它还使组织有信心满足监管要求并在更接近客户所在地的地方为客户提供服务。