教學路線：Managed SQL 與平台責任轉移

Aurora 服務頁的教學目標是把 PostgreSQL / MySQL 語意延伸到 AWS managed storage / compute 分離模型。讀者讀完後要能判斷哪些責任交給 Aurora，哪些責任仍留在 schema、query、maintenance window、region 與成本治理。

定位：storage / compute 分離的 SQL

Aurora 跟傳統 PostgreSQL / MySQL primary 最大差異是 storage layer 重寫。傳統 SQL primary 把 storage 跟 CPU / RAM 綁定、storage 擴容要換 instance、replication lag 受 compute 影響。Aurora 把 storage 拉到分散式 log service、跨 6 個 storage node（3 AZ × 2 node）、storage 跟 compute 獨立擴。

容量特性：

• 單一 cluster 最高 storage：128 TB
• 最多 15 個 read replica（單 region 內）
• read replica replication lag：10-30ms（vs 傳統 PostgreSQL 跨 AZ 可能秒級）
• 跨 AZ failover：< 30 秒（promote read replica）
• Aurora Global Database 跨 region replication：< 1 秒典型 lag

為什麼這個分離很重要：

• 傳統 PostgreSQL primary 上的 read replica 都靠 logical replication、會跟著 primary write load 走慢
• Aurora storage 直接複製到 6 個 storage node、read replica 從 storage 讀、不靠 primary
• → read replica 大幅減少 lag、可以撐更多 OLTP read traffic
• 對應 9.C23 Netflix +75% 效能改善的關鍵原因

適用場景

按公開 case 提煉的典型適用場景：

1. 既有 PostgreSQL / MySQL 應用想要 managed：

• wire protocol 相容，應用層改動通常集中在連線、參數與操作流程
• ORM / driver / SQL 多數可保留，但 migration plan 仍要驗證 dialect 與 extension
• 對應案例：9.C23 Netflix — 多套 RDBMS（PostgreSQL、MySQL、Oracle）統一到 Aurora、+75% 效能、-28% 成本

2. 金融交易 / 體育博彩 OLTP：

• 強 ACID transaction
• 多 read replica 處理 query traffic、不影響寫
• 對應案例：9.C4 DraftKings — 每分鐘 100 萬 ops、200 個獨立資料庫、Super Bowl 流量 +50% 無影響

3. 受監管產業跨市場部署：

• 每個市場一個獨立 cluster、合規分割
• 對應案例：9.C14 Standard Chartered — 7 個受監管市場、各自獨立 Aurora、總吞吐 4000 TPS、10x 提升

4. 高峰流量 + 多 read replica 擴容：

• read 高峰用 read replica 接、write 走 primary
• 對應案例：9.C28 FanDuel — 5-10x Super Bowl 峰值、直播 + 投注雙工作負載

5. Aurora Serverless v2 適用場景：

• 流量 unpredictable + sustained workload
• 自動 scale CPU / RAM，降低 instance class 管理負擔
• 適合：dev / test 環境、流量稀疏的多 tenant SaaS

6. Aurora Global Database：

• 跨 region async replication（< 1 秒 typical）
• DR + 跨地理 read（write 在 primary region、read 可從 secondary region）
• Global Database 是跨 region DR / read route，multi-region active-active write 要改看 Aurora DSQL

不適用場景

1. 跨雲需求：

• Aurora 是 AWS-only、wire protocol 相容但 storage 是 AWS 專屬
• 替代：自管 PostgreSQL / MySQL on Kubernetes

2. 需要最新 upstream PostgreSQL / MySQL 特性：

• Aurora 通常落後 upstream 1-2 個 major version
• 替代：RDS PostgreSQL（更接近 upstream）

3. 極端寫入吞吐：

• 單一 primary 寫入受 storage 設計限制（雖然比 PostgreSQL 快）

• 100K WPS 級別、考慮 sharding、CockroachDB、或 DynamoDB

• 對應 9.C29 Lemino — RDB connection limit 是 bottleneck、改 DynamoDB

4. 全球 multi-region active-active write：

• Aurora Global Database 是 async、有 lag，write 仍集中在 primary region
• 替代：Aurora DSQL（2024 推出）、Spanner、Cosmos DB

5. 預算敏感的小 workload：

• Aurora 比 self-managed PostgreSQL 貴 20-30%
• 小流量場景、自管 PostgreSQL on EC2 或 RDS 更便宜

跟其他 vendor 的取捨

vs RDS PostgreSQL / MySQL（同 AWS）：

• Aurora：storage / compute 分離、更多 read replica、更快 failover、跨 AZ 自動 replication
• RDS：純 managed PostgreSQL / MySQL、不重寫 storage、更接近 upstream
• 選 Aurora：需要 scale read replica 或 cross-AZ failover < 30 秒
• 選 RDS：需要最新 upstream 特性、預算更敏感

vs 自管 PostgreSQL / MySQL：

• Aurora：託管、自動 backup / failover，降低日常 database operation
• 自管：彈性高、可自己 tuning、跨雲可用、預算可控
• 選 Aurora：團隊想把 DBA / SRE 操作責任轉交 AWS、AWS 生態深
• 選自管：跨雲需求、需要客製化、預算極敏感

vs CockroachDB：

• Aurora：single-region scaling（一個 region 內擴）、AWS-only
• CockroachDB：multi-region 強一致、跨雲可用、PostgreSQL wire protocol
• 選 Aurora：AWS-only + single-region OLTP
• 選 CockroachDB：需要 multi-region 強一致 + 跨雲 / on-prem 彈性

vs Aurora DSQL（2024-12 preview / 2025-05 GA）：

• Aurora：single-region scaling、傳統 OLTP
• Aurora DSQL：multi-region active-active write、serverless、強一致
• 選 Aurora：流量集中在一個 region
• 選 Aurora DSQL：需要全球 active-active
• 從 PG / Aurora PG 遷 DSQL 的完整 playbook 見 PG → Aurora DSQL Migration

vs DynamoDB：

• 詳見 DynamoDB vendor page 對比段。Aurora 是 SQL、DynamoDB 是 KV、適用場景不同。

vs Azure SQL Hyperscale：

• 設計理念類似（storage / compute 分離）
• Aurora 在 AWS、Hyperscale 在 Azure
• 對應案例：9.C32 Clearent — Azure 生態的同類設計、5 億 payment txn / 年

容量規劃要點

從 09 案例庫提煉的 Aurora 容量規劃實踐：

1. read replica 是擴 read traffic 的主要工具：

• 最多 15 個 read replica、replication lag 10-30ms
• read replica autoscaler 按 CPU / connection 自動加減
• 對應 9.C4 DraftKings 用多個 read replica 處理「比賽期間用戶查 balance」流量

2. 200 個獨立 cluster 模式：

• Aurora 的實務設計通常用多個 bounded cluster 控制 blast radius
• 按業務切多個小 cluster（9.C4 DraftKings 200 個）、降低 blast radius
• 對應 microservice 私有 store（9.C23 Netflix 同樣思維）

3. Aurora I/O-Optimized：

• 2023-05 推出的 storage 配置
• 適合 I/O-heavy workload（write 多、scan 多）
• 比 standard storage 貴、但少 I/O 收費
• 對應 9.C4 DraftKings 用 I/O-Optimized 加速

4. Aurora Serverless v2：

• ACU（Aurora Capacity Unit）為單位、自動 scale 0.5-128 ACU
• 適合 dev / test、稀疏 workload、unpredictable burst
• 不適合：sustained predictable high workload（provisioned 便宜）

5. Cross-region Global Database：

• < 1 秒 typical replication lag、但是 async
• secondary region 可 read，write 仍回 primary region
• DR 切換通常 1-2 分鐘
• 對應 9.C14 Standard Chartered — 跨市場各自獨立 Aurora，合規邊界優先於 Global Database

6. Connection pool 仍是隱性限制：

• Aurora 跟傳統 PostgreSQL 一樣有 connection pool 上限
• 應用層 + Aurora 之間建議用 RDS Proxy 做 pool 共享
• 對應 9.C29 Lemino — RDB connection limit 是 surge 場景的 bottleneck；Lemino 案例發生在 RDS，但 connection-bound 機制同樣適用 Aurora

Deep article（已完成）

本 vendor 現有 deep article 覆蓋 Aurora 從 storage architecture、fleet 治理到容量彈性、連線管理與 distributed 升級門檻的核心 production 議題：

I/O-Optimized vs Standard 成本對比由 Aurora PostgreSQL I/O-Optimized Cost 主寫（storage I/O 成本模型 SSoT），本 vendor 各篇提到 storage 成本時 cross-link 它、不重複展開。

跨 vendor entry：先看 CockroachDB vs Aurora DSQL vs Spanner 決策樹（distributed SQL 三選一 + 撞牆訊號分型），再決定是否進 Aurora overview。

後續擴充（仍待補）

• Aurora Global Database write forwarding 深入
• Babelfish（SQL Server 相容層）適用判斷
• Blue/Green deployment 做 major version 升級
• Backup / PITR restore drill（hands-on lab）

Anti-recommendation 與升級路由

Aurora 的 managed SQL 能把大量操作責任交給 AWS，但它仍保留 single-primary SQL 的資料模型與交易邊界。這一段先說何時維持 RDS / Aurora，再說何時升級 Global Database、Serverless v2、RDS Proxy、Aurora DSQL 或 DynamoDB。

Aurora 的簡單路徑是先把 operation transfer 寫清楚。Backup、minor upgrade、storage growth、failover 與 read replica lag 交給平台後，schema design、query shape、transaction boundary、connection pool 與 cost guardrail 仍由 application / SRE 共同承擔。

Global Database 的升級路徑要先定義讀寫方向。它適合 DR 與跨地理 read，若業務需要多 region 同時寫入並保持強一致，應直接進入 Aurora DSQL、Spanner 或 CockroachDB 的 distributed SQL 比較。

已知 limitation 與後續路由

Aurora overview 目前完成 managed SQL 判斷。下一輪 deep article / playbook 應補 storage architecture、RDS Proxy、Global Database、Serverless v2、I/O-Optimized cost、PostgreSQL / MySQL → Aurora migration 與 Aurora → Aurora DSQL 的分歧路徑。

案例對照

Aurora case 的讀法是看 operation transfer 如何變成容量與成本結果。DraftKings 與 FanDuel 提供 peak OLTP 訊號，Standard Chartered 提供合規分區訊號，Netflix 則提供多套 RDBMS 整併到 managed SQL 的組織與成本訊號。

反向 sibling 路由

Aurora 的反向 sibling 路由用來避免把 managed SQL 誤讀成唯一升級方向。若讀者從 PostgreSQL / MySQL 章節過來，先對照 PostgreSQL → Aurora 與 MySQL → Aurora；若核心需求是 connection surge，補讀 DynamoDB vendor 與 Lemino case；若核心需求是 multi-region active-active write，轉到 Spanner vendor 或 CockroachDB vendor。

這條路由的判準是先問「保留 SQL + 轉移 operation」是否足夠。答案成立時，Aurora 是 RDS / 自管 MySQL / 自管 PostgreSQL 的 managed endpoint；答案需要改成 global quorum、partition-key access pattern 或 document API 時，Aurora 應退到對照組，而非成為最後選項。

常見陷阱

• 誤以為 Aurora 等於無限擴：寫吞吐仍受 primary 限制，容量曲線和 distributed SQL 不同
• 忽略 read replica：把所有 query 打 primary，會浪費 read replica scaling 能力
• 跨 region 強一致誤解：Global Database 是 async 複製，multi-region active-active 要看 Aurora DSQL / Spanner / CockroachDB
• connection pool 忽略：Aurora 仍是 PostgreSQL / MySQL、connection 上限有效
• 單一巨大 cluster：把所有業務塞進一個 cluster 會放大 blast radius，通常要按業務切

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：DynamoDB vendor page（NoSQL 對比）
• 上游：1.3 Transaction Boundary / 1.11 全球分散式 OLTP
• 下游：1.12 大規模 DB 遷移實戰（從 RDS / 自管遷到 Aurora）
• 跨模組：9.5 瓶頸定位流程、9.6 容量規劃模型
• Last reviewed：2026-05-22（Aurora storage / Serverless / Global Database / I/O-Optimized 屬時間敏感 claim）
• 官方：Amazon Aurora、Aurora storage architecture

本文是跨 vendor migration playbook、cross-link 到 MySQL 跟 Aurora。走 Migration playbook methodology Type C operational hybrid 結構。每階段切換用 migration gate 把關。

從 MySQL 角度 看 Aurora MySQL：wire protocol 一致、SQL 一致、ORM 不必改、application 連 endpoint 字串以外幾乎不必動。從 Ops 角度 看 Aurora MySQL：所有 storage / replication / failover knob 都 看不到也改不了、整個 ops 心智模型重寫。

這是 Type C operational hybrid 的典型 signature — schema / paradigm 接近、operational 完全不同。

為什麼是 Type C（operational 為主）

跑 6 維 diff dimension audit：

Operational = High（其他 Low） → Type C operational hybrid。Migration 路徑用 4-phase drop-in cutover + operational re-onboarding。

Driver：TCO + Multi-AZ HA + AWS integration

從自管 MySQL 遷到 Aurora MySQL 的核心 driver：

• TCO：自管 MySQL 真實 cost = EC2 + EBS + ops headcount（1-3 個 FTE 撐大 MySQL deployment）。Aurora per-GB / per-IOPS 比 EC2+EBS 貴 30-50%、但省 ops headcount、總帳通常 break-even 或更便宜
• Multi-AZ HA：Aurora storage 自動 6 份跨 3 AZ、failover < 30 秒、不需要自管 Orchestrator + VIP + fence script
• AWS ecosystem integration：跟 Lambda / SAM / CloudFormation / IAM / Secrets Manager 整合、給 cloud-native architecture 加分
• Read scaling：Aurora 最多 15 個 read replica、storage layer 共享（不 replicate data、僅 replicate page cache）、read latency < 10ms inter-replica

不適合 已用 Percona Server fork 或 需要 cross-cloud portability 的 org — Aurora MySQL 是 AWS-only、且 fork 自 MySQL 5.7/8.0、跟 Percona 特性不完全一致。

4-phase migration

Phase 1：Aurora cluster 起來作為 read replica

最低風險入口：建 Aurora cluster、用 MySQL binlog 把 production 資料 stream 進 Aurora。Application 仍寫自管 MySQL primary、Aurora 作為 external read replica。

 1# 1. 在 AWS 建 Aurora MySQL cluster
 2aws rds create-db-cluster \
 3  --db-cluster-identifier prod-aurora \
 4  --engine aurora-mysql \
 5  --engine-version 8.0.mysql_aurora.3.04.0 \
 6  --master-username admin \
 7  --master-user-password ... \
 8  --database-name production \
 9  --vpc-security-group-ids sg-xxx \
10  --db-subnet-group-name prod-subnet
11
12# 2. 用 mysqldump 或 Percona XtraBackup 拿 baseline
13mysqldump --single-transaction --master-data=2 --triggers --routines --events \
14  --all-databases > baseline.sql
15
16# 3. Restore 到 Aurora
17mysql -h prod-aurora.cluster-xxx.us-east-1.rds.amazonaws.com -u admin -p < baseline.sql
18
19# 4. 設定 Aurora 從自管 MySQL 接 binlog
20CALL mysql.rds_set_external_master(
21  'self-managed-primary.example.com', 3306,
22  'replication_user', 'password',
23  'mysql-bin.000123', 12345, 0
24);
25CALL mysql.rds_start_replication;

完成標準：Aurora replica lag < 1 秒、跟 production primary 同步。

Phase 2：Application read 切到 Aurora reader endpoint

Application 仍寫自管 primary、但讀 query 切到 Aurora reader endpoint：

• Aurora reader endpoint：prod-aurora.cluster-ro-xxx.us-east-1.rds.amazonaws.com
• 自動 round-robin 多個 read replica
• ProxySQL 或 application config 改 read connection string

跑 1-2 週、確認：

• Aurora read latency 跟自管 replica latency 接近（通常 Aurora 略好）
• Aurora replication lag 穩定 < 1 秒
• Aurora query 結果跟自管 primary 一致（spot-check critical query）

完成標準：所有 read traffic 都進 Aurora、no application bug。

Phase 3：Cutover — promote Aurora primary

Cutover window 內：

 1# 1. 停 application 寫入（feature flag / scheduled maintenance）
 2
 3# 2. 等自管 primary 跟 Aurora 同步完成（檢查 Aurora replica lag = 0）
 4
 5# 3. 把 Aurora 從 external replica 提升為獨立 primary
 6CALL mysql.rds_stop_replication;
 7CALL mysql.rds_reset_external_master;
 8
 9# 4. Application 寫 connection string 切到 Aurora writer endpoint
10# prod-aurora.cluster-xxx.us-east-1.rds.amazonaws.com
11
12# 5. 開始 application traffic

完成標準：寫入流量 100% 進 Aurora、自管 primary 變 idle。Cutover 通常需要 30-60 分鐘 maintenance window。

Phase 4：Decommission 自管 MySQL

跑 1-2 週確認 Aurora 穩定後 慢慢退役自管：

• 自管 primary 保留作 cold backup（1-3 個月）、不接 traffic、可隨時 rollback
• Replica 一個一個關掉
• 監控 Aurora cost vs 預估、確認 break-even

完成標準：自管 EC2 instance terminate、EBS volume snapshot 後 delete、cost 對比驗證符合預期。

5 個 Production 踩雷

1. Parameter group 沒對齊 — innodb_flush_log_at_trx_commit 等行為差

Aurora 的 parameter group 取代 my.cnf。預設 parameter group 不一定跟自管 MySQL 一致：

• innodb_flush_log_at_trx_commit：自管常設 1（zero loss）、Aurora 預設仍 1 但走 Aurora storage durability（行為等價但不同 mechanism）
• sync_binlog：自管 1、Aurora 沒有 binlog 寫 disk 概念（Aurora 不用 binlog 做 replication、binlog 是 optional output）
• time_zone：Aurora 預設 UTC、自管常設 local time、TIMESTAMP query 行為可能不同
• character_set_*：自管常設 utf8mb4、Aurora 預設可能是 latin1（看 cluster create 命令）

修法：

• Phase 1 完成後 逐 row 對比 parameter group：

  1SELECT @@global.variable_name FROM ...

• 建 custom DB cluster parameter group、匹配自管設定

• 重啟 Aurora primary 套 parameter group 改變（部分 parameter 需要重啟）

2. IAM authentication — application 沒準備

Aurora 提供 IAM authentication（不用 password、用 AWS IAM role + temporary token）。Application 用 IAM auth 不必管 password rotation、但程式碼必須 call AWS SDK 取 token、放 connection 設定。

如果 Phase 2-3 期間沒 reverse engineer application connection logic、cutover 後 application 仍試用 password auth、Aurora 拒絕、production down。

修法：

• 評估是否啟用 IAM auth — 簡單情況保留 password、整合 AWS Secrets Manager 自動 rotation
• 啟用 IAM 必須 application code 改：
  • Java：com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator
  • Python：boto3.client('rds').generate_db_auth_token(...)
  • Go：aws-sdk-go-v2/feature/rds/auth
• Phase 2 期間 application 對 Aurora 用 IAM token、self-managed 仍 password — 雙 path code

3. Aurora-only feature 寫進 application、rollback 成本升高

Migration 過程開發發現 Aurora 有 Aurora-only feature（Backtrack、Performance Insights、Aurora Global Database）、誘惑使用。一旦 application 用了 Aurora-only feature、要 rollback 自管 MySQL 變不可能（feature 不存在、query 失敗）。

常見 Aurora-only feature：

• Backtrack：72 小時內 in-place rollback 整個 DB（不同於 PITR）
• Aurora ML：SQL function 內接 SageMaker / Comprehend
• Aurora Parallel Query：analytical query 跨 storage node 並行
• Aurora Auto Scaling：read replica 數量按 CPU 自動加減

修法：

• Phase 1-3 期間禁用 Aurora-only feature、保留 rollback option
• Phase 4 完成後 才開始 evaluate Aurora-only feature、加進來時 明確記錄不可 rollback decision
• 把 Aurora-only feature 跟 Aurora 特定 cluster 綁定，避免 application 邏輯依賴 Aurora-only

4. Read replica endpoint behavior — Application 不知道 reader endpoint round-robin

Aurora reader endpoint（prod-aurora.cluster-ro-xxx）是 DNS-based load balancer、每次 DNS query 給不同 replica IP。Application connection pool 連續開 10 個 connection、可能全部連同一個 replica（DNS cache）、不均勻。

修法：

• Application connection pool 強制 DNS re-resolve（避免長時間 cache）
• 或用 RDS Proxy（managed connection pool）放在前面、不直接連 reader endpoint
• 或用 Route 53 latency-based routing 配 Aurora reader endpoint per AZ、application 連最近 AZ

5. Region failover — Aurora Global Database vs 自管 chained replication

自管 cross-region replication 是 chained replication（primary → region2 replica → region2 cascading replica）。Aurora Global Database 是 storage-level replication（storage page 直接 ship，而非 binlog）、跨 region < 1 秒 lag、failover < 1 分鐘。

但 Aurora Global Database 是 active-passive（primary region 可寫、secondary region 只讀）。如果原本自管已經 cross-region active-active write（用 multi-master 或應用層 sharding）、Aurora Global Database 的寫入模型會成為限制。

修法：

• 評估 cross-region 是 DR 用途還是 active write 用途
• 純 DR + read scaling：Aurora Global Database 直接 cover
• Active-active write：要 Aurora DSQL（2024 新推出、跟 Aurora 不同 product）或 distributed SQL（CockroachDB / Spanner）

Capability gap：自管 MySQL 有但 Aurora 沒有

評估時必須確認 當前自管功能 沒用到 Aurora 不支援的能力。如果在用 MyRocks 等 storage engine、Aurora migration 不可行。

容量與成本對照

對 100 GB DB、5K WPS、20 個 application instance 的 deployment：

Pure infra cost Aurora 貴 30-50%、但 ops cost 降幅大過 infra increase — 200 人 eng team 養 1.5 FTE DBA 是 $300K-400K/yr、Aurora 換成 0.3 FTE 是 $60K-100K/yr、差距 $200K+ 抵 infra increase。

小團隊 / 小 deployment Aurora 不一定划算 — 50 人 eng team 沒有 dedicated DBA、自管 MySQL 也只佔某人 20% 時間、Aurora migration 的 ops saving 不存在。

Production case：Netflix Aurora consolidation

MySQL → Aurora migration 的 production 責任是把自管 database operation 轉移成 managed SQL 的契約，而非只搬 schema 與資料。9.C23 Netflix Aurora consolidation 提供的工程訊號是多套 RDBMS 整併到 Aurora 後，效能、成本與操作責任一起改變。

這個案例要回收到三個操作判準。第一，migration driver 應寫成 operation transfer，例如 backup、failover、storage growth、patching 與 observability 由誰承擔。第二，效能與成本要一起看，因為 Aurora 的 storage / compute / I/O 計費會把原本藏在 DBA 操作裡的成本攤開。第三，整併多套 RDBMS 時要先做 feature inventory，確認 plugin、storage engine、charset、replication topology 與 SQL mode 都能落到 Aurora MySQL 支援範圍。

Netflix case 的 sibling 路由是 Aurora vendor page 與 PostgreSQL → Aurora。若 migration 目標從 managed SQL 變成 multi-region active-active write，應改接 1.11 全球分散式 OLTP。

何時維持原路線

• Cross-cloud portability 是 requirement：Aurora AWS-only、要 cross-cloud 用 PlanetScale 或 自管
• 用 Percona Server fork / MyRocks 等非標準 engine：Aurora 不支援
• 需要 OS-level customization：Aurora 完全 managed、無 SSH
• 規模太小：< 100 GB / < 1K WPS、自管 MySQL EC2 spot instance 已經夠便宜
• 規模太大：> 50 TB single DB / > 100K WPS、Aurora single-instance 仍是 ceiling、考慮 Vitess 或 Aurora DSQL

相關連結

• 平行 batch：→ PlanetScale migration playbook（同 MySQL backlog、不同 target paradigm）
• 上游：MySQL vendor overview / Aurora vendor page
• 跨章節：9.6 容量規劃模型 — Aurora cost forecast
• 既有 case：9.C23 Netflix Aurora consolidation — Netflix 從多套 RDBMS 統一到 Aurora 的 migration evidence
• 方法論：Migration Playbook Methodology（Type C operational hybrid 結構說明）
• 官方：Aurora MySQL Migration Guide

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 storage-level 設計的實作層教學。覆蓋 quorum-based replication 的工程含義、「韌性即性能」frame 為什麼成立、OLTP workload 在 storage 設計下的讀寫雙峰錯位、跟容量規劃的判讀槓桿。

問題情境

典型觸發場景：團隊從 RDS PostgreSQL / 自管 PostgreSQL 遷到 Aurora、看到「跨 AZ replication lag 從秒級降到毫秒級」、但讀文件「quorum」「4-of-6」「分散式 storage」訊息密集、不知道哪些設計決策要相信、哪些是 marketing 詞。

讀者常見的具體疑問：

• 「為什麼 Aurora 寫入比 RDS 還低、不是該因為跨 AZ network round-trip 而變慢？」
• 「Storage layer 跟 compute layer 分離具體怎麼影響 backup、failover 跟 read replica？」
• 「6 個 storage node 失去 2 個還能寫嗎？失去 3 個呢？」
• 「Aurora 文件講『韌性』跟『性能』都用 storage 設計解釋、是同一件事還是兩件事？」

進一步問題：傳統工程文化把可靠性跟性能視為對立 — HA 投資（跨 AZ replication、failover 演練）通常被當成性能成本、不被視為性能來源。Aurora 設計反這個直覺、但讀者需要看到具體機制才能信。Standard Chartered case 揭露這個 frame 在受監管銀行業務（要求兩者同時達標）的價值；DraftKings 揭露具體數字（讀 < 1ms、寫 6ms）。

核心機制：quorum-based 分散式 log

Aurora storage 的 first-class concept 是 quorum 寫入 + 6-way 跨 AZ replication。傳統 PostgreSQL primary 把 storage 跟 CPU / RAM 綁定、storage 擴容要換 instance、replication 在 compute 層做（streaming replication、logical replication）。Aurora 把 storage 拉到分散式 log service、6 個 storage node 各自獨立、application 看到的仍是 single primary SQL。

Storage layout：每個 storage segment 跨 3 AZ × 2 node、共 6 個 storage node。一個 cluster 的 storage 被切成多個 10GB segment、每個 segment 6-way 複製。

Quorum 設定：

• Write quorum：4-of-6（4 個 storage node 確認寫入才算 commit）— 容忍 1 AZ 失效 + 1 node 失效仍能寫
• Read quorum：3-of-6（讀 3 個 node 取最新版本）— 比 write 小、降低 read latency
• 算術不對稱：寫嚴讀鬆是設計選擇、不是 marketing — durability 由寫端保證、讀端可以放寬

Write path 跟傳統 PostgreSQL 的差異：

• PostgreSQL primary：寫 WAL 到 local disk + dirty page flush + 透過 streaming replication 推到 replica
• Aurora compute node：只送 redo log records 到 storage、不送整個 page；storage node 自己 apply redo log 重建 page、自己 checkpoint、自己 backup
• 工程含義：compute node 寫量小、CPU 不被 dirty page flush 佔用、寫入路徑變短

「韌性即性能」frame（9.C14 Standard Chartered 揭露）：

Aurora 把 HA 從 application-level（Patroni promotion + WAL catch-up）下推到 storage-level。設計含義是：storage 投資（6-way 跨 AZ replication）自動成為 read replica 的容量基底 — read replica 不需要 catch-up WAL、直接從共享 storage 讀、HA 預算同步轉成讀分流預算。

對 Standard Chartered 受監管銀行業務這代表：合規要求的 RPO / RTO 不能放棄、但業務也要求每秒 4000 TPS、兩者必須同時達成。傳統路徑要分別投資 HA（複雜的 streaming replication topology）跟性能（read replica catch-up tuning）、且兩個投資互相干擾。Aurora 讓 同一份 storage 投資 同時提供兩件事 — case「判讀」段第 2 點原話：「Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 韌性即性能 的目標」。

對應 knowledge card：quorum、replication-lag。

跟通用 quorum 概念差在哪：Aurora quorum 是 storage-level（不是 application-level Cassandra 風格）、application 看到 single primary SQL、不用感知 quorum；vs Cassandra application 要選 consistency level（ONE / QUORUM / ALL）。

OLTP workload shape：讀寫雙峰錯位

Aurora 設計的工程含義在 application 層落地時、要看 workload 形狀。9.C4 DraftKings 揭露一個 OLTP 容量規劃的典型 pattern。

DraftKings 揭露的雙峰錯位（case「觀察」段最後一行原文）：「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時是讀爆量（balance query）、payout event 時是寫爆量（ledger write）、兩個峰不在同一時刻。

工程含義：

• 讀寫資源規劃要分開、不能用「峰值總 TPS」單一數字規劃容量
• 讀峰拉 read replica 容量、寫峰靠 primary instance class 跟 commit batching、兩條路徑獨立預配
• 預估 headroom 也要分開：讀的 headroom 可以靠 auto-scale replica 接、寫的 headroom 要靠 primary 提前升 instance class（不能 auto-scale）

Application-level boundary：雙峰錯位是 application 層 拆讀寫 datasource 的決策訊號、storage layer 本身不解。Aurora 共享 storage 提供 lag 上限可預測（10-30ms）— 這是 read replica 變成「production-grade 可用」的前提、但讀寫分流要 application 端拆 read / write data source 才能落地。Storage 設計給的是「可預測的 lag 上限」、不是「自動讀寫分離」。

跨 case 對照：

9.C28 FanDuel 揭露另一種雙峰 — 直播 + 投注 兩種服務 同時峰、不是同服務讀寫錯位。這兩種雙峰類型要分清楚：

• 同服務讀寫錯位（DraftKings）：解法是 read / write data source 拆分、共享 Aurora cluster
• 跨服務雙峰（FanDuel）：解法是不同服務各自獨立擴容、betting 走 Aurora、streaming 走 CDN

雙峰類型不同、容量規劃策略不同。

Step-by-step 配置 / 觀測

Aurora storage 是 cluster-level、不暴露 segment-level config。讀者能影響的維度是 instance class、storage type、backup retention 跟 monitoring。

Cluster 建立：

1aws rds create-db-cluster \
2  --db-cluster-identifier my-cluster \
3  --engine aurora-postgresql \
4  --engine-version 15.5 \
5  --master-username admin \
6  --master-user-password "$(aws secretsmanager get-secret-value --secret-id db-password --query SecretString --output text)" \
7  --storage-type aurora-iopt1 \
8  --backup-retention-period 7

關鍵欄位：

• --storage-type aurora-iopt1：Aurora I/O-Optimized、月費高 30% 但無 I/O 收費；write-heavy + scan-heavy workload 才划算
• --storage-type aurora（預設）：Standard storage、按 I/O 計費；read-light workload 划算
• --backup-retention-period 7：1-35 天、影響 PITR 範圍

觀測 storage 狀態：

1aws rds describe-db-clusters \
2  --db-cluster-identifier my-cluster \
3  --query 'DBClusters[0].{StorageType:StorageType,AllocatedStorage:AllocatedStorage,Status:Status}'

CloudWatch metric（cluster-level）：

1VolumeBytesUsed           # 當前 storage 用量、接近 128 TB 上限要警告
2VolumeReadIOPs            # storage 層讀 IOPS、判斷 I/O-Optimized ROI
3VolumeWriteIOPs           # storage 層寫 IOPS、跟 compute 層 WriteIOPS 對照
4AuroraVolumeBytesLeftTotal # 剩餘可用 storage

Performance Insights wait event：

1db.IO.aurora_redo_log_flush   # quorum write 等待訊號、p99 > 10ms 要看
2db.IO.aurora_storage_xx       # storage layer I/O 細節

驗證點：

• 寫入 latency p99：PostgreSQL primary 1-3ms vs Aurora 3-6ms、跨 AZ network round-trip 是物理下界
• Read latency p99：Aurora < 1ms（從共享 storage 讀、不跨 AZ）
• Storage autoscale event：128 TB 上限前自動 grow per 10GB

Rollback boundary：Aurora storage 是 cluster-level、無法回滾 storage 設計；唯一 rollback 是切回 RDS / 自管（走 migration playbook、不是配置層 rollback）。

故障模式 / 邊界 case

Case 1：誤以為 Aurora 寫入一定比 PostgreSQL primary 快

徵兆：團隊期待 Aurora 寫入比自管 PostgreSQL 快、實測 p99 寫入 latency 沒明顯改善、甚至小 row + 單筆 commit 場景 Aurora 反而慢。

原因：跨 AZ network round-trip 是 3-5ms 物理下界、4-of-6 quorum 至少要等 4 個 storage node ack、單筆小寫場景 local SSD primary 仍有 latency 優勢。Aurora 的寫入優勢在 壓力下 才顯現 — write throughput 高峰時 PostgreSQL primary 受限於 dirty page flush + WAL fsync + replica catch-up、Aurora 的 storage layer 各自獨立處理 redo log apply。

數字口徑：「跨 AZ round-trip 3-5ms」屬通用工程估算（光速下界 + AWS 區內 AZ 物理距離）、case 未直接量化、實際值依 region / AZ pair / instance 類型而異、要看 AWS 官方 latency table 或自家 benchmark 校正。下方 DraftKings 6ms 寫入是 case 揭露的 production reference、可作為對照基線。

修：

• benchmark 要跑壓力測試、不能只測單筆 latency
• 寫入 latency 不是 Aurora 的核心賣點、是 可預測的 read replica lag + 韌性 才是
• DraftKings 6ms 寫入是 production reference：跨 AZ quorum 的物理下界、不是 Aurora 慢

Case 2：AZ-level outage 期間寫入 latency spike

徵兆：1 個 AZ 失效後、寫入 p99 從 6ms spike 到 30-50ms、application timeout 增加。

原因：失去 1 AZ 後 quorum 仍成立（4-of-6 → 用剩 4 個 node 寫）、但 storage node fault 期間需要等 timeout 才確認；單一 storage node 額外 fault 會把寫推到 timeout。Aurora 在 AZ outage 期間 能寫、但不是 性能不變。

修：

• 監測 AuroraVolumeBytesLeftTotal 跟 storage IOPS 分布、AZ outage 期間自動切到剩餘 AZ
• application 端做 retry + circuit breaker、不要假設寫入永遠 6ms
• 確認 cluster 至少跨 3 AZ deploy、單 AZ outage 才有 quorum 餘地

Case 3：I/O-Optimized 費用誤判

徵兆：team 看 Aurora I/O-Optimized「無 I/O 收費」直接切過去、月帳變高 25%、沒看到 ROI。

原因：Standard storage 按 I/O 收費、I/O-Optimized 月費比 Standard 高 30%。只有 write-heavy + scan-heavy workload（I/O 月費接近 instance 費用）才划算；read-light + write-light workload 反而吃虧。

修：

• 先量測 baseline I/O：VolumeReadIOPs + VolumeWriteIOPs × $0.20 per million I/O vs Standard 月費
• I/O 費用 > instance 費用 30% 才切 I/O-Optimized
• DraftKings 用 I/O-Optimized 是因為金融帳本 write-heavy + balance query scan-heavy、ROI 明顯

Case 4：Storage autoscale 假設

徵兆：TRUNCATE / DROP 大表釋放 50% storage、但下月帳單沒回落。

原因：Aurora storage 自動 grow、但 不自動 shrink。已分配的 storage 持續計費、TRUNCATE / DROP 只釋放 logical space、physical storage 仍占用。要 shrink 必須走 logical migration（dump / restore 到新 cluster）。

修：

• 大量 DROP 操作前先評估是否值得做 logical migration
• 用 partition + DETACH 而非 DROP TABLE、partition 可以單獨 archive
• 接受 storage 用量是 peak watermark 而非 current usage

Case 5：Replication lag 誤解

徵兆：read replica lag 10-30ms 看起來夠快、application 假設 read-after-write consistency、用戶下注後立刻查 balance 偶發看到舊資料。

原因：10-30ms 是 typical、heavy write + slow query 期間可能秒級。Aurora 共享 storage 設計讓 lag 可預測（不會像 PostgreSQL streaming replication unbounded）、但 可預測 不等於 zero。Read-after-write 場景仍需要 application 端處理。

修：

• 用戶寫操作後 N 秒內走 primary（N 由 lag p99 決定、典型 100ms）
• Aurora 提供 session pinning：寫完同 session 短期內走 primary
• 不能假設「Aurora replication lag 小到可以忽略」、要看 application 容忍度

容量與觀測

核心 metric：

1VolumeBytesUsed           # storage 用量、128 TB 上限預警
2AuroraReplicaLag          # replica lag、判斷讀寫分流可行性
3db.IO.aurora_redo_log_flush # quorum write 等待、storage 瓶頸訊號

Production reference number（9.C4 DraftKings 揭露、case「觀察」段表格）：

這個 production reference 取代用「typical 3-5ms」籠統說法。讀寫 6x 差距是 OLTP 容量規劃槓桿 baseline — 寫延遲是 quorum 4-of-6 + 跨 AZ network round-trip 的物理下界、不是 storage 設計能再壓低。引用時要明示是 DraftKings production reference、不是 Aurora marketing。

容量上限：

• 128 TB / cluster（超過要拆 cluster、見 Aurora read replica scaling fleet 治理 SSoT）
• 15 read replica / region（Aurora read replica scaling 展開）
• Storage 自動 grow per 10GB

跨 region replication：Aurora Global Database 用 AuroraGlobalDBReplicationLag 監測、< 1 秒 typical。

回路徑：4.20 Observability Evidence Package 抽 CloudWatch evidence、9.5 瓶頸定位流程 判斷 storage-bound vs compute-bound。

Netflix +75% 效能改善的根因

9.C23 Netflix consolidation 案例揭露 storage 設計的具體效能含義。Netflix 把多套 RDBMS（PostgreSQL / MySQL / Oracle）統一到 Aurora、拿到 up to 75% 效能改善、-28% 成本。

+75% 的根因：

• 傳統 PostgreSQL primary 寫 WAL + dirty page flush + 透過 streaming replication 推到 replica
• Compute 大量 CPU 用在 dirty page flush + replication encoding、不是用在 query processing
• Aurora compute 只送 redo log records、storage 自己 apply page、自己 checkpoint
• → 同樣 instance class 下、Aurora compute 能處理更多 query

這不是 marketing 的「分散式儲存讓效能提升」籠統說法、而是具體的 compute 不再 flush dirty page。

scope warning（必明示、case 自帶警示原話）：

「effective 75% improvement 是跨多 workload 的最大改善幅度、不是『每個 workload 都 +75%』。實際每個 workload 改善幅度從 10% 到 75% 不等」（case「需要警惕」段第 1 點）。

引用 Netflix 時不能把 75% 套到單一 workload — 容量規劃要看自家 workload 形狀（write-heavy / read-heavy / scan-heavy）、預估改善幅度範圍而非單一數字。

Fleet 治理（cross-link、不展開）

Production scale 不是「單一巨型 Aurora cluster」而是 fleet of clusters — 5 case 揭露同一 frame：

• DraftKings 200 個獨立 cluster（按業務切分）
• Netflix 多 cluster（微服務私有 store）
• Standard Chartered 7 個 cluster（受監管市場 boundary）

跨 case 合成的 fleet 拓樸 3 條 driver（business sharding / microservice ownership / 合規市場 boundary）跟「何時拆 cluster vs 加 replica」的判讀順序、SSoT 在 Aurora read replica scaling 邊界段。Storage 設計本身不解 fleet 邊界決策 — Aurora 解 single-cluster scaling（quorum / 共享 storage / 共享 backup）、但「拆幾個 cluster」是業務拓樸決策。

邊界與整合 / 下一步

Sibling deep articles：

• Aurora cross-AZ failover RTO — storage 設計如何加速 failover（replica 不需要 catch-up）
• Aurora read replica scaling — 共享 storage 為什麼能養 15 replica + fleet 治理 SSoT
• Aurora Global Database — 跨 region storage replication 設計

Migration playbook：

• PostgreSQL / MySQL → Aurora — storage 設計差是 operational redesign 的核心 driver

1.x 章節互引：

• 1.3 Transaction Boundary — quorum 寫入 vs single-primary transaction 邊界
• 1.11 全球分散式 OLTP — Aurora storage 是 single-region scaling、不是 distributed SQL

何時不用本文：single-region OLTP 用 RDS 仍足夠、storage architecture 細節不影響容量規劃時可跳過、看 Aurora vendor overview 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Quorum 卡片 — 概念基底
• Replication Lag 卡片 — 對照通用 replication lag 模型
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora storage architecture

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 Serverless v2 的容量機制、設定與適用邊界的實作層教學。

核心機制：ACU 與秒級擴縮

Serverless v2 的容量單位是 ACU（Aurora Capacity Unit），一個 ACU 對應一組固定比例的記憶體與運算資源。cluster 不再綁定一個 instance class，而是設一個 ACU 區間（min / max），Aurora 依即時負載在區間內伸縮：

擴縮行為：

• 負載上升時 ACU 平滑增加、不需要切換 instance、無連線中斷
• 負載下降時縮回低水位、但受 min ACU 下限約束
• min ACU 決定離峰的最低成本與「保留多少暖容量」；max ACU 決定尖峰的上限與成本天花板

Scope warning：「ACU 對應的記憶體比例」「serverless v2 是否能縮到 0」「最小 ACU 粒度」這些屬 AWS vendor 規格、會隨版本演進（auto-pause 等能力陸續調整）、實作時 cross-verify 官方 doc 當前值。本文不含 production case 揭露的 ACU 配置數字。

對應 knowledge card：peak forecast、cost per request。

min / max ACU 的設定權衡

min 與 max ACU 不是隨便設，兩端各自承擔不同風險。

min ACU 太低：離峰省錢，但流量回升時從很低的水位往上爬、爬升期間可能容量不足、且 buffer cache 在低 ACU 時被壓縮、回升後 cache 重新暖機、query latency 短暫升高。對延遲敏感、又有規律日週期的 workload，min ACU 不要壓到極限。

max ACU 太低：尖峰被天花板卡住、等同 provisioned 的 instance class 上限問題又回來。max ACU 要按「預期尖峰 + 餘量」設，並把它當成成本天花板來監控——max 設太高雖然不會平時就花錢，但失控 query（如缺索引的全表掃描）可能把 ACU 一路推到 max、帳單尖峰。

暖容量考量：min ACU 同時決定「保留多少隨時可用的暖容量」。完全不可預測、且要求第一個請求就低延遲的場景，min ACU 要留足暖機水位，不能為了省錢設到最低。

混合 cluster：serverless + provisioned 並存

Serverless v2 不是「整個 cluster 要嘛全 serverless、要嘛全 provisioned」。同一個 Aurora cluster 可以混用：writer 用 provisioned 保穩定、read replica 用 serverless v2 吸收讀取尖峰；或反過來。這讓 workload 的不同部分各取所需：

• 穩定的寫入路徑用 provisioned instance、成本可預測
• 間歇的讀取分析、報表副本用 serverless v2、平時縮到低水位
• failover 目標可指定 provisioned 或 serverless，依可用性需求

混合配置的判讀是把 cluster 內每個角色當獨立的負載形狀評估，而非整個 cluster 一刀切。

操作流程

從負載形狀評估到上線的 6 步流程。

Step 1：判斷負載形狀

用 CloudWatch 過去 30 天的 CPU / connection / IOPS，看負載是穩定平緩、規律日週期、還是不規則突發：

• 穩定高負載（平均使用率高、波動小）→ provisioned 通常更划算
• 間歇 / 突發 / 開發測試 / 多租戶各自小 DB → serverless v2 適合
• 規律日週期（白天高晚上低）→ serverless v2 或 provisioned + scheduled 都可，算成本 crossover

Step 2：估 min / max ACU

min 依離峰最低負載 + 暖容量需求；max 依尖峰負載 + 餘量。第一次設保守一點、上線後依實際 ACU 曲線收斂。

Step 3：建立或轉換

1# 新 cluster 指定 serverless v2 capacity range
2aws rds create-db-cluster \
3  --db-cluster-identifier my-cluster \
4  --engine aurora-postgresql \
5  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=32

既有 provisioned cluster 可加 serverless v2 reader、逐步驗證再調整 writer。

Step 4：觀察 ACU 曲線

上線後盯 ServerlessDatabaseCapacity（即時 ACU）與 ACUUtilization，確認伸縮符合負載、min/max 設定合理。

Step 5：成本對照

把實際 ACU-秒換算的帳單，跟「同等 provisioned instance 全時段開機」對照。若 serverless 帳單接近或超過 provisioned，代表負載其實夠穩定、該回 provisioned。

Step 6：驗證點

1# 驗證離峰真的縮到 min ACU（看 ServerlessDatabaseCapacity 低谷）
2# 驗證尖峰沒撞 max ACU 天花板（看是否長時間貼著 max）
3# 驗證回升期 latency 可接受（min ACU 暖容量是否足夠）

Rollback boundary：serverless v2 與 provisioned 可互轉、reader 先轉驗證再動 writer；轉換本身有短暫中斷，要排 maintenance window。

失敗模式

production 常見的 5 個踩雷：

Case 1：穩定高負載用 serverless 反而更貴

把一個 7x24 高使用率的 cluster 改 serverless「以為省錢」，實際 ACU 幾乎全時段貼近高水位、按 ACU-秒計費比固定 instance 貴。修法：穩定高負載用 provisioned；serverless 的省錢前提是「有顯著的離峰可以縮」。

Case 2：min ACU 設太低、回升期 latency 尖刺

離峰縮到極低、早上流量回來時 cache 冷、ACU 從低水位爬、前幾分鐘 query 變慢。修法：規律日週期的 workload，min ACU 留足暖容量；或用 provisioned + scheduled scaling 處理可預測的日週期。

Case 3：max ACU 沒當成本天花板監控

缺索引的 query 觸發全表掃描、ACU 一路衝到 max、帳單尖峰才發現。修法：max ACU 設合理上限 + CloudWatch alarm 盯 ACU 長時間貼 max（那是 query 或容量問題的訊號，不是正常擴縮）。

Case 4：把 serverless 當「不用做容量規劃」

以為 serverless 自動伸縮就不必估容量、min/max 隨便設。修法：serverless 改變的是「不用手動切 instance」，不是「不用理解負載形狀」；min/max 仍要基於負載曲線設定。

Case 5：對延遲極敏感的 OLTP 全 serverless

核心交易路徑要求穩定低延遲、卻用會伸縮的 serverless writer、伸縮邊界期間 latency 抖動。修法：穩定低延遲的核心寫入用 provisioned writer，serverless 留給可容忍伸縮抖動的讀取 / 分析副本（混合 cluster）。

Anti-recommendation：負載穩定、使用率長期偏高、或對延遲抖動零容忍的核心 OLTP → 用 provisioned；serverless v2 的價值在「間歇、突發、難預測、或有大量離峰」的負載，沒有離峰可縮就沒有省錢空間。

容量與觀測

CloudWatch metric：

• ServerlessDatabaseCapacity：即時 ACU、看伸縮曲線
• ACUUtilization：ACU 使用率、判斷 min/max 設定是否合理
• CPUUtilization / DatabaseConnections：底層負載、對照 ACU 是否跟得上

判讀：

• ACU 長時間貼近 max → max 設太低或有失控 query，要查
• ACU 長時間貼近 min 且使用率低 → 負載其實很輕，min 可能可再降、或這個 cluster 適合更小配置
• ACU 幾乎不波動且水位高 → 負載穩定，serverless 沒發揮價值，評估改 provisioned

Scope warning：本文未引用 production case 的 ACU 數字；上述 metric 與判讀屬 vendor 規格 + 通用容量工程。

接回 9.6 容量規劃模型、Aurora 容量規劃要點。

邊界與整合

Serverless v2 vs provisioned + scheduled scaling

兩者都能處理「負載隨時間變」，但適用場景不同：

• scheduled scaling（provisioned）：負載 可預測（已知的日週期、已知大活動）→ 預先排程改容量，成本最可控
• serverless v2：負載 不可預測（突發、不規則）→ 自動伸縮吸收，不需預測

可預測的尖峰用 scheduled、不可預測的用 serverless，這跟 DynamoDB capacity mode 的 predictable-peak vs flash-sale 判讀同源。

Sibling 與 cross-link

• storage-architecture — serverless 只改 compute 層容量、storage 層 quorum 設計不變
• read-replica-scaling — serverless reader 吸收讀取尖峰、與 fleet 治理結合
• Aurora I/O-Optimized cost — serverless 算的是 compute（ACU）成本、I/O-Optimized 算的是 storage I/O 成本，兩個成本軸獨立、要分開評估
• rds-proxy-connection-pooling — serverless + Lambda 場景的連線管理
• 替代路由：負載穩定且高 → provisioned；KV access pattern → DynamoDB
• 跟 Netflix 9.C23 互引：polyglot 架構下不同 workload 用不同 Aurora 配置（穩定 OLTP provisioned、間歇副本 serverless）

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 cluster 邊界劃分與多 cluster 治理的實作層教學。

共用大 cluster 的根本問題：blast radius

單一大 cluster 把多個業務的失敗耦合在一起。一個業務的異常會透過共用資源外溢到其他業務：

• 資源競爭：connection pool、CPU、IOPS、buffer cache 共用，一個業務的尖峰擠壓其他業務
• failure blast radius：cluster 故障 / 升級 / schema 變更鎖表，影響所有掛在上面的業務
• 容量規劃糾纏：要為「所有業務尖峰的總和」規劃容量，無法針對單一業務調整
• schema change 互相牽制：一個業務的 migration 鎖表、其他業務跟著受影響

按業務切 cluster 的核心價值是把這些耦合切開——每個 cluster 的故障、容量、變更只影響自己的業務範圍。

切分判斷維度

不是「每個服務都該有自己的 cluster」（那會走向另一個極端：cluster 數爆炸、運維 surface 失控）。切分依以下維度判斷：

9.C23 Netflix 是這個判斷的 case anchor：Netflix 把過往多套不同 種類 的關聯式 DB（PostgreSQL / MySQL / Oracle）整合到 Aurora、效能提升最高 75%、成本下降 28%；但整合的是「DB 種類 / 運維 surface」，不是 把所有資料塞進一個 cluster——Netflix 的微服務各自擁有自己的 Aurora cluster、彼此不共用。兩件事同時成立：減少 DB 技術種類 降低運維知識負擔、同時維持 per-service cluster 隔離 blast radius。

Scope warning：Netflix 的「+75% 效能 / -28% 成本」是跨多 workload 的最大改善幅度、非每個 workload 都 +75%（case 原文已標明）；且 Netflix 數據層遠不止 Aurora（還有 Cassandra / EVCache / Iceberg），Aurora 承擔的是需要 ACID 的 OLTP。引用時不可外推成「整合到 Aurora 就 +75%」。

兩種切分哲學的對照

大規模平台的 cluster 切分沒有單一正解，光譜兩端各有代表：

• per-service 私有 store（Netflix 式）：每個微服務一個 Aurora cluster、容量規劃變成「每個服務各自規劃」、跨服務 contention 變成 網路議題 而非 DB lock 議題
• 高度 consolidation：少數大 cluster 承載多業務、運維實例少、但 blast radius 大

實務多落在中間：核心 / 高關鍵 / 合規敏感業務各自獨立 cluster，低關鍵性的內部服務可數個共用一個 cluster。判斷的是「這群業務能不能接受共命運」。

Fleet 治理：切分後的一致性

切成多 cluster 後，運維 surface 從「一個 cluster」變成「N 個 cluster」。若沒有治理一致性，N 個 cluster 各自飄移會比一個大 cluster 更難維護。fleet 治理要把以下標準化：

• 配置一致：engine 版本、parameter group、backup 策略、加密設定用 IaC 統一管理，避免逐個手調漂移
• 監控一致：每個 cluster 同一套 CloudWatch alarm 基線（connection / replication lag / CPU / IOPS），不是只盯總量
• 升級協調：major version 升級分批跨 fleet，不是一次全升（也不是放任各 cluster 版本散落）
• 成本歸屬：按 cluster / 業務 tag 切成本，讓每個業務看見自己的 DB 成本

這層治理對應 read-replica-scaling 的 fleet 治理段——讀副本 fleet 與多 cluster fleet 共用「N 個實例如何維持治理一致」的方法。

失敗模式

production 常見的踩雷：

Case 1：共用大 cluster、報表 query 拖垮交易

分析 / 報表 workload 跟核心交易共用 cluster、一個重 query 佔滿資源、交易延遲飆高。修法：分析類 workload 切到獨立 cluster 或獨立 read replica；核心交易的 cluster 不混入不可控的分析查詢。

Case 2：cluster 切太細、運維 surface 爆炸

矯枉過正、每個小服務都獨立 cluster、結果幾十個 cluster 各自飄移、升級與監控成本失控。修法：低關鍵性、負載相近、可共命運的服務合併共用 cluster；切分以「blast radius 需求」為準，不是「每個服務都要」。

Case 3：切分了 cluster 但沒切分 fleet 治理

多 cluster 各自手調 parameter group、版本散落、backup 策略不一、出事才發現某個 cluster 設定漂移。修法：fleet 配置用 IaC 統一、監控基線一致、升級分批協調。

Case 4：跨 cluster 交易需求才發現切錯邊界

把本該強一致綁在一起的資料切到不同 cluster、結果需要跨 cluster 交易（Aurora 不提供跨 cluster transaction）、application 層自己補償、複雜又易錯。修法：cluster 邊界要對齊 transaction boundary——必須在同一個交易內一起成功失敗的資料，放同一 cluster（對應 1.3 transaction 與一致性邊界）。這是切分前就要確認的邊界，切錯後重切成本高。

Anti-recommendation：團隊規模小、服務少、無合規隔離需求、且負載總量單一 cluster 撐得住 → 不要預先切成多 cluster；多 cluster 的治理成本只在「blast radius 隔離 / 合規分艙 / 負載差異大」真正需要時才值得。從少到多容易，從多合併回少要資料遷移。

容量與觀測

• 每個 cluster 獨立的 CloudWatch 基線：DatabaseConnections / CPUUtilization / AuroraReplicaLag / IOPS
• 跨 fleet 的成本 dashboard：按 cluster / 業務 tag 歸屬，看哪個業務的 DB 成本成長最快
• blast radius 演練：定期確認單一 cluster 故障不會外溢到其他業務（混沌測試）

Scope warning：本文未引用 production case 的 cluster 數量 / 容量數字；切分維度與治理項屬通用平台工程 + Netflix consolidation 的架構訊號。

接回 9.6 容量規劃模型、05 部署平台模組 的 service decomposition。

邊界與整合

cluster 邊界 vs 微服務邊界

多 cluster 切分常跟微服務拆分一起發生，但兩者不必一一對應。一個微服務可以擁有一個 cluster（Netflix 式私有 store），數個低關鍵微服務也可共用一個 cluster。判斷錨點是 transaction boundary 與 blast radius，不是「服務數 = cluster 數」。當切分壓力其實來自「不同資料模型」而非「隔離需求」，可能該考慮的是 polyglot persistence（OLTP 用 Aurora、KV 用 DynamoDB、analytics 用數倉），而非切更多 Aurora cluster。

Sibling 與 cross-link

• read-replica-scaling — fleet 治理方法共用、讀副本 fleet 與多 cluster fleet 同源
• cross-az-failover-rto — 每個 cluster 的 failover 行為、blast radius 隔離後各自獨立
• serverless-v2-scaling — 低關鍵 / 間歇負載的 cluster 可用 serverless 降離峰成本
• 1.8 State Ownership 與 Query Boundary — cluster 邊界對齊狀態 ownership
• 替代路由：切分壓力來自資料模型差異 → polyglot persistence、回 00 服務選型模組
• 跟 Netflix 9.C23 互引：DB 種類 consolidation + per-service cluster 隔離雙重成立的架構

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 RDS Proxy 連線管理機制與陷阱的實作層教學。

核心機制：connection multiplexing

RDS Proxy 維護一個到 Aurora 的後端連線池，多個 client 連線共享這些後端連線。當 client 連線閒置（交易之間沒有活動），proxy 可以把對應的後端連線釋放回池子給其他 client 用：

multiplexing 生效的前提是 client 連線「閒置時可以被借走」。這只在連線處於 交易之間 的乾淨狀態時成立——一旦連線帶了交易內狀態，proxy 不能把它借給別人，這就是 pinning。

Scope warning：「RDS Proxy 支援的 engine / 連線數上限 / IAM 認證細節」屬 AWS vendor 規格、實作時 cross-verify 官方 doc 當前值。本文不含 production case 揭露的 proxy 配置數字。

對應 knowledge card：connection pool。

Pinning：multiplexing 失效的主因

Pinning 是 RDS Proxy 最常被忽略、卻直接決定省連線效果的機制。當 client 在連線上做了「跨交易持續的 session 狀態」操作，proxy 無法安全地把這條後端連線借給其他 client，於是把它 pin（綁定）到該 client 直到連線關閉——這條後端連線在 pin 期間不參與 multiplexing。

常見觸發 pinning 的操作：

• session 層級的變數設定（SET 某些 session variable）
• 建立 temp table
• prepared statement（某些情況）
• advisory lock、保持開啟的交易
• 部分 session 層級的設定語句

pinning 的後果是「明明裝了 RDS Proxy、後端連線數卻沒降下來」。若大量 client 都觸發 pinning，等於退化回「一個 client 一條後端連線」、proxy 白裝。

判讀與修法方向：

• 監控 DatabaseConnectionsCurrentlySessionPinned，看 pinning 比例
• application 端避免不必要的 session 狀態（少用 session variable、temp table；改用交易內可清理的方式）
• 真的需要 session 狀態的 workload，接受該連線會 pin、或評估這類 workload 是否適合走 proxy

Scope warning：「哪些具體語句觸發 pinning」隨 RDS Proxy 版本與 engine 演進、實作時以 AWS doc 當前清單為準；本段列舉是常見類型、非完整或固定清單。

Failover 加速

RDS Proxy 的第二個價值是縮短 failover 對 application 的中斷。沒有 proxy 時，writer failover 會讓所有 client 連線斷掉、application 要偵測、重連、重建連線池；有 proxy 時，proxy 保持與 client 的連線、在後端把流量切到新 writer，client 端感知到的中斷時間縮短。

這對連線建立成本高、或 failover 期間不能大量重連的 workload 特別有價值。但 proxy 不消除 failover 本身——in-flight 的交易仍會失敗、application 仍要有 retry；proxy 縮短的是「重建連線」這段，不是「交易不中斷」。

操作流程

從連線壓力判讀到上線的 6 步流程。

Step 1：確認是不是連線問題

先區分「Aurora 容量不夠」vs「連線管理問題」。看 DatabaseConnections 是否逼近上限、且 CPU/IOPS 還有餘量——後者是典型的連線數問題、proxy 能解；若是 CPU/IOPS 飽和，proxy 不解。

Step 2：判斷 workload 是否適合 proxy

• serverless / Lambda / 高並發短連線 → 適合（連線爆炸是主問題）
• 少量長連線、穩定的 application server → proxy 效益有限（連線數本就可控）
• 大量 session 狀態 workload → pinning 會吃掉 multiplexing 效益、要先評估

Step 3：建立 proxy

1aws rds create-db-proxy \
2  --db-proxy-name my-aurora-proxy \
3  --engine-family POSTGRESQL \
4  --auth ... \
5  --role-arn ... \
6  --vpc-subnet-ids ...

application 連到 proxy endpoint 而非直連 cluster endpoint。

Step 4：減少 pinning

review application 的 session 狀態使用、移除不必要的 SET / temp table；連線池設定避免長時間持有閒置連線。

Step 5：驗證 multiplexing 生效

1# 對照後端連線數：裝 proxy 後 Aurora 的 DatabaseConnections 應顯著低於 client 並發數
2# 看 DatabaseConnectionsCurrentlySessionPinned：pinning 比例高代表 multiplexing 沒發揮

Step 6：驗證 failover 行為

主動觸發一次 failover、測量 application 感知到的中斷時間、確認 retry 邏輯能吸收 in-flight 交易失敗。

Rollback boundary：application 可在 proxy endpoint 與直連 cluster endpoint 間切換、proxy 出問題時改回直連（但直連會回到連線爆炸風險，要先確認後端撐得住）。

失敗模式

production 常見的 5 個踩雷：

Case 1：裝了 proxy 但 pinning 比例高、連線沒降

application 大量用 session variable / temp table、多數連線被 pin、後端連線數沒降、proxy 白裝。修法：監控 pinning 比例、減少 session 狀態；理解 proxy 的省連線前提是連線可被借走。

Case 2：把 proxy 當「Aurora 容量擴充」

連線數沒問題、是 CPU/IOPS 飽和、卻裝 proxy 期待變快。修法：proxy 解連線管理、不解運算容量；容量問題要擴 instance / 加 replica。

Case 3：以為 proxy 讓 failover 零中斷

裝了 proxy 就拿掉 application 的 retry、failover 時 in-flight 交易失敗沒處理。修法：proxy 縮短重連時間、不保證交易不中斷；application 仍要 retry in-flight 交易。

Case 4：少量長連線 workload 強裝 proxy

穩定的 application server 連線數本就可控、裝 proxy 多一跳延遲、效益有限。修法：proxy 的價值在連線爆炸場景（serverless / 高並發短連線）；連線可控的 workload 不必加。

Case 5：proxy 與自管 pooler 疊加未理清責任

application 已有自管連線池（如語言層 pool）、又加 RDS Proxy、兩層 pool 互相打架、連線數行為難預測。修法：理清兩層職責——application 層 pool 管「app 到 proxy」、proxy 管「proxy 到 Aurora」；兩層設定要協調、不是各設各的。

Anti-recommendation：連線數本就可控的少量長連線 workload、或 workload 大量依賴 session 狀態（pinning 會吃掉效益）→ 不必上 RDS Proxy；它的價值集中在 serverless / Lambda / 高並發短連線的連線爆炸場景。

容量與觀測

CloudWatch metric：

• DatabaseConnections（Aurora 端）：裝 proxy 後應顯著低於 client 並發數
• DatabaseConnectionsCurrentlySessionPinned：pinning 數、判斷 multiplexing 效益
• ClientConnections（proxy 端）：client 側連線數、對照後端收斂比例
• QueryDatabaseResponseLatency：proxy 多一跳的延遲影響

判讀：

• 後端連線數沒因 proxy 下降 → pinning 比例高或 workload 不適合
• pinning 數持續高 → application session 狀態過多、需 review
• proxy 延遲明顯 → 評估這一跳對延遲敏感路徑是否值得

Scope warning：本文未引用 production case 的 proxy metric 數字；上述指標與判讀屬 vendor 規格 + 通用連線管理工程。

接回 9.5 瓶頸定位流程、1.1 高併發下的 SQL 讀寫邊界。

邊界與整合

RDS Proxy vs 自管 pgbouncer

兩者都是 connection pooler，責任切分在「managed vs 自管」：

• RDS Proxy：AWS managed、跟 Aurora / IAM / Secrets Manager 整合、零運維、含 failover 加速；綁 AWS
• 自管 pgbouncer / pgcat：自己部署運維、pooling 模式（session / transaction / statement）可細調、跨雲可攜；運維責任自負

PostgreSQL 的通用連線池機制與 pgbouncer 細節主寫於 pgbouncer-config 與 connection-pooler-comparison；本篇聚焦 RDS Proxy 這個 AWS managed 方案的機制與 pinning 陷阱。要細調 pooling 模式、或需要跨雲可攜 → 評估自管 pooler；要零運維 + Aurora 原生整合 + failover 加速 → RDS Proxy。

Sibling 與 cross-link

• serverless-v2-scaling — serverless + Lambda 場景的連線管理常與 RDS Proxy 一起出現
• cross-az-failover-rto — proxy 縮短 failover 重連時間、與 RTO 目標結合
• pgbouncer-config / connection-pooler-comparison — 通用連線池 SSoT、自管方案對照
• 1.1 高併發下的 SQL 讀寫邊界 — 連線池與 transaction 範圍控制
• 替代路由：需要細調 pooling 模式 / 跨雲 → 自管 pgbouncer

本文是 Aurora family 內的決策取捨文章。聚焦 standard Aurora（Aurora PostgreSQL / MySQL，single-region managed SQL） 跟 Aurora DSQL（active-active distributed SQL） 之間的升級門檻判斷。兩個既有 SSoT 不在本篇重複：「PG → DSQL 怎麼遷」見 migrate-to-aurora-dsql；「DSQL vs Spanner vs CockroachDB 三方 distributed SQL 選型」見 aurora-dsql-spanner-decision-tree。本篇只回答「standard Aurora 夠不夠、要不要跨過去」。

多數團隊不需要 Aurora DSQL。Aurora PostgreSQL / MySQL 已經是 managed SQL、storage / compute 分離、跨 AZ 高可用、read replica 擴讀——絕大多數 OLTP workload 在這層就解決了。Aurora DSQL 是 2024-12 re:Invent preview、2025-05 GA 的 不同 paradigm 產品：PG wire-compatible 但底層是 active-active distributed、OCC + snapshot isolation、multi-region strong consistency。它解的是 standard Aurora 解不了 的特定問題，代價是放棄一部分 PostgreSQL 相容性與交易自由度。要不要跨過去，看 workload 是否真的撞到 standard Aurora 的結構上限。

時間錨點：Aurora DSQL 2024-12 preview、2025-05 GA。vendor 能力持續演進、實際決策前以 AWS docs 當前狀態為準。

核心差異：single-writer vs active-active

兩者的根本差異在寫入架構：

standard Aurora 的 storage 層雖然分散，compute 寫入仍是 single writer——這是它的結構上限。DSQL 把寫入也分散，代價是 SQL 相容性縮窄（PG 子集、extension 缺位）與交易語意改變（OCC，衝突要 application retry）。

該跨到 DSQL 的訊號

只有撞到 standard Aurora 結構上限的特定需求，才值得跨 paradigm：

• global write（多 region 都要低延遲寫入）：standard Aurora 跨 region 只有非同步副本、寫入要回到單一 writer region；真正需要多 region active-active 寫入 → DSQL
• single-writer 寫入上限撞牆：寫入量大到單一 writer instance（即使最大 instance class）撐不住、且無法用 sharding 簡單解 → DSQL 的水平寫入擴展
• region resiliency（單 region 失效仍要可寫）：standard Aurora 的跨 region failover 有 RPO/RTO 與寫入中斷；要求單 region 失效時其他 region 仍持續接受寫入 → DSQL active-active
• operational zero-touch：不想管 instance / failover / 容量 → DSQL serverless 模型（但這單項不足以跨 paradigm、要搭配上面的結構需求）

不該跨的訊號（standard Aurora 夠用）

以下情況跨 DSQL 是過度工程、且會付出相容性代價：

• single-region 夠用：寫入集中在一個 region、跨 region 只需要讀副本或 DR → standard Aurora
• 需要 PostgreSQL extension：依賴 PostGIS / pgvector / 特定 extension → DSQL 子集不支援、留 standard Aurora
• 複雜 / 長交易：依賴長交易、複雜多語句交易、特定 isolation 行為 → standard Aurora 的完整交易模型
• 寫入量 standard Aurora 撐得住：single writer 還有餘量 → 不必為「未來可能」預先跨 paradigm

9.C14 Standard Chartered 與 9.C4 DraftKings 是反向佐證：金融帳本 / 博彩這類高一致性、高關鍵 OLTP workload，在 standard Aurora 上就能同時拿到韌性與性能（DraftKings replication lag 降到 10-30ms 級、Standard Chartered 把韌性與性能當單一目標）。它們沒有跨到 distributed SQL——因為 single-region 強一致 + 跨 AZ 高可用已滿足需求。多數金融 OLTP 不需要 active-active multi-region write。

Scope warning：Standard Chartered / DraftKings 的 case 揭露其用 standard Aurora 達成韌性 + 性能（見 storage-architecture）；「它們不需要 DSQL」是本文基於其 single-region 強一致需求的推論、非 case 明文比較 DSQL。引用為「standard Aurora 已足夠多數高一致 OLTP」的訊號、不當 DSQL 對比的 case fact。

升級門檻決策流程

從需求判讀到路徑選擇的流程：

Step 1：確認是不是 global write 需求

寫入是否真的需要多 region 同時低延遲？還是只需要多 region 讀 + 單 region 寫？後者 standard Aurora（+ Global Database 讀副本）就解。

Step 2：確認 single-writer 是否真的撞牆

當前寫入量 vs 最大 instance class 上限、是否已嘗試過 read/write 分離、是否能用 application 層 sharding。撞牆才考慮 DSQL；沒撞牆是過早優化。

Step 3：檢查相容性代價

清點對 PG extension、長交易、特定 SQL 功能的依賴。依賴重 → DSQL 相容性子集會擋路、留 standard Aurora。

Step 4：若決定跨，走既有 SSoT

• 「PG → DSQL 怎麼遷」（protocol drop-in + paradigm shift、transaction retry 處理、extension 缺位）→ migrate-to-aurora-dsql
• 「DSQL vs Spanner vs CockroachDB 哪個 distributed SQL」→ aurora-dsql-spanner-decision-tree

Rollback boundary：跨 paradigm 是高成本決策——DSQL 子集相容性與 OCC 交易模型改變了 application 契約，回退到 standard Aurora 不是改 connection string 就好。決策前用一個非關鍵 workload 試點、確認相容性與 retry 行為，再擴大。

邊界與整合

為什麼這是「升級門檻」而非「遷移」

standard Aurora → DSQL 不是版本升級、是 paradigm 切換。Aurora PG/MySQL 用得好好的，不代表「升級到 DSQL 會更好」——多數情況會更差（失去 extension、交易要改、相容性縮窄）。只有 workload 真的需要 active-active multi-region write 或撞到 single-writer 上限，跨過去才划算。這跟「PostgreSQL major version upgrade」（同 paradigm、向後相容）是完全不同性質的決策。

Sibling 與 cross-link

• storage-architecture — standard Aurora 的 storage 分散但 compute single-writer 的結構上限根源
• global-database-multi-region — standard Aurora 的多 region 方案（非同步副本）、global write 需求前先確認這層夠不夠
• migrate-to-aurora-dsql — 決定跨之後的遷移 playbook（SSoT）
• aurora-dsql-spanner-decision-tree — 三方 distributed SQL 選型（SSoT）
• 替代路由：single-region 夠 → 留 standard Aurora；KV access pattern → DynamoDB
• 跟 Standard Chartered 9.C14 / DraftKings 9.C4 互引：高一致 OLTP 在 standard Aurora 已足夠的訊號

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 failover 流程的實作層教學。前置閱讀建議 Aurora storage architecture（理解為什麼 Aurora failover 不需要 data catch-up）。

問題情境

典型觸發場景：DraftKings / Standard Chartered 等級的金融交易服務、AZ-level outage 期間用戶操作不能斷、RTO 預算 < 60 秒、但 application 端看到的 reconnect 行為跟 AWS 文件不一致。

讀者常見的具體疑問：

• 「Failover trigger 後新 connection 還連到舊 primary、為什麼？」
• 「Writer endpoint DNS 切換了、application 還沒重連、什麼時候會切？」
• 「Failover 期間 in-flight transaction 是全 abort 還是部分 commit？」
• 「我手動測 failover RTO 量出 90 秒、AWS 文件講 < 30 秒、誰錯？」

進一步問題：失敗模式分布在 application 端的 connection state、不只是 Aurora 端的 promotion 流程。Aurora 端的 promotion 在 storage 共享下確實 < 30 秒（不需要等 data catch-up）、但 application reconnect 受 JVM DNS cache、connection pool validation、retry policy 影響、容易把總體 RTO 拉長到 2-3 倍。

對 Standard Chartered 這種受監管銀行業務、failover 還有合規維度：受監管市場資料 不能跨境複製、Global Database 在這種場景違反合規、必須用每市場獨立 cluster 的 cross-AZ failover 吸收 RTO 預算。這個 driver 跟一般工程「跨 region failover 更好」的直覺相反。

核心機制：failover lifecycle 三段

Aurora cross-AZ failover 的 first-class concept 是 failover lifecycle 三段：detection → promotion → DNS update。每一段有自己的 SLA 跟可調維度。

Detection（10-15 秒）：

• AWS 內部 health check 每幾秒檢查 primary writer health
• 連續失敗到一定閾值才 trigger failover（避免 false positive）
• 讀者無法直接調 detection 閾值、是 AWS managed

Promotion（< 5 秒）：

• 選 PromotionTier 最低的 read replica 升 primary
• Storage 跨 AZ 共享、replica 升 primary 不需要 data catch-up（vs 傳統 PostgreSQL streaming replication 要等 WAL apply）
• Promotion 本身極快、是 Aurora storage 設計的直接受益

DNS update（5-15 秒）：

• Cluster endpoint / writer endpoint DNS 切到新 primary
• Aurora endpoint DNS TTL 是 5 秒、AWS DNS infrastructure 通常 5-15 秒 propagate 完
• 但 application 端的 DNS cache 可能 cache 更久 — JVM networkaddress.cache.ttl 預設 -1（cache forever）就會卡在這層

Endpoint 類型跟 failover 行為：

• Writer endpoint：跟著 failover 走、DNS 切到新 primary、application 寫操作用這個
• Reader endpoint：load-balance 到所有 replica；failover 期間短暫包含 promoted replica（已升 primary）、reader query 可能打到 primary、引起寫鎖競爭
• Custom endpoint：用戶自定 routing rule、failover 期間行為要驗證、不能假設自動跟隨

跟通用 failover 差在哪：Aurora 不需要 data catch-up phase、failover 主要瓶頸是 DNS propagation + application reconnect、不是 promotion 本身。傳統 PostgreSQL streaming replication failover 要等 replica WAL catch-up（heavy write 期間可能秒級延遲）、Aurora 在 storage 設計下消除這段等待。

對應 knowledge card：failover、rto、rpo。

Step-by-step 配置 / 量測

Cluster failover 配置：

 1# 確認 cluster 至少有一個跨 AZ replica
 2aws rds describe-db-clusters \
 3  --db-cluster-identifier my-cluster \
 4  --query 'DBClusters[0].DBClusterMembers'
 5
 6# 設定 PromotionTier（0 最優先、15 最不優先）
 7aws rds modify-db-instance \
 8  --db-instance-identifier my-replica-az-b \
 9  --promotion-tier 0
10
11# 跨 region replica 預設 tier 15（不優先升、避免 failover 跨 region）
12aws rds modify-db-instance \
13  --db-instance-identifier my-cross-region-replica \
14  --promotion-tier 15

Application 端 JVM 設定（最常踩雷的點）：

1# JVM 系統 property、預設 -1 = cache forever、必改
2networkaddress.cache.ttl=5
3networkaddress.cache.negative.ttl=0

Connection pool 設定（HikariCP 範例）：

1spring.datasource.hikari:
2  maximum-pool-size: 30
3  connection-test-query: "SELECT 1"
4  validation-timeout: 5000
5  max-lifetime: 1800000      # 30 分鐘、強制 recycle connection
6  keepalive-time: 30000      # 30 秒檢查 idle connection
7  connection-timeout: 30000

Retry policy：

1// 簡化範例、實際用 Resilience4j 或 Failsafe
2RetryPolicy<Object> retryPolicy = RetryPolicy.builder()
3    .handle(SQLTransientConnectionException.class, SQLNonTransientConnectionException.class)
4    .withBackoff(Duration.ofSeconds(1), Duration.ofSeconds(30))
5    .withMaxAttempts(5)
6    .build();

手動觸發 failover 量測 RTO：

1# 觸發 failover、記錄時間
2START=$(date +%s%3N)
3aws rds failover-db-cluster --db-cluster-identifier my-cluster
4echo "Failover triggered at $START ms"
5
6# 用 application heartbeat 寫入時間戳
7# application 端跑 every-second insert、failover 後第一個成功 insert 的時間 - START = RTO

驗證點：

• CloudWatch FailoverEvent counter > 0（failover 觸發訊號）
• DatabaseConnections 在 failover 期間 drop > 50%、之後 spike（reconnect 風暴）
• Application metric「first successful write after failover trigger」< 30 秒

Rollback boundary：promotion 不可逆 — 原 primary 變 replica、不會自動 fallback。要切回原 AZ 必須再做一次 failover。

故障模式 / 邊界 case

Case 1：DNS cache 把 RTO 從 30 秒拉到 120 秒

徵兆：手動 failover 後、CloudWatch FailoverEvent 1 秒內出現、但 application log 顯示寫操作 120 秒後才恢復。

原因：JVM networkaddress.cache.ttl 預設 -1（cache forever）、application JVM 把 writer endpoint DNS 永久 cache 到舊 primary IP；只有 connection pool eviction 或 application restart 才會重新 resolve。

修：

• JVM startup 加 -Dnetworkaddress.cache.ttl=5
• 或在 $JAVA_HOME/lib/security/java.security 改 networkaddress.cache.ttl=5
• Python application 通常沒這問題（DNS resolve per connection）、但要確認 SQLAlchemy 用 pool_pre_ping=True

Case 2：Connection pool cached connection 全 stale

徵兆：DNS 切換 OK、但 application 寫操作 timeout 10-30 秒後才觸發 reconnect、p99 latency spike。

原因：connection pool 的 cached connection 還指向舊 primary IP、validation 沒開或 timeout 太長、application 拿到 stale connection 才發現 backend gone。

修：

• HikariCP：connection-test-query: "SELECT 1" + validation-timeout: 5000 + keepalive-time: 30000
• SQLAlchemy：pool_pre_ping=True + pool_recycle=1800
• failover 演練後驗證 connection pool 在 30 秒內 evict 完所有 stale connection

Case 3：Reader endpoint failover 期間打到新 primary

徵兆：failover 期間 application read query 偶發出現 cannot execute SELECT in a read-only transaction 或寫鎖競爭、用戶看到 inconsistent state。

原因：reader endpoint 是 DNS-based load balance 到所有 replica、failover 期間 短暫 包含已升 primary 的 replica（DNS propagation 期間 reader 跟 writer endpoint 都指向同一台）。Read query 打到 primary 後、跟正在寫的 transaction 競爭。

修：

• Application 端 read 跟 write data source 拆分、不要假設 reader endpoint 永遠 read-only
• Failover 期間 application 端做 SQL error type 偵測、read-only transaction 錯誤觸發 retry
• 用 custom endpoint group 特定 replica、failover 期間 custom endpoint 行為更可控

Case 4：In-flight transaction 全 abort

徵兆：failover 期間正在執行的 transaction 全部 abort、application 看到 connection reset 或 server closed connection、commit 沒成功。

原因：Aurora failover 不保留 transaction 狀態、所有 in-flight transaction（包括已執行 BEGIN 但還沒 COMMIT 的）全 abort。Application 沒做 idempotent retry 就會丟失 commit。

修：

• 寫操作必須 idempotent（用 idempotency key、application 端做 deduplication）
• 在 application 層做 transaction-level retry、不在 connection 層 retry
• 重要寫入做 write-then-verify 模式：commit 後立刻 SELECT 確認、失敗才 retry

Case 5：PromotionTier 配置忽略

徵兆：failover 後 application latency 暴漲、發現升 primary 的是 cross-region replica。

原因：cross-region replica 預設 PromotionTier 是 1（或忘記改）、failover 時優先升、application 跟新 primary 跨 region、latency 從 5ms 變 100ms+。

修：

• cross-region replica --promotion-tier 15（不優先升）
• 同 region 跨 AZ replica --promotion-tier 0 或 1
• Multi-AZ deployment 至少配 2 個 same-region replica、避免 cross-region 被升

Standard Chartered 為什麼選獨立 cluster 而非 Global Database

9.C14 Standard Chartered 揭露受監管產業的 failover 設計選擇 — 案例「判讀」段第 1 點：「7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成『7 個獨立規劃 × 各自合規門檻』」。

合規 driver：

• 受監管市場資料 不能跨境複製
• Aurora Global Database 是跨 region async replication、會把資料推到其他 region
• → Global Database 在這種場景 違反合規、不是 DR 選項
• 必須用每市場獨立 cluster、各自做 cross-AZ failover、各自吸收 RTO 預算

工程含義：

• 每市場 cross-AZ failover RTO < 30 秒、滿足當地監管 RTO 要求
• 跨市場 DR 不靠 Global Database、靠應用層的 市場切換（用戶從 A 市場切到 B 市場是業務決策、不是技術 failover）
• 7 個 cluster 各自獨立、operational surface area × 7（parameter group / backup / IAM / observability fan-out）、但合規要求壓倒運維成本

Fleet 拓樸：合規驅動的 fleet 設計（7 個受監管市場 = 7 個獨立 cluster）詳見 Aurora read replica scaling fleet 治理 SSoT 邊界段。本篇只展開 單 cluster cross-AZ failover 流程、不展開跨 cluster 拓樸決策。

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

容量與觀測

核心 metric：

1FailoverEvent           # failover 觸發 counter、> 0 立即通知
2DatabaseConnections     # failover 期間 drop、之後 spike
3AuroraReplicaLag        # failover 前 replica 是否 caught up

Application 端 metric：

1first_successful_write_after_failover  # 真實 RTO
2connection_pool_error_rate              # stale connection 訊號
3db_retry_count                          # retry policy 觸發頻率

量測 RTO 流程：

1. 跑 application 端 every-second heartbeat insert
2. 手動觸發 failover、記錄 trigger 時間戳
3. 從 heartbeat insert log 找 failover 後第一個成功 insert 的時間戳
4. 差值 = 真實 RTO（包含 detection + promotion + DNS + reconnect）

Alert：

• FailoverEvent > 0 立即通知 on-call
• DatabaseConnections 5 分鐘內 drop > 50% 警告 stale connection
• db_retry_count 短期內 spike 警告 reconnect 風暴

Failover 演練頻率：

• Non-critical workload：每季一次 planned failover drill
• 受監管產業（Standard Chartered 類）：每月一次、有合規 sign-off 記錄
• 重大版本升級前必跑一次

回路徑：8.x incident response failover playbook、9.5 瓶頸定位流程 判斷 reconnect-bound vs query-bound。

邊界與整合 / 下一步

Sibling deep articles：

• Aurora storage architecture — 理解為什麼 Aurora failover 不需要 data catch-up（storage 跨 AZ 共享）
• Aurora read replica scaling — replica 升 primary 流程跟 fleet 治理 SSoT
• Aurora Global Database — 跨 region failover RTO 不同數量級（2-15 分鐘 vs cross-AZ < 30 秒）

Migration playbook：

• PostgreSQL / MySQL → Aurora — HA redesign 是 operational redesign 主項、從 Patroni / Orchestrator 切到 Aurora cluster endpoint

1.x 章節互引：

• 1.3 Transaction Boundary — failover 期間 in-flight transaction abort 對 application 契約的影響
• 8.x incident response — failover decision log

何時不用本文：non-critical workload、RTO 預算 > 5 分鐘、Multi-AZ 預設配置足夠時可跳過、看 Aurora vendor overview 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Failover 卡片 — 概念基底
• RTO 卡片 — RTO 量測判讀
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora high availability

本文是跨 vendor migration playbook、cross-link 到 PostgreSQL（self-managed source）跟 Aurora（cloud-managed target）。跟前兩篇 migration（Splunk → Elastic 高 schema 差 / Redis → DragonflyDB drop-in）對照、本篇是 middle ground：wire protocol drop-in、但 operational model 重設計。每階段切換用 migration gate 把關。

為什麼遷：operational cost / HA / DR 三條 driver

反向 driver（Aurora → self-managed）也存在 — 主要是 cost 在 10TB+ 規模時 Aurora 反而更貴、或 需要 PostgreSQL extension Aurora 不支援（pg_partman / pg_repack / TimescaleDB 等）。

結構：protocol 相容 + operational phased 的混合

跟前兩篇對照、Aurora migration 結構是 protocol drop-in（application 不改 SQL）+ operational redesign（HA / backup / monitoring 全換）：

Hypothesis 驗證：migration playbook 結構由 最大差異維度 決定 — Splunk → Elastic 是 schema 差導向 phased、Aurora migration 是 operational 差導向局部 phased。

Operational redesign 對位

跟 self-managed PostgreSQL 比、Aurora 的 operational 模型差異：

每一條 operational concept 都需要 migration plan、application code 不變但 運維知識體系全換。

Migration 流程：3 phase operational + drop-in cutover

Phase 0：Pre-migration audit（1-2 週）

1. Extension 清單對位：

1SELECT extname, extversion FROM pg_extension;
2-- 對照 Aurora supported extensions list
3-- 不支援的（pg_repack / pg_partman 部分 / TimescaleDB / Citus）需替代方案

2. Custom config 清單：

1SELECT name, setting FROM pg_settings WHERE source != 'default';
2-- 對照 Aurora Parameter Group 可調項目

3. Capacity 評估：

• 當前 IOPS / connection / storage / WAL rate
• 對應 Aurora instance class（db.r6g.large to db.r6g.32xlarge）
• 估算 cost（vCPU + IOPS + storage + backup retention）

4. Application connection pool audit：

• PgBouncer 配置是否能直接搬到 RDS Proxy
• Connection string + IAM 認證準備

Phase 1：Operational infrastructure 準備（2-3 週）

1. 建 Aurora cluster（Terraform / CloudFormation）
2. 設 Parameter Group、對位 self-managed 配置
3. 設 Security Group + IAM role
4. 設 RDS Proxy（推薦、connection 集中管理）
5. CloudWatch alert + Performance Insights baseline
6. Backup retention + PITR window 設定

Phase 2：Data migration（取決於 dataset 大小）

兩條路：

路線 A：AWS DMS（推薦中等規模 < 5TB）

1self-managed Postgres ──(DMS)──→ Aurora
2                         |
3                  full load + CDC continuous

• DMS task 設 Full Load + Ongoing Replication
• 跑 full load 估算（100GB ~ 1-3 小時依 instance class）
• CDC 持續直到 cutover

路線 B：Logical replication（推薦 5TB+ 或要精準控制）

1-- Source：建 publication
2CREATE PUBLICATION migrate_pub FOR ALL TABLES;
3
4-- Aurora：建 subscription
5CREATE SUBSCRIPTION migrate_sub
6  CONNECTION 'host=<source> dbname=<db> user=<replicator>'
7  PUBLICATION migrate_pub;

• Initial COPY 跑完後 streaming
• 詳見 Logical Replication + Debezium

Phase 3：Cutover 跟 verification

11. Application 端設 maintenance mode（block writes）
22. 等 replication lag → 0
33. 確認 Aurora 端 row count + checksum 對齊
44. Application connection string 切到 Aurora endpoint
55. 解除 maintenance mode
66. Self-managed 端 read-only 保留 1-2 週 standby

Cutover window 視 dataset 大小：

• < 100GB：1-2 小時
• 100GB - 1TB：2-4 小時
• 1TB+：考慮 zero-downtime cutover via blue-green deployment

Production 故障演練

Case 1：Extension 不支援、application 直接壞

徵兆：cutover 後 application 某些 query 報 extension "pg_repack" not available、batch job 壞。

根因：Phase 0 audit 漏掉 application 用 pg_repack 做 maintenance；Aurora 不支援、self-managed 端的 cron job 改不過去。

修法：

1. Pre-migration audit 必做：SELECT extname FROM pg_extension 對照 Aurora extension whitelist
2. 替代方案：
   • pg_repack → Aurora 自家 vacuum + storage auto-resize
   • TimescaleDB → 改 declarative partitioning 或換 Timestream
   • Citus → 評估保留 self-managed 或重設計 schema
3. 退役策略：Extension 是 application 必要的、評估暫不遷或選 alternative cloud（如 AlloyDB / Citus on Azure）

Case 2：Replication slot 不直通

徵兆：self-managed 端有 Debezium CDC 接 application 事件、cutover 後 CDC pipeline 直接壞、Kafka 端訊息斷流。

根因：Aurora 對 logical replication slot 有限制 — 不直接支援 external consumer（如 Debezium）讀 slot；要走 RDS Database Events 或 DMS CDC。

修法：

1. Pre-migration audit：列所有 logical consumer（Debezium / Kafka Connect / 自家 CDC）
2. 替代方案：
   • DMS CDC 取代 Debezium（Aurora 原生支援）
   • 評估 RDS Database Activity Streams（newer feature）
   • 重設計 CDC：application 寫 outbox 表、Aurora trigger 發 SNS → Lambda → Kafka
3. 接受代價：CDC pipeline 重建是 2-4 週工作、納入 migration scope

Case 3：Autovacuum 行為跟 self-managed 不同

徵兆：cutover 後幾天、特定 hot table 的 bloat 數據異常、application 端 query latency p99 漲；CloudWatch Performance Insights 顯示 autovacuum 跑頻率比 self-managed 端高 3 倍。

根因：Aurora 預設 Parameter Group 的 autovacuum 配置跟 self-managed 不同 — autovacuum_vacuum_cost_limit 預設更低、vacuum_scale_factor 更激進；shared storage 上 vacuum 行為不一樣。

修法：

1. Parameter Group 對位：把 self-managed autovacuum tuning 配置複製到 Aurora Parameter Group
2. per-table tuning：hot table 的 ALTER TABLE SET (autovacuum_*) 可遷過去
3. 接受差異：Aurora storage 設計讓 vacuum 不一定要跟 self-managed 同 cadence、SRE 心智模型要調

Case 4：IAM 認證強制、application 端改 connection logic

徵兆：production 切到 Aurora 後、application 仍用 password authentication、SOC team 要求改 IAM 認證（compliance）；application 連線 logic 大改、token rotation 邏輯也要加。

根因：self-managed 端用固定 username/password、Aurora 推薦（部分情境強制）IAM authentication；token 15 分鐘輪換、application 必須改連線 SDK。

修法：

1. Migration scope 內包含：authentication migration 是必要工作、不能事後補
2. SDK 整合：用 AWS SDK + RDS Proxy 抽象 token rotation、application 不直接管 token
3. Hybrid 期間：保留 password auth 直到 application 全切 IAM、再 disable password auth

Case 5：Cost model 預估錯、月底帳單炸

徵兆：第一個月 Aurora 帳單比預估高 50-80%；IOPS / backup storage / I/O cost 都比預期多。

根因：Aurora pricing 三層（compute instance / storage / I/O）—

• Storage：actual data + backup × retention
• I/O：每個 read / write block 都計費（self-managed 不算）
• Backup：超過 backup retention 部分 charged as snapshot storage

self-managed 端習慣 fixed EC2 + EBS cost、Aurora I/O-based 計費對 high-IOPS workload 衝擊大。

修法：

1. Pre-migration cost estimate：用 self-managed pg_stat_database 估 I/O 量、套 Aurora pricing calc
2. I/O optimization：開 Aurora I/O-Optimized storage class（fixed monthly + 不算 I/O）、適合 high-IOPS workload
3. Backup retention 控制：不要 default 35 天、依 compliance 調整（7-14 天通常夠）
4. Reserved Instance：穩定 workload 預付 1-3 年、省 30-40%

Capacity / cost 對照

判讀：< 10TB workload Aurora 平攤 operational cost 後仍便宜；50TB+ workload Aurora cost 顯著高、要 reserved + I/O-Optimized 才有競爭力。

整合 / 下一步

跟 Patroni HA 對位

Patroni 在 Aurora migration 後 退役 — Aurora 自家 failover 取代；但 SRE 心智模型要調：

• Patroni 的 pg_rewind 概念不存在（shared storage）
• Patroni 的 synchronous_commit 行為 Aurora 隱藏在 storage layer
• Aurora 跨 region 用 Global Database、不是 Patroni cross-region setup

跟 PITR 對位

self-managed PITR rebuild 工作量大、Aurora PITR 是 native API call：

1aws rds restore-db-cluster-to-point-in-time \
2  --source-db-cluster-identifier myapp-prod \
3  --db-cluster-identifier myapp-prod-restored \
4  --restore-to-time 2026-05-19T14:30:00Z

完全不需要 base backup + WAL replay 思維、storage layer 自動處理。

跟 PgBouncer → RDS Proxy

PgBouncer 多數情境可換 RDS Proxy：

• transaction pooling 等效
• IAM authentication 整合
• Connection pinning（Lambda / serverless workload）
• 限制：RDS Proxy 對某些 PG 14+ feature 仍 catching up、prepared statements 行為差異

下一步議題

• Aurora Serverless v2 評估：variable workload 適合、steady workload 反而貴
• Babelfish 評估：跑 SQL Server protocol on Aurora（多 source 遷移到 Aurora）
• Cross-region DR：Aurora Global Database vs self-managed cross-region streaming + Patroni

相關連結

• Source vendor：PostgreSQL
• Target vendor：Aurora
• 平行 migration playbook：Splunk → Elastic Security / Redis → DragonflyDB
• Aurora family 內進一步遷移：→ Aurora DSQL（從 Aurora PG 升 DSQL active-active distributed、Type E paradigm shift）
• 平行 deep article：Patroni HA / PITR + WAL Archiving / Logical Replication + Debezium
• Methodology：Vendor 深度技術文章的寫作方法論

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 read replica 跟 fleet 拓樸的實作層教學。前置閱讀建議 Aurora storage architecture（理解共享 storage 為什麼能養大量 replica）。

問題情境

典型觸發場景：FanDuel Super Bowl / DraftKings 比賽日、流量 5-10 倍尖峰、read query（用戶查 balance、投注紀錄、odds）打爆 primary、需要快速擴 read replica 但又怕 lag 把 stale read 推到 user-facing。

讀者常見的具體疑問：

• 「加 read replica 後 primary CPU 沒降、為什麼？」
• 「Auto-scaling 加 replica 要幾分鐘、來不及接尖峰怎麼辦？」
• 「Reader endpoint round-robin 把 query 打到 lag 大的 replica、用戶看到舊 balance」
• 「業務跨 200 個 cluster、單個 cluster 才 5-10 個 replica、為什麼不集中？」

進一步問題：讀寫雙峰錯位是 Aurora 讀寫分流的核心 driver。9.C4 DraftKings 揭露「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時讀爆量、payout event 時寫爆量、兩個峰不在同一時刻。這代表 read replica 容量規劃不是「分散負載」、而是「為讀峰專門配置 capacity」。

9.C28 FanDuel 揭露事件型容量分級：平日 baseline → 季後賽 2-3x → 季冠軍賽 4-5x → Super Bowl 5-10x。容量規劃要按事件級別分段、不是一律 10x。

對 9.C14 Standard Chartered 這種受監管金融、不能用單一巨型 cluster — 7 個受監管市場 = 7 個獨立 cluster、合規 boundary 比運維成本優先。

核心機制：15 replica 上限、共享 storage、reader endpoint

Aurora read replica 的 first-class concept 是 共享 storage + DNS-based reader endpoint。傳統 PostgreSQL streaming replication 靠 primary push WAL 給 replica、replica 自己 apply；Aurora replica 直接從共享 storage 讀已 apply 的 page、不需要 catch-up。

15 replica 上限：

• 每個 Aurora cluster 最多 15 個 read replica（跨 AZ）
• 跨 region replica 走 Aurora Global Database（不算這 15 個）
• 文件上限不是 production 真實上限 — 多數 production 部署在 5-10 replica 之間遇到拆 cluster 訊號

共享 storage 對 lag 的影響：

• Replica 不靠 logical replication catch-up、直接從共享 storage 讀
• Lag 來源是 compute node 的 buffer cache 同步、不是 WAL replay
• Typical 10-30ms、heavy write 期間可能 100ms+、但 不會像 PostgreSQL 那樣 unbounded

DraftKings 揭露的「lag 可預測」frame（case「判讀」段第 2 點）：

「30 秒降到 10-30 ms」的工程意義不只是「快」、而是「讓 read-after-write 變得可預測」。30 秒 lag 的世界裡、application 端做 read-after-write 要 cache 用戶最後寫入 30 秒以上、實務上做不到；10-30ms lag 的世界裡、application 可以做「寫操作後 100ms 內走 primary、之後可走 replica」的可規劃策略。

Reader endpoint 行為：

• DNS-based round-robin、不感知 replica 健康狀態
• Application 想要 lag-aware routing 要自己實作或用 RDS Proxy
• Failover 期間短暫包含 promoted replica（已升 primary）、見 Aurora cross-AZ failover RTO

Auto-scaling policy：

• CloudWatch metric（CPU / connection）trigger
• Replica creation 2-5 分鐘
• 無法用於秒級尖峰 — 是 DraftKings「+50% no sweat」誤讀的關鍵點

跟通用 read replica 差在哪：Aurora replica 不用 catch-up WAL、lag 上限可預測；vs PostgreSQL streaming replication lag 是 unbounded（取決於 primary 寫速度）。可預測 lag 是 read-after-write 場景變得可規劃的前提。

對應 knowledge card：replication-lag、stale-read。

Step-by-step 配置 / Reader endpoint 設計

建 read replica：

1aws rds create-db-instance \
2  --db-cluster-identifier my-cluster \
3  --db-instance-identifier my-replica-01 \
4  --db-instance-class db.r6g.4xlarge \
5  --engine aurora-postgresql \
6  --availability-zone us-east-1b \
7  --promotion-tier 1

Reader endpoint vs Custom endpoint：

1# 預設 reader endpoint：所有 replica round-robin
2# 訪問 url: my-cluster.cluster-ro-xxx.us-east-1.rds.amazonaws.com
3
4# Custom endpoint：group 特定 replica
5aws rds create-db-cluster-endpoint \
6  --db-cluster-identifier my-cluster \
7  --db-cluster-endpoint-identifier my-cluster-analytics \
8  --endpoint-type READER \
9  --static-members my-replica-analytics-01 my-replica-analytics-02

Custom endpoint 適用場景：

• 分析 query 走獨立 endpoint、不影響 OLTP read replica
• Read-after-write session 走 primary endpoint、其他 read 走 reader endpoint
• 不同 SLO 的 read traffic 分流（high-priority vs batch）

Auto-scaling policy：

 1aws application-autoscaling register-scalable-target \
 2  --service-namespace rds \
 3  --resource-id cluster:my-cluster \
 4  --scalable-dimension rds:cluster:ReadReplicaCount \
 5  --min-capacity 2 \
 6  --max-capacity 10
 7
 8aws application-autoscaling put-scaling-policy \
 9  --service-namespace rds \
10  --resource-id cluster:my-cluster \
11  --scalable-dimension rds:cluster:ReadReplicaCount \
12  --policy-name my-cluster-cpu-scaling \
13  --policy-type TargetTrackingScaling \
14  --target-tracking-scaling-policy-configuration file://scaling-config.json

預配 vs auto-scale：

• Peak workload 預知（賽事、促銷、季節事件）→ 提前 1 小時預配
• Unpredictable burst → auto-scale（接受 2-5 分鐘 lead time）
• 兩者混合：baseline 預配 + auto-scale 處理 baseline 之上的浮動

驗證點：

• AuroraReplicaLag < 100ms（per replica）
• Reader endpoint CPU 分布均勻（不是某 replica 過熱）
• Application stale-read error rate < 0.1%

Rollback boundary：移除 replica 即時生效、無 data loss；但 reader endpoint DNS cache 仍可能短暫 routing 到已移除 replica（5-30 秒）。

故障模式 / 邊界 case

Case 1：加 replica 後 primary CPU 沒降

徵兆：明明加了 3 個 read replica、primary CPU 仍然 90%、reader endpoint CPU 才 10%。

原因：application 沒把 read query routing 到 reader endpoint、所有 query 仍打 primary。Aurora reader endpoint 不會自動分流 — 必須 application 端拆 read / write data source。

修：

• Application 端 ORM / data source layer 拆 read / write connection pool
• 寫操作用 writer endpoint、純讀走 reader endpoint
• 雙峰錯位是這層拆分的 driver（DraftKings case 揭露 讀寫資源規劃要分開）

Case 2：Reader endpoint round-robin 推 stale read

徵兆：read-after-write 場景（用戶下注後立刻查 balance）打到 lagging replica、看到舊 balance、客訴。

原因：reader endpoint DNS-based round-robin、不感知 lag。Application 假設 read 永遠 fresh、但 typical 10-30ms lag 期間用戶操作就會踩到。

修：

• Sticky session：寫操作後 N 秒內同 session 走 primary（N = lag p99、typical 100ms）
• Application 端做「下注後 N 秒走 primary」邏輯（DraftKings「可預測 lag」frame 讓 N 秒可規劃）
• 或用 RDS Proxy 提供 lag-aware routing（managed alternative）

Case 3：Auto-scaling 來不及接秒級尖峰 — headroom 預留判讀

徵兆：賽事開賽 30 秒內流量 +50%、auto-scaling 觸發但 2-5 分鐘後才有新 replica、開賽尖峰已過、用戶在最關鍵時段看到 timeout。

機制限制：replica creation 2-5 分鐘、秒級尖峰過去了 replica 才上線。

DraftKings「Super Bowl +50% no sweat」的工程意義（case「判讀」段第 3 點原文）：「這句話的工程意義是 提前做好容量規劃、不是『Aurora 神奇』。寫 workload 預期可能 +50%、整個 system headroom 預留至少 50%、加上 read replica 動態加減、才能讓 50% 增幅變成『不流汗』」。

工程含義：

• Peak workload 預知（賽事 / 促銷）用 headroom 預留 + scheduled scaling 提前預配、不靠 auto-scale 接秒級
• Auto-scale 是 unpredictable burst 才用（突發新聞、KOL 推廣、未預期事件）
• DraftKings 的「不流汗」是 系統設計 結果、不是 Aurora 特殊能力

修：

• 賽事日曆建模：賽前 1 小時自動加 replica、賽後 2 小時減
• Primary instance class 升級提前一週、不是賽前升（升級期間 failover 風險）
• Headroom 預算：read replica 預留 50%、primary CPU baseline < 50%

Case 4：15 replica 上限 — 拆 cluster 訊號

徵兆：read traffic 持續成長、加到 15 replica 仍接近 CPU 瓶頸、想加第 16 個被 API 拒絕。

原因：Aurora 硬上限 15 replica / cluster、超過要拆 cluster。但實務上更常在 5-10 replica 就遇到其他拆 cluster 訊號（blast radius、ownership boundary、業務 sharding）。

修：見下方「邊界與整合：fleet 治理 SSoT」段、按 3 條 driver 判讀拆 cluster vs 加 replica。

Case 5：Heavy write 期間 replica lag spike

徵兆：bulk insert / DDL 期間 replica lag 從 10-30ms 跳到 100-500ms、application 假設 typical lag 永遠成立、stale read 比例大幅上升。

原因：heavy write 期間 replica buffer cache invalidate 速度跟不上、lag 暫時拉大。Aurora 的「可預測 lag」不等於「lag 永遠 10-30ms」。

修：

• bulk insert / DDL 期間 application 端切到全 primary 模式（避開 stale read 風險）
• 重要 DDL 用 pg_repack 或 logical migration、避免長時間 table lock
• 監測 AuroraReplicaLagMaximum、spike 超過 p99 threshold trigger application 端 fallback

Case 6：FanDuel 雙 SLO 並行 — 不要壓成單一數字

徵兆：team 看 FanDuel「5-10x peak」直接套到自家 streaming workload、結果 Aurora 撐不住、發現 FanDuel streaming 根本不走 Aurora。

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

scope warning（必明示）：

• FanDuel 5-10x 是 betting 服務的 Aurora 擴容倍數、不是 streaming
• Streaming 走 CDN、不走 Aurora
• 不能把兩種 SLO 壓縮成「Aurora 撐 5-10x」單一數字

case 自承的進一步 scope warning：「AWS 案例 沒有 提具體 betting transaction TPS、concurrent streams、延遲分布」（case「需要警惕」段）。引用 FanDuel 時不能寫「Aurora 在 betting 路徑撐 X TPS」這類細節 — case 沒提的數字不能擴寫。

修：

• 不同 SLO workload 拆獨立 cluster 或拆 read / write data source
• 容量規劃看自家 workload TPS、不要套用未公開的 case 數字

事件型容量分級表

9.C28 FanDuel 揭露事件型 scaling 不是一律 10x — 事件級別 是容量分級單位：

Frame 8 event-driven scaling 5 模式（跨 vendor 共寫）：本表是 Aurora 端從讀峰視角切入的事件分級、跟 DynamoDB on-demand-vs-provisioned 的 5 模式分類（flash-sale spike / predictable peak / sustained growth / surge baseline permanent shift / B2B sustained + 高可用）共軸。Aurora 端的 FanDuel 季賽 cycle 在 5 模式分類中對應 predictable peak 的時間序列展開 — 事件 tier 已知（賽季 → 季後賽 → 季冠軍賽 → Super Bowl）、按 tier 預配 read replica 數量、本質是「峰值已知 + 重複出現」的 predictable peak 在多 tier 結構下的延伸。

KV 層 vs SQL 層的 mode 決策差異：DynamoDB 端的 on-demand vs provisioned mode 是 KV vendor 的容量抽象（軸 1 peak/avg ratio / 軸 4 predictable-peak vs flash-sale）、詳見 DynamoDB on-demand-vs-provisioned 6 軸決策、本篇不展開。Aurora 端對應的決策是 read replica 數量 + auto-scaling vs scheduled scaling vs headroom 預留、靠的是 replica fleet size 而非 mode 切換。

兩 vendor 在 Frame 8 各自承擔：

• DynamoDB on-demand-vs-provisioned：5 模式分類 SSoT、mode × 事件型分類的合成判讀
• Aurora read-replica-scaling（本篇）：read 峰值的 headroom 預留 + 雙 SLO 並行（FanDuel 分級 + DraftKings 讀寫雙峰錯位）+ fleet 治理

case 自帶警示（scope warning 必保留）：

• 「5-10x」是 峰值倍數、不是 peak 持續時間。Super Bowl 的關鍵 30 分鐘可能 8-10x、其他 3 小時可能 3-5x（case「需要警惕」段）
• 分級 driver 是「同類事件中的最高倍率」、不是恆定數字 — 引用時要保留事件 tier 對應、不是一律「Super Bowl = 10x」單一閾值
• 跨業務 transfer 判讀：本表 只代表體育博彩賽季 cycle、不能直接套到 e-commerce flash-sale（後者倍數結構是「秒級數千倍」、跟事件 tier 結構不同）

容量規劃做法：

• 建立 event tier 體系、每 tier 對應不同 pre-scale 倍數跟 lead time（賽前 N 小時預配）
• 事件型分級的關鍵是「峰值是已知的」、不是「峰值多大」
• 對應 9.11 高峰事件準備 的容量分級

邊界與整合：Fleet 治理 SSoT — 何時拆 cluster vs 加 replica

本段是 Aurora fleet 治理軸 SSoT — Aurora storage architecture / Aurora cross-AZ failover RTO / Aurora Global Database / Aurora migration playbook cross-link 不重複展開。

跨 case 合成 frame：production scale 不是「單一巨型 cluster」而是 fleet of clusters、但 driver 各異。

Driver 1：Business sharding（DraftKings 200 cluster）

DraftKings 不用一個巨型 cluster 撐 100 萬 ops/min、而是 按業務切 200 cluster。每體育類別、每地理、每產品線各自 cluster、blast radius 自然隔離。

工程含義：

• 業務本身就有 sharding key（sport type / region / product line）— 拆 cluster 不需要 schema redesign
• 單 cluster 故障只影響該業務、不影響全平台
• 容量規劃變成「每 cluster 的容量規劃」、單機極限不重要

容易誤判的邊界：DraftKings 100 萬 ops/min ≈ 17K ops/sec 是 200 cluster 加總、平均每 cluster 約 80 ops/sec（case「需要警惕」段）— 不是「單一 cluster 撐 100 萬 ops」、案例對照不能擴寫成單 cluster 容量。

Driver 2：Microservice ownership（Netflix）

Netflix 每微服務各自有 private Aurora cluster、不共用 — 跟 monolith「一個大 DB 撐全部」相反。

工程含義：

• DB 容量規劃變成「每微服務的容量規劃」、複雜度分散到 service owner
• 跨服務 contention 變成 network 議題 而非 DB lock 議題
• 每多一個微服務就多一個 cluster、operational surface area × N

case 自帶 scope 警示：Netflix 數據層遠不止 Aurora — 還有 Cassandra（playback metadata）、EVCache（cache layer）、Iceberg（data warehouse）。Aurora 主要是「需要 ACID 的 OLTP 工作負載」、不是「all-purpose store」（case「需要警惕」段第 2 點）。讀者引用 Netflix consolidation 時、不能誤推論「Aurora 可以替所有 store」。

Driver 3：合規市場 boundary（Standard Chartered 7 cluster）

Standard Chartered 7 個受監管市場 = 7 個獨立 cluster。Data Residency 規範資料 不能跨境複製、Aurora Global Database 在這種場景違反合規。

工程含義：

• 容量規劃變成「7 個獨立規劃 × 各自合規門檻」
• 跨市場 DR 不靠 Global Database、靠應用層市場切換
• 合規 lead time 是時程主項（見 migration playbook 合規時程段）

case 自承 scope 警示：Standard Chartered case 未公開是 PostgreSQL 還是 MySQL、未公開具體 cost 數字、屬「相關 case study」匿名對照。

何時拆 vs 加 replica 的判讀順序

按以下順序判斷、第一個成立的就是拆 cluster 的訊號：

1. > 15 replica 需求 → 拆 cluster（Aurora 硬上限）
2. Blast radius 隔離需求 → 拆 cluster（單 cluster 故障影響範圍太大、業務不能接受）
3. 業務本身可切分（user shard / 產品線 / 地理）→ 拆 cluster（DraftKings 拓樸）
4. 微服務私有 store 拓樸 → 拆 cluster（Netflix 拓樸、跟服務生命週期綁定）
5. 合規禁止跨境複製 → 拆 cluster（Standard Chartered 拓樸、Global Database 反指標）
6. 以上都不成立 → 加 replica（最便宜的容量槓桿）

容易誤判的邊界：

• Fleet 治理本身有 ops surface area 成本（parameter group / backup / IAM / observability fan-out × N cluster）— 不是免費；driver 不夠強時不該拆
• 「fleet 看起來大」不是 driver — driver 是業務本身有 boundary、不是運維美觀
• 拆 cluster 後再合併比拆更難（資料遷移成本高）— driver 不確定時先加 replica

容量與觀測

核心 metric：

1AuroraReplicaLag           # per replica lag
2AuroraReplicaLagMaximum    # cluster max lag
3CPUUtilization             # per replica CPU
4DatabaseConnections        # per replica connection

Application 端 metric：

1read_query_latency_p99       # per endpoint (writer vs reader)
2stale_read_error_count       # read-after-write 失敗訊號
3read_replica_routing_ratio   # writer vs reader 流量比例

容量上限：

• 15 replica / cluster（硬上限）
• Cross-region replica 走 Aurora Global Database（不算 15）

容量公式：

1read replica count = (read QPS / replica throughput) × (1 + lag buffer) × (1 + event tier headroom)
2
3lag buffer        = 30%（典型）
4event tier headroom = 0% (平日) / 50% (playoff) / 100% (championship) / 200% (Super Bowl)

回路徑：9.5 瓶頸定位流程 判斷 read-bound vs write-bound、9.6 容量規劃模型 peak workload 預配 vs auto-scale 決策。

邊界與整合 / 下一步

Sibling deep articles：

• Aurora storage architecture — 共享 storage 為什麼能養 15 replica + 雙峰錯位 application 邊界
• Aurora cross-AZ failover RTO — replica 升 primary 流程
• Aurora Global Database — 跨 region replica 配置 + 合規 anti-pattern

Migration playbook：

• PostgreSQL / MySQL → Aurora — fleet 拓樸是 migration 規劃的維度之一

1.x 章節互引：

• 1.1 高併發資料存取 — read replica 是 OLTP 擴容的基本槓桿

RDS Proxy 整合：lag-aware routing、connection pool 共享、Lambda 場景；managed alternative。

何時不用本文：single replica + cross-AZ failover 已滿足、read traffic 不是 bottleneck 時可跳過、看 Aurora vendor overview 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Replication Lag 卡片 — 概念基底
• Stale Read 卡片 — read-after-write 容忍度
• 9.C4 DraftKings — 200 cluster business sharding 跟 headroom 預留
• 9.C23 Netflix — 微服務私有 store + Aurora 非 all-purpose store 邊界
• 9.C14 Standard Chartered — 合規驅動 fleet 拓樸
• 9.C28 FanDuel — 雙 SLO 並行 + 事件型容量分級
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora replication

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 Global Database 的實作層教學。前置閱讀建議 Aurora storage architecture（理解 storage-level replication）、Aurora cross-AZ failover RTO（對照單 region failover）。

問題情境

典型觸發場景：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 工具、但對 受監管產業 是反指標。9.C14 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 是 tens of minutes。

對應 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

切換後 application 端要 reconfigure connection string — DNS 不自動切跨 region（vs cross-AZ failover writer endpoint 自動跟）。

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

Case 1：期待 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）

Case 2：DNS 不跨 region 自動切

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

原因：cross-AZ failover writer endpoint DNS 自動跟、cross-region 不會 — Global Database 切換要 application 端管 region-specific connection string。

修：

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

Case 3：跨 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

Case 4：Lag spike during bulk operation

徵兆：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）
• 重要 DDL 用 pg_repack 避免長時間 lag

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

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

9.C14 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。

Case 6：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 更便宜

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

如果 team 引用 9.C28 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。

邊界與整合 / 下一步

Sibling deep articles：

• 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 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Stale Read 卡片 — read-after-write 容忍度
• RPO 卡片 — DR RPO 判讀
• 9.C14 Standard Chartered — 合規驅動的 Global Database anti-pattern
• 9.C28 FanDuel — 雙 SLO 並行的 multi-region 策略對照
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora Global Database

本 playbook 不重複 Aurora overview（請看 Aurora vendor 頁）— 前置閱讀建議 Aurora storage architecture（理解為什麼 operational redesign）、Aurora cross-AZ failover RTO（HA redesign 主項）、Aurora read replica scaling（fleet 治理 SSoT、含合規 driver）。

Migration type 判定

本 playbook 是 Type C：Operational redesign hybrid：

• PostgreSQL / MySQL → Aurora wire protocol 相容、application 多數不改
• 但 operational model（HA / backup / monitoring / capacity）完全不同、需要 redesign
• 跟 Type A schema translation 差：不需要翻譯 application SQL
• 跟 Type B drop-in 差：HA / backup / monitoring / capacity 模型需要 redesign
• 跟 Type E paradigm shift 差：保留 single-primary SQL 跟 ACID transaction 語意

對照其他 Aurora-related migration playbook：

• PG → Aurora DSQL 是 Type E paradigm shift（distributed SQL、multi-region active-active）
• PG → CockroachDB 是 Type E paradigm shift + cross-cloud

Driver：為什麼遷

主要 driver

• 團隊規模成長、DBA bandwidth 飽和、backup / failover / patch 操作負擔超過產品價值
• Read replica scaling 需求（傳統 streaming replication lag 秒級、Aurora 10-30ms — 詳見 Aurora read replica scaling）
• Storage growth 痛點（local SSD 上限、resize 要 downtime、Aurora 自動 grow 到 128 TB）

次要 driver

• HA model 簡化（Patroni / Orchestrator → Aurora cluster endpoint、見 cross-AZ failover RTO）
• Backup 自動化（pgBackRest / xtrabackup → Aurora automated backup + PITR）
• Multi-region DR 需求（Aurora Global Database、但合規場景例外）

No-go condition（嚴格遵守）

跨雲 / on-prem 需求觸動 vendor lock-in — Aurora storage layer 是 AWS 專屬、wire protocol 相容不代表退出成本低、long-term 跨雲策略未定時 self-managed PG / MySQL 反而保留路徑。

合規禁止跨境複製 no-go（9.C14 Standard Chartered 揭露）：

受監管市場資料不能跨境複製、Aurora Global Database 在這種場景違反合規。讀者規劃 Aurora migration 時不能假設「Aurora 一定有 Global Database 選項」— 要改用每市場獨立 cluster（fleet 拓樸吸收合規邊界、見 Aurora read replica scaling fleet SSoT）。

替代方案

• RDS PostgreSQL / MySQL：更接近 upstream、單 AZ 便宜、不重寫 storage
• 自管 + Patroni HA + pgBackRest：保留控制、跨雲可用
• CockroachDB / Aurora DSQL：multi-region active-active write 需求

Case anchor

• 9.C23 Netflix Aurora consolidation：多套 RDBMS 統一到 Aurora、driver 是 operational consolidation、不是純效能
• 9.C4 DraftKings：200 個 cluster、按業務切分（不是一個大 cluster + 200 schema）
• 9.C14 Standard Chartered：受監管場景、合規 lead time 是時程主項

Netflix scope warning（必引用）：

• case「需要警惕」段第 2 點原文：「Netflix 數據層遠不止 Aurora — 還有 Cassandra（playback metadata）、EVCache（cache layer）、Iceberg（data warehouse）。Aurora 主要是『需要 ACID 的 OLTP 工作負載』、不是『all-purpose store』」
• 工程含義：consolidation 是 ACID OLTP 整合到 Aurora、不是 所有 store 整合到 Aurora
• 讀者規劃整合範圍時要明示什麼 workload 不在範圍（cache、analytics、time-series、search、KV 高峰）
• 「+75% performance improvement 是跨多 workload 的最大改善幅度、不是『每個 workload 都 +75%』。實際每個 workload 改善幅度從 10% 到 75% 不等」（case「需要警惕」段第 1 點）

Diff audit：6 維 source / target 差異盤點

主導差異：Operational layer（HA / backup / monitoring）、不是 schema 或 application。

Schema diff 細節

PostgreSQL → Aurora PostgreSQL：

MySQL → Aurora MySQL：

Operational diff 細節

Application diff 細節

1# Self-managed PostgreSQL
2jdbc:postgresql://primary.internal:5432/mydb?ssl=true&sslmode=verify-full&sslrootcert=/etc/ssl/postgresql.crt
3
4# Aurora PostgreSQL
5jdbc:postgresql://my-cluster.cluster-xxx.us-east-1.rds.amazonaws.com:5432/mydb?ssl=true&sslmode=verify-full&sslrootcert=rds-ca.pem

Application 改動量小：connection string 換 endpoint、SSL CA 換 RDS CA、driver 不變。

對應 knowledge card：failover、replication-lag。

Phase plan：階段切換

Phase 0：Pre-migration audit（2-4 週）

工作：

• Extension audit：SELECT * FROM pg_extension / SHOW PLUGINS、列出 source 使用的 extension
• Parameter audit：postgresql.conf vs Aurora parameter group、列差異
• Application connection string audit：所有服務的 DB connection 點位
• Benchmark baseline：write QPS / read QPS / p99 latency
• Cost baseline：current self-managed monthly cost vs Aurora estimate

Output：

• Migration feasibility report（含 no-go condition check）
• Aurora cluster sizing 估算
• Extension migration plan（each extension 對應的策略）

Phase 1：Aurora infra 準備（1-2 週）

工作：

• Aurora cluster 開設（dev / staging / prod）
• Parameter group 對位（從 source postgresql.conf / my.cnf 翻譯到 Aurora parameter group）
• SG / subnet / IAM 設定
• RDS Proxy 配置（如需要）
• CloudWatch dashboard + Performance Insights baseline
• Backup retention 設定（1-35 天）

Output：

• Aurora cluster 待 data load
• Monitoring 已 ready、能對照 source 跟 target

Phase 2：Data migration（2-8 週、依資料量）

三條 path、依場景選：

Path A：AWS DMS full load + CDC

• 適合：< 1 TB、可接受 read-only 短窗口
• 流程：DMS full load → DMS CDC → application cutover
• 優點：managed、validation 工具齊全
• 缺點：CDC lag 受 DMS task config 影響、bulk DDL 不友善

Path B：pg_dump / mysqldump + logical replication catch-up

• 適合：> 1 TB、要長 CDC 期、預算敏感
• 流程：snapshot → pg_dump / mysqldump → restore to Aurora → logical replication catch-up → application cutover
• 優點：成本低、可控性高
• 缺點：手動步驟多、要自己管 CDC lag

Path C：Snapshot restore

• 適合：已在 RDS PostgreSQL / MySQL
• 流程：RDS snapshot → Aurora restore-from-snapshot → catch-up → application cutover
• 優點：最快、AWS-internal 操作
• 缺點：只適用 RDS source、不適用 self-managed

Phase 3：Dual-read validation（1-2 週）

工作：

• Application read 50/50 split source / target
• 比對 query 結果（per-table checksum + sampling）
• 量測 latency（Aurora p99 ≤ source × 1.2）
• 確認 stale read 比例 < 0.01%

Output：

• Validation report：query 結果差異、latency 對照
• Go/no-go decision for cutover

Phase 4：Cutover（< 1 小時 window）

工作：

• Source set read-only
• CDC catch-up final（lag → 0）
• Application switch endpoint（DNS / service discovery / config flag）
• Smoke test（critical path query + write）
• Monitor error rate + latency 1 小時

Output：

• Cutover complete
• Source 切到 read-only、保留作為 rollback 餘地

Phase 5：Cleanup（4-8 週）

工作：

• Source 保留 1 個月 read-only（rollback window）
• 確認穩定後 snapshot → S3 archive → decommission
• 舊 monitoring / backup / runbook archive

Output：

• Source decommissioned
• 新 runbook + monitoring 為 SSoT

本 phase plan 適用範圍

Non-regulated workload（一般 SaaS / e-commerce / 內部系統）。受監管場景（銀行 / 保險 / 醫療）請見下方「合規驅動遷移的時程模型」段、技術 phase 不變但 lead time 完全不同。

合規驅動遷移的時程模型

受監管產業遷移的關鍵時程是 合規審查 lead time、不是技術遷移時間 — 本段是補充給銀行 / 保險 / 醫療讀者、避免照本 playbook 走嚴重低估時程。

Standard Chartered 揭露的時程模型

9.C14 Standard Chartered case 「判讀」段第 3 點 + 「策略」段第 3 點原文：「每個受監管市場的審查可能 3-12 個月、合計遷移時程是『市場數 × 平均審查月份』、不是『技術遷移月份』」。

工程含義：

• 技術 phase plan 假設 2-8 週 data migration + < 1 小時 cutover
• 合規 lead time 是 獨立軸、可能比技術時程長一個數量級
• 不同市場合規進度不同步、可能要分批上線

合規時程組合

讀者判讀

• 受監管場景 不能 用本 playbook 的「2-8 週 data migration + < 1 小時 cutover」估時程交付給管理層 — 合規 lead time 是時程主項
• 受監管場景 不能 假設 Aurora Global Database 是 multi-region DR 選項 — 合規禁止跨境複製場景下 Global Database 違反合規（見 global-database-multi-region），要改用每市場獨立 cluster
• 合規場景的 phase plan 要把每市場當成獨立 mini-migration、用 市場批次 推進、不是一次 big bang

scope warning（必明示、case 自承）：Standard Chartered case 未公開是 PostgreSQL 還是 MySQL、未公開具體 cost 數字 — 引用時不能擴寫「Standard Chartered 用 Aurora PostgreSQL」這類細節（case 用「相關 case study」匿名標明）。

合規時程 scope 警示：「3-12 個月、7 市場 × 6 個月 ≈ 3.5 年」是 Standard Chartered case 揭露範圍。實際合規 lead time 隨產業（銀行 / 保險 / 醫療）跟國家（東南亞 / 歐盟 / 北美 / 中東）差異大、不是恆定數字。讀者要把自家對應監管框架的實際 lead time 算進來、不是直接套 Standard Chartered 數字。

Evidence：每階段驗證資料

受監管追加 evidence：

• 每市場合規 sign-off 文件（central bank / 金融監管機關）
• 跨境複製禁令審查記錄
• Data residency 驗證測試（資料未流出受監管市場 boundary）
• Audit log 連續性驗證（source / target audit log 銜接）

回路徑：4.20 Observability Evidence Package 抽 CDC / latency evidence。

Cutover：切流決策

Cutover window：

• 建議 4 AM local time（lowest traffic）
• 預留 4 小時 buffer
• 受監管場景可能要在合規規定的 maintenance window（例如某些央行規定週日凌晨）

Rollback condition：

• error rate > baseline × 5
• write latency p99 > baseline × 3 持續 10 分鐘
• data corruption signal（checksum mismatch、unexpected row count drop）

Rollback path：

• Application connection string 切回 source
• Source 仍 read-write（cutover 前留 read-write 路徑、若已 read-only 要先解凍）
• CDC 反向同步（Aurora → source）catch-up

Decision owner：

• DBA lead + service owner + on-call SRE 三方 sign-off
• 受監管場景追加 compliance officer sign-off
• Cutover decision log 記錄（rollback window / rollback condition 文件化）

對應 knowledge card：rollback-window、rollback-condition。

Cleanup：雙軌退役

不可逆 cleanup 邊界：

• Source decommission 後資料只能從 backup restore
• 確保 backup 可用性測試通過再 decommission
• 受監管場景要保留 source backup 到合規 retention（金融 7 年、可能更長）

案例對照

Netflix Aurora consolidation：operational consolidation 的價值

9.C23 Netflix 多套 RDBMS（PostgreSQL / MySQL / Oracle）→ Aurora、+75% 效能 / -28% 成本。

驗證的 driver：

• DB 種類太多本身是規模化的成本（每多一種 DB 多一套 DBA 知識 / backup / monitoring）
• 整合到 Aurora 釋放工程資源、不是純效能改善

case 自帶警示（必引用）：

• 「+75% 是跨多 workload 最大改善幅度、不是每 workload 都 +75%」（case「需要警惕」段第 1 點）
• Aurora 非 all-purpose store 邊界：「Netflix 數據層遠不止 Aurora — 還有 Cassandra（playback metadata）、EVCache（cache layer）、Iceberg（data warehouse）。Aurora 主要是『需要 ACID 的 OLTP 工作負載』」（case「需要警惕」段第 2 點）

工程含義：consolidation 是「ACID OLTP 整合到 Aurora」、不是「所有 store 整合到 Aurora」。讀者規劃整合範圍時要明示什麼 workload 不在範圍：

DraftKings：fleet 拓樸 redesign

9.C4 DraftKings 200 個獨立 Aurora cluster、按業務切分（不是一個大 cluster + 200 schema）。

驗證的 driver：

• Migration 不只是技術切換、也是 cluster 拓樸 redesign
• 業務本身可切分（每體育類別 / 每地理 / 每產品線）就在 migration 時順便拆 cluster
• Blast radius 隔離跟容量規劃分散一起獲得

Fleet 拓樸決策：詳見 Aurora read replica scaling 邊界段 SSoT。本 playbook 提醒 migration 是拆 cluster 的好時機、不展開拓樸決策本身。

Standard Chartered：合規 lead time + 跨境複製禁令

9.C14 Standard Chartered 受監管場景揭露：

• 合規 lead time 是時程主項（3-12 個月 / 市場）
• 跨境複製禁止讓 Global Database 變反指標
• 每市場獨立 cluster + cross-AZ failover 是合規場景的標準解

反例：Aurora 不適合的場景

• Multi-region active-active write：見 PG → Aurora DSQL Migration
• 跨雲：見 PG → CockroachDB Migration
• 極端寫入吞吐（> 100K WPS）：考慮 sharding、CockroachDB、或 DynamoDB

邊界與整合 / 下一步

Sibling playbook：

• PG → Aurora DSQL — paradigm shift、Type E、multi-region active-active
• PG → CockroachDB — cross-cloud、paradigm shift
• PG → Aurora — 既有 PG-specific playbook、可對照本 playbook 的 vendor-neutral 版本

Sibling deep article：

• Aurora storage architecture — 理解 storage 設計才知道為什麼 operational redesign
• Aurora cross-AZ failover RTO — HA redesign 主項
• Aurora read replica scaling — fleet 治理 SSoT、含合規 driver
• Aurora Global Database — 合規禁止跨境複製的 anti-recommendation

1.x 章節互引：

• 1.12 大規模 DB 遷移實戰 — migration 上游 framework

何時不用本 playbook：

• 從 Aurora 遷到別處（反向、走對應的反向 playbook）
• 從 RDS PostgreSQL 升 Aurora PostgreSQL 是 in-place upgrade、用 RDS console「Convert to Aurora」即可、不需要這套 playbook
• 跨雲遷移：本 playbook 不涵蓋 GCP / Azure SQL → Aurora 流程

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Failover 卡片 — 概念基底
• Replication Lag 卡片 — operational diff 主軸
• Rollback Window 卡片 — cutover decision
• Rollback Condition 卡片 — rollback trigger
• 9.C23 Netflix — operational consolidation 跟 Aurora 非 all-purpose store 邊界
• 9.C4 DraftKings — fleet 拓樸 redesign
• 9.C14 Standard Chartered — 合規 lead time + 跨境複製禁令
• Migration Playbook 寫作方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora migration documentation

本文的判讀錨點是：I/O-Optimized 是成本與 workload profile 決策，而非效能保證。要看的是 read / write I/O charge、storage、instance、backup、replica、query pattern、maintenance 與未來成長。

官方文件路由的核心責任是固定時間敏感 claim。實作前先查 Aurora storage configurations 與 supported engines / regions；本文最後檢查日是 2026-05-22。

Cost Model

Cost model 的核心責任是拆解 Aurora bill 的來源。Aurora 成本通常包含 instance、storage、I/O request、backup、replica、data transfer 與 support / operation。

成本評估要用真實帳單和 CloudWatch 指標。只用平均 QPS 估算會漏掉 batch job、vacuum、index build、replica、backfill 與報表查詢帶來的 I/O 尖峰。

Workload Signals

Workload signals 的核心責任是找出 I/O 是否為主要成本與瓶頸。

先做 query 與 index review。若 I/O 來自缺 index、全表掃描、過度 eager loading 或不必要 backfill，直接切 I/O-Optimized 只會把浪費制度化。

Evaluation Process

Evaluation process 的核心責任是讓切換決策可回溯。

1. 收集 30 到 90 天成本：instance、storage、I/O、backup、transfer。
2. 收集 workload 指標：read/write IOPS、cache hit、slow query、top SQL。
3. 標記特殊事件：migration、backfill、incident、seasonality。
4. 建立 Standard vs I/O-Optimized 成本試算。
5. 在 staging / canary 確認 application behavior。
6. 設定切換後 7 / 14 / 30 天回顧點。

試算要包含季節性。月初結算、年度促銷、批次報表與資料重整都可能讓 I/O profile 和普通週不同。

Migration and Rollback

Migration and rollback 的核心責任是把 storage configuration change 放進變更流程。Aurora storage configuration 是 cluster-level decision，應先確認支援區域、engine version、切換限制、維護窗口與回退條件。

Rollback 條件要明確。若切換後成本下降未達目標、latency 沒改善、或 workload profile 改變，應重新評估 Standard 與 query optimization。

Anti-Patterns

Anti-pattern 的核心責任是避免把計費選項當成效能調校。

I/O-Optimized 的價值來自成本結構對齊 workload。它應該是 FinOps 與 database operation 的共同決策。

下一步路由

Aurora I/O-Optimized cost 完成後，Aurora 遷移讀 PostgreSQL to Aurora Migration；query 成本讀 Query Optimization；capacity 與瓶頸判斷讀 Bottleneck Localization。