這篇整理 Aurora Global Database 的適用條件、它的 region failover 與 cross-AZ failover 在 RTO 上的數量級差、合規邊界，以及它跟 Aurora DSQL / Spanner / CockroachDB 之間怎麼選。storage-level replication 的機制在 Aurora storage architecture，單 region 內的 failover 在 Aurora cross-AZ failover RTO。

Aurora Global Database 是 跨 region async replication、< 1 秒 typical lag、最多 5 個 secondary region，看起來是 multi-region OLTP 的標準解；Standard Chartered 揭露一個受監管產業的 anti-recommendation：合規禁止跨境複製的場景下，Global Database 違反合規，要改用每市場獨立 cluster + 應用層市場切換。

問題情境

典型觸發場景：global SaaS / 跨地理金融服務、需要 region-level DR（us-east-1 整 region 失效時 < 5 分鐘恢復寫入）、或跨地理 read（歐洲用戶查美國 primary 延遲 100ms+ 不可接受）、但又不到「multi-region active-active write」需求。

讀者常見的具體疑問：

• 「Global Database 是 sync 還是 async？lag 多少？」
• 「Secondary region 可以寫嗎？」
• 「Region failover 流程跟 cross-AZ 一樣嗎？」
• 「跟 Aurora DSQL / Spanner / CockroachDB 怎麼選？」
• 「合規場景一定要用 Global Database 嗎？」

進一步問題：Global Database 對一般 SaaS 是合理的 DR + 跨地理 read 工具、但對 受監管產業 是反指標。Standard Chartered 7 個受監管市場、各自獨立 Aurora cluster、不用 Global Database — 成因是合規要求「資料不能跨境複製」，而不是技術不夠。讀者規劃 multi-region 架構時、合規維度要在技術維度之前判斷。

核心機制：跨 region async storage replication

Aurora Global Database 的 first-class concept 是 跨 region storage-level async replication。跟 logical replication / streaming replication 不同、Global Database 在 storage layer 複製、lag 上限相對穩定。

Architecture：

• Primary region：1 個 writer cluster + N read replica
• Secondary region：最多 5 個 secondary region、每 region N 個 reader-only cluster（最多 16 個 reader 含 1 個 headless）
• Storage replication：primary region 寫 storage 後 async push 到 secondary region storage、不等 ack

Write path：

1Application
2    ↓ writer endpoint (primary region only)
3Primary region compute
4    ↓ redo log
5Primary region storage (4-of-6 quorum)
6    ↓ async replication (typical < 1 秒)
7Secondary region storage

Read path：

• Secondary region 直接從 local storage 讀、不需要跨 region 拉
• Read latency 是 secondary region local latency、不是跨 region

DR 切換 RTO 跟 cross-AZ 對比：

數量級不同 — cross-AZ 是 seconds、cross-region planned 是 minutes、unplanned 是 5-15 分鐘。

對應 knowledge card：stale-read、rpo、rto。

跟通用 cross-region replication 差在哪：Aurora 在 storage layer 複製、lag 上限更穩定；vs PostgreSQL logical replication lag 受寫速度影響大、heavy write 期間可能秒級到分鐘級。

Step-by-step 配置

建 global cluster：

 1# Step 1：在 primary region 建 global cluster
 2aws rds create-global-cluster \
 3  --global-cluster-identifier myglobal \
 4  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:primary-cluster \
 5  --region us-east-1
 6
 7# Step 2：在 secondary region 加 reader cluster
 8aws rds create-db-cluster \
 9  --db-cluster-identifier secondary-cluster \
10  --global-cluster-identifier myglobal \
11  --engine aurora-postgresql \
12  --source-region us-east-1 \
13  --region eu-west-1
14
15# Step 3：在 secondary region 建 db instance
16aws rds create-db-instance \
17  --db-cluster-identifier secondary-cluster \
18  --db-instance-identifier secondary-reader-01 \
19  --db-instance-class db.r6g.4xlarge \
20  --engine aurora-postgresql \
21  --region eu-west-1

Application routing：

1# 寫永遠去 primary region writer endpoint
2primary:
3  url: jdbc:postgresql://primary-cluster.cluster-xxx.us-east-1.rds.amazonaws.com/mydb
4
5# read 可走 secondary region reader endpoint（靠近用戶的 region）
6secondary-eu:
7  url: jdbc:postgresql://secondary-cluster.cluster-ro-xxx.eu-west-1.rds.amazonaws.com/mydb

DR 切換（planned failover）：

1aws rds failover-global-cluster \
2  --global-cluster-identifier myglobal \
3  --target-db-cluster-identifier arn:aws:rds:eu-west-1:123:cluster:secondary-cluster

切換後要不要改 connection string，取決於 application 連的是哪個 endpoint：連 Global Database 的 global writer endpoint 時不必改，截至 2026-09 的官方文件，managed switchover / failover 之後 Aurora 會把這個 endpoint 指到新的 primary cluster（生效時間受 DNS cache 影響）；連 primary cluster 自己的 cluster endpoint 時，application 端要 reconfigure connection string。

Application reconfiguration 模式：

• Connection string 用 service discovery（Consul / Route53 health check）動態解析
• 或在 application config 加入 region-aware logic、failover 後切換 active region
• 不能假設 application 自動 reconnect 到新 primary region

驗證點：

• AuroraGlobalDBReplicationLag < 1 秒
• Planned failover RTO 量測（手動 trigger + heartbeat timestamp diff）
• Application 跨 region read 路徑 latency 符合預期

Rollback boundary：promote secondary 後原 primary 變 secondary、不會自動 fallback；rollback 要再做一次 failover。

故障模式 / 邊界 case

期待 multi-region active-active write

徵兆：team 在 secondary region application 直連 secondary cluster 寫資料、收到 cannot execute INSERT in a read-only transaction 錯誤。

原因：Global Database secondary 是 reader-only、寫只能去 primary region。要 active-active write 必須改用其他服務（Aurora DSQL / Spanner / CockroachDB）。

修：

• Application 設計時明確區分 read region vs write region
• 寫操作永遠路由到 primary region、容忍跨 region write latency
• 真的需要 active-active write 才考慮 Aurora DSQL（2024-12 preview / 2025-05 GA）

連 cluster endpoint 時 DNS 不跨 region 自動切

徵兆：手動 failover trigger 後、application 端 connection string 仍指向舊 primary region、寫操作全失敗。

原因：每個 cluster 自己的 cluster endpoint 只在同一個 region 內跟著 failover 走；application 連的是這種 region-specific endpoint 而不是 global writer endpoint 時，Global Database 切換後要 application 端自己換 connection string。global writer endpoint 會在 managed switchover / failover 後指到新的 primary cluster（截至 2026-09 的官方文件），但 DNS 更新的生效時間受 DNS cache 長度影響，而且 application 要能連到新 primary region 的 VPC。

修：

• Application 用 service discovery（Route53 / Consul / etcd）解析 active primary region
• 部署 region-aware DNS（Route53 latency-based routing + health check）
• Failover 演練要包含 application reconfiguration step、不只是 DB layer

跨 region read 假設 strong consistency

徵兆：用戶在 primary region 寫資料、隨即在 secondary region read、看到舊資料、客訴 inconsistency。

原因：Global Database 是 async replication、< 1 秒 lag 不是 zero、read-after-write 場景仍會看到 stale data。

修：

• 用戶寫操作後短期內 read 走 primary region（read-after-write window）
• 接受最終一致性、application 端做 versioning / timestamp 比對
• 強一致性需求改 Aurora DSQL / Spanner

Bulk operation 期間跨 region lag spike

徵兆：DDL 或 bulk insert 期間 cross-region lag 從 < 1 秒跳到秒級到分鐘級、secondary region read 大量 stale。

原因：Global Database 「< 1 秒」是 typical、heavy write 期間 lag 拉大。Storage-level replication 比 logical 穩定、但 不是 zero variance。

修：

• DDL 跟 bulk insert 在低峰期跑、避開跨 region read traffic
• 監測 AuroraGlobalDBReplicationLag、spike 超過閾值 trigger application 端 fallback（read 切回 primary region）
• 重建整張表的維護作業同樣是 heavy write：pg_repack 只移除表與索引的 bloat、不執行 schema 變更，它重建表的期間會拉高跨 region lag，一併排進低峰期並先量測 lag

合規邊界誤用 Global Database — Standard Chartered anti-pattern

徵兆：team 以為 Global Database 是受監管金融的標準 DR 解、配置完才發現監管機構不接受跨境資料複製、被迫拆掉 Global Database 重建獨立 cluster。

Standard Chartered case 「判讀」段第 1 點原文：「7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成『7 個獨立規劃 × 各自合規門檻』」。

原因：受監管市場資料 不能跨境複製（Data Residency 硬約束）、Global Database 本質上就是跨 region storage replication、配置了就違反合規。Standard Chartered 的選擇是 每市場獨立 cluster、跨市場 DR 走應用層市場切換、不靠 Global Database。

修：

• 規劃 multi-region 前先確認合規要求（資料駐留、跨境複製禁令、稽核要求）
• 合規禁止跨境複製場景：每市場獨立 cluster + cross-AZ failover 吸收 RTO（見 cross-az-failover-rto）
• 跨市場 DR 設計成 市場切換（用戶從 A 市場切到 B 市場）、不是 資料切換
• Fleet 拓樸（多市場 → 多 cluster）詳見 Aurora read replica scaling fleet 治理 SSoT

scope warning（必明示）：Standard Chartered case 未公開是 PostgreSQL 還是 MySQL、未公開具體 cost 數字、屬「相關 case study」匿名對照。引用時不能擴寫具體 engine。

Cost trap — cross-region data transfer

徵兆：開了 Global Database 後月帳變高 50%、發現 cross-region data transfer 是主要費用、不是 instance。

原因：Aurora 跨 region replication 走 AWS 內部網路、但 cross-region data transfer 仍計費。Heavy write workload 月費可能 doubled。

修：

• 用 AuroraGlobalDBReplicatedWriteIO × per-region transfer rate 估月費
• Write-heavy workload 評估 Global Database ROI（保險、低費用版本是用 cross-region snapshot 做冷備）
• Cost 跟 RTO 一起看 — 如果接受 hours RTO、cross-region snapshot 更便宜

FanDuel 雙峰 case 對照（避免 over-extrapolate）

如果 team 引用 FanDuel 規劃 multi-region 部署、要明示 scope warning。

case「判讀」段第 1 點原文：「直播跟投注是兩種完全不同 SLO：直播容忍秒級延遲（用 CDN + ABR 串流）、投注必須毫秒級成交。兩個服務必須各自獨立擴容、各自獨立 SLO」。

scope warning（必明示）：

• FanDuel 5-10x 是 betting 服務的 Aurora 擴容倍數、不是 streaming（streaming 走 CDN、不走 Aurora）
• 不能壓成「Aurora 撐 5-10x」單一數字
• 案例自承：betting transaction TPS 跟 concurrent streams 未公開、不能 over-extrapolate

引用 FanDuel 規劃自家 multi-region betting workload 時、看 策略（事件型分級 + 雙 SLO 拆分 + 多層 edge）、不套用 具體數字。

跟 Aurora DSQL / Spanner / CockroachDB 的決策樹

Global Database 是 async + reader-only secondary、不是 multi-region active-active。當 active-active write 是核心需求時、要看 distributed SQL 方案。

何時選 Global Database：

• DR + 跨地理 read 是主要需求
• 寫流量集中在一個 region（單 region write 撐得住）
• 合規允許跨境複製（一般 SaaS、非受監管）
• 從 single-region Aurora 升級、不想換 engine

何時改 Aurora DSQL / Spanner / CockroachDB：

• Multi-region active-active write
• 跨 region strong consistency 是業務需求
• 跨雲 / on-prem 需求（CockroachDB）

何時不用 Global Database：

• 合規禁止跨境複製（Standard Chartered case）→ 每市場獨立 cluster
• Single-region 已滿足 DR / read 需求
• 跨 region cost 不划算（write-heavy workload）

容量與觀測

核心 metric：

1AuroraGlobalDBReplicationLag       # secondary lag、< 1 秒 typical
2AuroraGlobalDBReplicatedWriteIO    # cross-region data transfer 量
3AuroraGlobalDBProgressLag          # storage replication progress

容量上限：

• 1 primary region + 5 secondary region
• 每 secondary region 16 個 reader 含 1 個 headless（可升 writer）

Cost signal：

1月費 ≈ AuroraGlobalDBReplicatedWriteIO × per-region transfer rate
2     + secondary region instance + storage
3     + cross-region snapshot (optional)

Write 量大的 workload 月費可能 doubled（primary region + secondary region 都計費）、要在規劃時估準。

驗證 DR：

• Planned failover drill 每季一次、量測 RTO / RPO
• 受監管產業：每月一次、有合規 sign-off 記錄
• 重大版本升級前必跑一次

回路徑：9.6 容量規劃模型 cross-region cost、8.x DR playbook region-level failover decision。

邊界與整合 / 下一步

同 vendor 的其他文章：

• Aurora storage architecture — cross-region replication 是 storage-level 延伸
• Aurora cross-AZ failover RTO — cross-AZ 跟 cross-region failover RTO 數量級對比
• Aurora read replica scaling — fleet 治理 SSoT、合規驅動 fleet 拓樸的展開

Migration playbook：

• PostgreSQL / MySQL → Aurora — 從 PostgreSQL streaming replication 跨 region 升級的差異

1.x 章節互引：

• 1.11 全球分散式 OLTP — Global Database vs distributed SQL 對比

何時不用本文：single-region OLTP、無跨 region DR / read 需求時可跳過。

相關連結

• Aurora vendor overview
• Stale Read 卡片 — read-after-write 容忍度
• RPO 卡片 — DR RPO 判讀
• Standard Chartered — 合規驅動的 Global Database anti-pattern
• FanDuel — 雙 SLO 並行的 multi-region 策略對照
• Vendor 深度技術文章方法論 — vendor 深度文章從問題情境、核心機制、操作流程、失敗模式、容量與觀測到邊界與整合的寫法
• 官方：Aurora Global Database