本文不是 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 頁）— 而是 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