AWS 多区域高可用架构图

AWS 多区域架构图应该画什么:Route 53 故障转移、可用区、复制方向,以及 active-active 与 active-passive 的区别。

2026/10/16

AWS 多区域高可用架构图

大多数 AWS 多区域架构图都以同样的方式失败:两个一模一样的方框,分别标着 us-east-1 和 eu-west-1,并排放着,中间什么都没有。看起来像高可用,但评审人或值班工程师会问的问题,它一个都回答不了。写入去哪里?数据往哪个方向复制?某个区域出问题时,是什么在切换流量,又由谁或什么来决定?本文讲清楚这张图必须展示什么、active-active 与 active-passive 在图上有何不同,以及如何从一个免费示例出发在 Archboard 里把它画出来。

AWS 多区域架构图必须展示什么

按照请求经过的顺序,从上往下读这张图。

1. 全局入口:Route 53 与 CloudFront

  • Amazon Route 53 位于两个区域之上,而不是放在其中一个区域里。把路由策略写在连线标签上:failover(与 health check 关联的主、备记录)、latency-based(把每个用户送到延迟最低的区域)或 weighted。health check 也要画出来,没有它,故障转移路由就不起作用。
  • Amazon CloudFront 位于各区域源站的前面。如果使用带 origin failover 的 origin group,要把两个源站都画出来,并标明哪个是主源站。CloudFront 的 origin failover 适用于 GET、HEAD 和 OPTIONS 请求,写入请求需要单独的路径。

2. 区域入口:Application Load Balancer

ALB 是区域级资源,覆盖你为它启用的各个 Availability Zone。每个区域画一个,放在区域边界内,目标至少分布在两个可用区。

3. 跨可用区的计算层

无论运行应用的是 Amazon ECS 服务、Amazon EKS 节点组还是 EC2 Auto Scaling 组,都画成分布在两到三个可用区框架中。这张图要讲清楚一点:可用区故障在区域内消化,区域故障由全局层消化。

4. 数据层:一定要有箭头

大多数架构图在这里都沉默了。每种数据存储都有自己的复制模型,箭头方向就是全部信息。

服务 复制模型 图上要画什么
Aurora Global Database 一个主(写入)区域,若干只读次要区域,存储层异步复制 主 → 次的单向箭头,以及提升步骤(switchover 或 failover)
DynamoDB global tables 多活:每个副本表都接受写入 双向箭头,并注明冲突规则(默认模式下最后写入者胜出)
S3 Cross-Region Replication 异步,按复制规则定义;源桶和目标桶都必须启用版本控制 每条规则一个箭头;双向复制需要两条规则

再加一条注释:S3 复制规则只作用于新对象,规则创建前已存在的对象需要 S3 Batch Replication。一定会有人问。

5. 密钥与配置

AWS Secrets Manager 可以把密钥复制到其他区域,AWS KMS 支持多区域密钥。Systems Manager Parameter Store 是区域级的。把每个区域从哪里读取密钥和配置画出来。如果应用在切换后无法解密数据库密码,那就不算真正的故障转移。

6. 可观测性与控制平面

展示由什么检测故障、由什么采取行动:Route 53 health check、各区域的 CloudWatch 告警、合成监控 canary,以及跨区域仪表盘。如果故障转移由 Amazon Application Recovery Controller(ARC)的 routing control 或 runbook 触发,也要画到图上。AWS Well-Architected 可靠性支柱 建议在恢复过程中依赖数据平面操作,而不是控制平面变更。基于 health check 的 DNS 故障转移属于前者,而架构图正是说明你依赖哪一种的合适位置。

active-active 与 active-passive

AWS 描述了四种灾难恢复策略。其中三种会在第二个区域运行某些组件,每一种都会改变图上需要表达的内容。

策略 平时的第二区域 RTO / RPO(定性) 图上必须展示什么
Backup and restore 只有备份,没有运行中的基础设施 恢复时间最长;数据丢失取决于备份频率 备份复制方向和重建步骤
Pilot light 数据持续复制;核心基础设施已预置,应用计算关闭或缩容到零 数据丢失少;因为计算需要启动并扩容,恢复较慢 复制箭头、标为关闭的备用计算、扩容步骤
Warm standby 规模缩小但功能完整、可以承接流量的副本 数据丢失少;只需扩容而非从零启动,恢复更快 每个区域的最小容量、health check、扩容步骤
Multi-site active-active 两个区域同时承接生产流量 恢复最快;数据丢失取决于数据模型和冲突处理 路由策略、每个数据存储的写入归属、冲突解决方式

具体数字由你们自己定。把 RTO 和 RPO 目标写在画布上、策略旁边,这样图和业务要求就可以相互核对。

active-active 并不天然更好。它去掉了提升步骤,却要求你决定每个数据存储如何处理并发写入。Aurora Global Database 同一时间只有一个区域可以写入,因此基于它构建的 active-active 设计仍然只有一个写入区域。请如实画出来。

把故障转移路径画明白

使用三种连线样式,并在图例中说明:

  • 请求路径:实线箭头,从用户经过 DNS、CDN、ALB 到计算层。
  • 复制:数据存储之间的虚线箭头,标明方向和模式(async、multi-active)。
  • 故障转移:一条单独的、带标签的路径,说明主区域不健康时流量去往哪里。

然后在画布上的注释里给故障转移步骤编号:

1. Route 53 health check on primary ALB fails
2. Route 53 failover record answers with the secondary region
3. Aurora secondary cluster is promoted to writer (global database failover)
4. ECS service / Auto Scaling group in the secondary region scales out
5. Alarms confirm traffic and error rates in the secondary region

如果某一步需要手动操作,写明由谁执行;如果某一步依赖控制平面 API,做好标记。

常见错误

  • 同一个区域画两遍,却没有数据流。 没有复制箭头的两份相同技术栈,说明不了任何恢复能力。
  • 隐藏控制平面。 故障转移是否发生,由 health check、routing control 和 runbook 决定。漏掉它们,图上描述的就是一个无法故障转移的系统。
  • 没有故障转移箭头。 正常运行时的请求路径只是故事的一半。
  • 把全局服务画在区域里。 Route 53 和 CloudFront 是全局服务;放进某个区域框架,会暗示一个并不存在的依赖,或掩盖一个真实存在的依赖。
  • 没有可用区。 区域级冗余不能替代可用区级冗余,两者都要画。
  • 遗漏状态。 缓存、队列和会话存储同样是区域级的。标出它们在哪里,以及故障时会发生什么。

在 Archboard 中构建

在 Archboard 中,你可以用 Cloud 和 Network 节点包中的节点来构建这张图:这些是带端口的一等节点,用 AWS 服务名称作标签,因此每个方框既能体现角色,也能标明具体服务。构建步骤如下。

  1. 研究免费模板。 打开 /examples/multi-region-cloud-ha。它展示了跨区域的 CDN、双区域负载均衡器、计算资源和托管数据库。以它为参考,或通过使用此示例把它复制到你的工作区,然后加上前面介绍的各个层次。
  2. 创建区域和可用区边界。 添加两个 Cloud 包的 Region 框架,分别标为 us-east-1 (primary) 和 eu-west-1 (secondary)。在每个区域内,用 Core 的 Frame 元素表示可用区。
  3. 在区域上方放置全局层。 用 Network 包的 Internet 表示用户,Network 包的 DNS 标为 Route 53 (failover routing),Cloud 包的 CDN 标为 CloudFront。
  4. 填充每个区域。 Cloud 包的 Cloud LB 标为 ALB;每个可用区框架里放 Compute 节点,标为 ECS service 或 EC2 Auto Scaling group(EKS 可用 Kubernetes Cluster 节点);Managed DB 节点分别标为 Aurora (writer) 和 Aurora (secondary, read-only),再加一个用于 DynamoDB global table;Object Storage 标为 S3。
  5. 连接端口并给每条连线加标签。 请求路径、复制方向与模式、故障转移路径。用连线标签写明路由策略和复制类型。
  6. 加入控制平面和注释。 用 Core 的 Box 节点表示 Secrets Manager、CloudWatch 和 health check;用一个 Note 写编号的故障转移步骤;用一个 Markdown 块写 RTO、RPO 目标和所选策略。
AWS 多区域架构图:us-east-1 为主区域,eu-west-1 为备用区域,每个区域都有 ALB、分布在两个可用区的 ECS 服务、Aurora、DynamoDB 和 S3,区域之间有复制箭头,并附有故障转移步骤说明。

22 个组件 · 21 个连接

在 Archboard 中打开
图表内容
  • Users
  • CloudFront
  • Route 53 · failover routing
  • us-east-1 (primary)
  • us-east-1a
  • us-east-1b
  • ALB
  • ECS service
  • Aurora (writer)
  • DynamoDB global table
  • S3
  • eu-west-1 (secondary)
  • eu-west-1a
  • eu-west-1b
  • Aurora (secondary, read-only)
  • exports
  • HTTPS
  • DNS
  • origin · primary
  • failover · secondary
  • Global Database · async
  • global tables · multi-active
  • Cross-Region Replication
双区域 AWS 高可用:前端是 CloudFront 和 Route 53 故障转移,每个区域有 ALB 和跨两个可用区的 ECS,并配有 Aurora Global Database、DynamoDB 全局表和 S3 复制。

开始之前先数一数节点数量:完整的双区域地图通常会超过 Free 计划每张图 15 个图表节点的额度(便签和文本另行计算,最多 150 个),因此 Pro 是自然的选择,它提供无限节点、嵌入文档站点和 PDF 导出。更多模式请参见云使用场景页面。

常见问题

可以在 Archboard 中使用 AWS 官方图标吗? Archboard 的类型化 Cloud 和 Network 节点与厂商无关,但你可以用 Core 的 Icon 节点搜索 Iconify(例如 logos:aws-route53)来添加 AWS logo,也可以把官方的 AWS Architecture Icons 作为图片上传。给每个节点标上 AWS 服务名称,例如 Route 53 或 Aurora Global Database,熟悉 AWS 的人都能一眼看懂这张图。

区域和可用区都要画吗? 要。可用区说明你如何扛过单个可用区故障,区域说明你如何扛过区域级故障。这是不同的故障模式,对应不同的机制。

选 active-active 还是 active-passive? 从 RTO、RPO 目标和数据模型出发。如果主数据库只有一个写入区域,active-passive(pilot light 或 warm standby)往往是更简单、也更符合实际的设计。把决定写在图上。

如何分享? 导出 SVG 或 PNG(Free 计划带水印),分享公开链接,或在 Pro 计划中嵌入到你的文档里。

免费开始 — 1 个席位,无需信用卡

相关文章

← 返回博客

一分钟打开画布

使用 Google 或 GitHub 登录。单席位免费,团队加入后再升级。