2. AWS全球基础设施与区域选择策略

多区域高可用设计的第一步，不是画架构图，而是把 AWS 全球基础设施的层级关系搞清楚。AWS 把计算、存储、网络和边缘能力组织成若干不同粒度的“位置”，每一层的故障域、延迟特征、可用服务和计费方式都不同。选错层级，后面的多活、容灾、合规设计都会建立在错误的地基上。

一、五类基础设施位置的特性

区域（Region）是最高层级的地理隔离单元，例如 us-east-1、ap-southeast-1、eu-central-1。每个区域由 3 个或更多可用区（Availability Zone, AZ）组成，AZ 之间通过低延迟、高带宽的冗余光纤互联，物理上彼此独立供电、独立制冷，因此单个 AZ 故障不会连带影响同区域其他 AZ。AZ 是“同区域内高可用”的基本单位：把两台实例放在同一区域的不同 AZ，就获得了 AZ 级容错；而区域之间天然隔离，是“跨地理容灾”的单位。

边缘位置（Edge Location / Point of Presence）数量最多，全球超过 400 个。它不运行 EC2 或 RDS，主要承载 CloudFront 内容分发、Route 53 权威 DNS、AWS Global Accelerator 的接入点以及 Shield 边缘防护。边缘位置的价值在于把静态内容和 DNS 解析推到离用户最近的地方，降低首字节时间，但它不能作为业务数据的持久化落点。

本地区域（Local Zone）是区域的延伸，把计算、存储、部分网络服务部署到离大城市更近的位置，通常与父区域保持个位数毫秒级延迟。它适合对本地延迟极敏感、又需要与父区域保持数据同步的场景，例如实时游戏服务器、视频转码、医疗影像处理。Local Zone 的可用服务是区域服务的子集，选型时必须先确认目标实例族和存储类型是否在该 Local Zone 提供。

波长区域（Wavelength Zone）把 AWS 计算和存储嵌入到 5G 运营商的网络边缘，流量不必先绕回区域即可在运营商网络内完成处理。它面向超低延迟的移动场景，如车联网、AR/VR、直播互动。Wavelength 的实例类型和存储选项更受限，且通常与特定运营商绑定，属于“场景专用”而非通用选址。

二、基于延迟的选址方法

延迟选址的核心是回答“用户到哪个区域最近”。AWS 提供两种可量化的手段：一是用 CloudWatch 合成监控或第三方探针从目标城市持续测量到候选区域的 RTT；二是用 Route 53 延迟路由让 DNS 自动把用户导向延迟最低的区域。实际工程中，通常先做一轮测量，再决定主区域和灾备区域。

假设目标用户分布在新加坡、雅加达、曼谷三地，候选区域为 ap-southeast-1（新加坡）、ap-southeast-3（雅加达）、ap-southeast-7（曼谷）。用合成监控从三地各取 100 次 TCP 握手 RTT 中位数，可能得到类似结果（以下为示例假设数据，非实测）：

从表可见，没有单一区域对三地都最优。若业务允许，可采用“主区域 + 延迟路由”把三地分别导向最近区域；若必须单主，则选 ap-southeast-1，因为它的最差延迟（19 ms）在三者中最小，属于“最小最大延迟”策略。这就是延迟选址的基本判断逻辑：先量化，再按业务容忍度选择单主、双主或多主。

三、合规与服务可用性约束

合规往往是一票否决项。金融、医疗、政务类业务常要求数据驻留（Data Residency）在特定国家或地区，此时可选区域被压缩到该国境内或该主权范围内的区域。例如要求数据不出印尼，就只能选 ap-southeast-3；要求数据留在欧盟，则候选为 eu-central-1、eu-west-1、eu-west-2 等。合规还会影响备份、日志、密钥的存放位置，KMS 密钥、S3 存储桶、CloudTrail 日志都必须与数据同区域或同主权范围。

服务可用性是第二个硬约束。新区域或 Local Zone 往往不提供全部实例族、全部存储类型或全部托管服务。例如某些 GPU 实例、特定 RDS 引擎版本、SageMaker 特定功能可能只在部分区域上线。选址前应逐项核对：目标计算实例族、数据库引擎、消息队列、AI 服务是否在候选区域提供。若关键服务缺失，要么换区域，要么调整架构（例如用自建替代托管服务）。

四、成本维度与综合决策

区域之间的价格差异真实存在。同一实例族在不同区域的小时价可能相差 10%～30%，S3 存储单价、跨区域数据传输费、NAT 网关处理费也各不相同。多区域架构还会引入额外的跨区复制流量费、跨区请求费和重复的固定成本（如每个区域的 NAT 网关、负载均衡器、KMS 密钥）。因此选址不能只看“离用户近”，还要算总拥有成本。