本文是 DynamoDB overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。

quarterly review 看 DynamoDB bill 突然漲 80%、追查發現是 dev team 把所有 table 切 on-demand「省 capacity 管理」。finance 反問「於是省了多少 SRE 工時、又多花多少 cost」、team 答不出來。反向情境：Black Friday 前一週 provisioned table auto-scaling 上限是日常 5 倍、但開賣瞬間流量是 50 倍、auto-scaling 反應週期 5 分鐘、前 10 分鐘大量 throttle。兩個 production 痛點指向同一件事 — capacity mode 選擇不能只看「peak/avg ratio > 5x」單軸閾值。

本文展開 6 軸決策（peak/avg / 讀寫比 trend / surge 性質 / 事件分級 / DBA 工時釋放 / vendor crossover），把單軸決策樹擴成完整判讀框架。

DynamoDB 適用度前置判讀：本篇假設 workload 已通過 DynamoDB 適用度 4 軸（PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定）— 詳見 single-table-design-pattern 開頭 4 軸前置判讀、本篇不重複展開。Capacity mode 選擇是 已選 DynamoDB 後 的成本決策；若 workload 不適用 DynamoDB、mode 選擇無法救回 vendor 選錯的成本。

核心機制：兩種 mode 的工程差異

Auto-scaling 內部機制：

• CloudWatch alarm 觸發 → scaling activity → 1-5 分鐘調整 capacity
• target utilization 70%（建議值、留 buffer 給 scale latency）
• 連續 spike 仍可能 throttle（auto-scaling 反應週期 > spike 速度）

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

6 軸決策框架

mode 選擇不是單軸 peak/avg ratio。下面 6 軸是 9 個 production case（Zomato / Zoom / Amazon Ads / Disney+ / Tixcraft / Capcom / Lemino / Genesys / PayPay）跨 case 揭露的真實決策維度。

軸 1：peak / average 流量 ratio

最直覺的軸、但是單軸誤判的根源。基本判讀：

• 高 ratio（spiky / flash-sale）傾向 on-demand
• 穩定 ratio（sustained / 平緩）傾向 provisioned + auto-scaling

Scope warning：「peak/avg > 5x → on-demand」、「provisioned base rate × 6-7 = on-demand rate」這些具體閾值是經驗值 / 通用工程估算、9.C5 / 9.C20 case 都沒給具體 ratio 數字。實際 crossover 點隨 region pricing + workload shape 變動、不要照搬本文數字。

軸 1 單獨不夠用、要跟軸 2-6 合成判讀。

軸 2：讀寫比 trend 變化

9.C5 Amazon Ads 揭露的觀測軸：「讀寫比 變化 比讀寫比本身更重要」。

• 絕對讀寫比對容量規劃不是最重要（C5 是 18:1、C27 推估 5:1、絕對值各家不同）
• 業務邏輯改變（新增即時報表 / 新增推播 / 新增分析 query）會讓讀寫比跳一個量級
• 觀測上加 metric：read / write ratio 7-day rolling average、超過 ±30% 偏移觸發 review

把 trend 變化當 capacity mode 重新評估的訊號 — 不是固定週期 review、是 trend 偏移 觸發 review。

軸 3：surge 是 暫時 還是 永久 baseline 上移

9.C18 Zoom COVID 30x DAU surge 揭露的軸：surge 後 baseline 永久上移、不會回去。

• 暫時 surge（單日活動 / 季節高峰）：on-demand 划算、活動結束 mode 不用調
• 永久上移後（Zoom COVID、社會行為改變）：原 on-demand 設計會持續燒錢、要重新算 crossover、考慮切回 provisioned

Tripwire：surge 結束後 4-8 週仍維持 surge 期間 baseline 的 70%+、判定為「永久 baseline 上移」、重評 mode。

Scope warning：「4-8 週 / 70% 閾值」屬通用工程估算、9.C18 Zoom case 揭露「surge 後 baseline 不會回去」概念、未揭露具體閾值。

軸 4：predictable-peak vs flash-sale

9.C27 Disney+ 跟 9.C15 Tixcraft 對比揭露的軸：兩種 event-driven peak 不是同一類。

9.C27 Disney+（Marvel / Star Wars 首日 metadata 流量 3-5 倍、持續時段較長）可以提前 1-2 天 pre-scale、scheduled scaling 合適。9.C15 Tixcraft 6750x in seconds，scheduled scaling 太慢、必須事前 pre-provision baseline 拉到極高、或用 on-demand + composite partition key 雙保險。

兩者都不是「peak/avg > 5x → on-demand」單軸決策能解。

Scope warning：「scheduled scaling 30-60 分鐘前升 capacity」這個具體 lead time 是經驗值、case 未揭露具體時間。pre-scale 的 lead time 依事件性質決定、不是固定 30-60 分鐘。

軸 5：DBA / SRE 工時釋放

9.C19 Capcom 跟 9.C29 Lemino 揭露的成本軸：DynamoDB 真實成本不只看 monthly bill。

• 9.C19 Capcom：30% 成本下降的本質是「工程資源從 DB 運維轉到遊戲品質」、Capcom 是遊戲公司不是 IT 公司、把 DBA 時間從 Postgres patching / replication 設定 / backup 排程釋放到遊戲機制設計
• 9.C29 Lemino：90% 工程工時下降（DBA + connection management + capacity planning 統包）

評估公式：

1總成本 = direct cost (monthly bill)
2       + 工程工時機會成本 (DBA 從 patch/replication/backup 釋放出來做的事)

on-demand 的 6-7x base rate 在 DBA 工時釋放下、實質 ROI 可能仍正向（特別在小團隊 / 非 IT 主業公司）。但要算總成本、不是只看 bill。

軸 6：DynamoDB vs 自管 cluster cost crossover

9.C20 Zomato 警惕段揭露的最上層決策軸：mode 選擇之上還有 vendor 選擇。

• 9.C20 Zomato：「成本降 50% 是 當下流量 的對照」、未來流量繼續成長、DynamoDB cost-per-request 成長率比 TiDB 自管 cluster 高、某流量規模後 crossover、自管 cluster 反而便宜
• 不是只在 on-demand vs provisioned 之間挑、是要算「未來 12-24 個月在預期流量下、DynamoDB（不論 mode）vs 自管 cluster 的成本曲線」

判讀分層：

• 小 / 中流量 startup：DynamoDB on-demand 簡單划算、不用糾結
• 大流量 + 流量可預測 + DBA 團隊已存在：自管 cluster crossover 點可能成立、值得算
• 大流量 + 流量不可預測 + 小團隊：DynamoDB managed 仍划算（軸 5 加成）

本軸是 mode 選擇之上的更上層決策、不是每次都展開、但寫進邊界判讀條件。

操作流程

從 workload profiling 到 mode 切換的 8 步流程。

Step 1：workload profiling

用 CloudWatch 過去 30 天 RCU/WCU、算 p50 / p95 / p99 peak、求 peak/avg ratio（軸 1 輸入）+ read/write ratio rolling avg（軸 2 輸入）。

Step 2：surge 性質判讀

• 是暫時 surge 還是永久 baseline 上移（軸 3）— 看 surge 結束後 4-8 週的 baseline trend
• 是 predictable-peak 還是 flash-sale（軸 4）— 看事件時間跟 auto-scaling 反應週期的比例

Step 3：6 軸合成決策

1軸 1（peak/avg）+ 軸 2（讀寫比 trend）+ 軸 3（surge 性質）
2+ 軸 4（事件分級）+ 軸 5（工時機會成本）+ 軸 6（vendor crossover）
3→ provisioned + auto-scaling / on-demand / scheduled scaling 三選一

不是任一軸獨自決定、是 6 軸合成；軸間衝突時優先序：軸 6（vendor）> 軸 5（工時）> 軸 3（surge 永久 vs 暫時）> 軸 4（事件分級）> 軸 1（peak/avg）> 軸 2（讀寫比 trend）。

Step 4：provisioned 配 auto-scaling

 1BillingMode: PROVISIONED
 2ProvisionedThroughput:
 3  ReadCapacityUnits: 100
 4  WriteCapacityUnits: 50
 5
 6AutoScalingSettings:
 7  TargetTrackingScalingPolicy:
 8    TargetValue: 70.0  # target utilization
 9    ScaleOutCooldown: 60
10    ScaleInCooldown: 60
11  MinCapacity: 50      # baseline
12  MaxCapacity: 1000    # baseline × 預期 surge multiplier

target utilization 70% 留 buffer 給 scale latency；alarm 設 5 分鐘觀察窗。

Step 5：scheduled scaling

已知大事件（黑五、開票、新片發布）前預先提升 min capacity、事件後回原值：

1# 黑五前 24 小時把 min capacity 拉到日常 10 倍
2client.put_scheduled_action(
3    ResourceId="table/orders",
4    ScheduledActionName="black-friday-pre-scale",
5    Schedule="cron(0 0 * * ? *)",  # 時間 lead 依事件性質決定、非固定 30-60 分鐘
6    ScalableTargetAction={"MinCapacity": 5000, "MaxCapacity": 50000}
7)

Step 6：mode switch

1aws dynamodb update-table \
2  --table-name orders \
3  --billing-mode-summary BillingMode=PAY_PER_REQUEST

每張 table 24 小時內只能切一次、要計畫 maintenance window。

Step 7：驗證點

切換後第一週對比 cost + throttle metric、確認方向正確：

• cost 變化方向跟預期一致（on-demand 應該變貴 / provisioned 應該變便宜）
• throttle rate 沒上升
• latency p99 沒退化

Step 8：總成本評估（軸 5 + 軸 6）

直接 cost + 工時機會成本 + 對照自管 cluster 的 cost crossover 曲線。Quarterly review 用這個公式、不是只看 monthly bill。

Rollback boundary：on-demand → provisioned 隨時可切、但 baseline 要先 sized 好；切錯方向第一個月可逆、長期累積 cost 不可逆。

失敗模式

production 觀察到的 6 個典型 anti-pattern：

Case 1：on-demand 後 cost 翻 3 倍

dev team 切 on-demand「不用管 capacity」、但 workload 是 sustained constant、on-demand 6-7x base rate 全付出來。9.C5 Amazon Ads 明示「sustained workload 用 provisioned + auto-scaling」。修法：穩定 workload 用 provisioned + auto-scaling（軸 1 + 軸 2）。

Case 2：auto-scaling 跟不上 spike

流量 1 分鐘內 10x、auto-scaling alarm 5 分鐘才觸發、前 4 分鐘全 throttle。修法：peak/avg 高且 spike 突然 → on-demand、或 scheduled scaling 預先升配（軸 1 + 軸 4）；flash-sale 場景 auto-scaling 不夠快、必須 pre-provision。

Case 3：on-demand hot partition 隱藏

on-demand 不顯示 throttle、latency 從 5ms 變 50ms、application timeout retry 加劇問題。修法：on-demand 仍要看 partition-level metric（Contributor Insights）、不能假設 mode 解決設計問題（跟 partition-key-antipatterns cross-link）；mode × partition 交叉判讀。

Case 4：provisioned target utilization 設太高

target = 90% 看似省、實際每次 spike 都先 throttle 再 scale。修法：70% buffer 給 scale latency、不要為了省 cost 把 utilization 推到極限。

Case 5：頻繁切 mode 撞 24h 限制

team 想「白天 provisioned 晚上 on-demand」省 cost、但 mode 切換 24h 一次、計畫破產。修法：白天 provisioned + 晚上把 capacity 設低、不切 mode；用 scheduled scaling 處理日週期、不用 mode switch。

Case 6：surge 後沒重評 mode、長期燒錢（軸 3 對應）

Zoom 式 30x permanent baseline 上移後、原 on-demand 設計成本爆炸。修法：surge 結束 4-8 週後重評、若 baseline 維持 70%+ 改 provisioned；把「surge 後 mode review」寫進 runbook、不是 ad-hoc 才想到。

Anti-recommendation：流量 < 100 RPS、cost < $50/月的小 table 不用糾結 mode、on-demand 簡單；workload 穩定且 cost 高才值得做 provisioned + auto-scaling 的工程投入。

容量與觀測

CloudWatch metric：

• ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits：基本用量
• ProvisionedReadCapacityUnits / ProvisionedWriteCapacityUnits：provisioned 預設值
• ThrottledRequests：provisioned mode 直接訊號、on-demand 為零不代表沒問題
• SuccessfulRequestLatency p99：on-demand mode 下 hot partition 訊號

新增的觀測軸（軸 2 / 軸 3 對應）：

• read/write ratio 7-day rolling avg、超過 ±30% 偏移觸發 review
• surge baseline 4-week rolling avg、判斷 surge 是暫時還是永久
• AWS Cost Explorer 按 table + mode 切 cost trend、月對比

Auto-scaling activity log：CloudWatch alarm history + scaling activity，觀察 scaling 是否頻繁但 utilization 仍低（表示 alarm 設太敏感）。

指標口徑紀律：引用 case 數字時明示口徑 — 9.C5 90M reads/sec 是「年度峰值最高一秒、非平均」、9.C20 90% latency 降可能只 p50 不是 p99/p999、9.C18 30x DAU 是「permanent baseline 上移」非單日 peak。讀 vendor case 數字要分「最大瞬時 / 99 百分位 / 常態 / 滾動」四個口徑、不是混用。

Cost gate：每月 finance review 把 DynamoDB cost 對齊 access pattern volume、不只看絕對數字；軸 5 工時釋放跟軸 6 vendor crossover 也納入。

接回 9.6 容量規劃模型、1.10 KV / Document DB 容量規劃。

邊界與整合

Frame 8 event-driven scaling 5 種模式

9.C5 / 9.C15 / 9.C18 / 9.C24 / 9.C27 跨 case 揭露 event-driven scaling 至少 5 種形狀：

• flash-sale spike：拓元 6750x in seconds（軸 4 走 pre-provision + composite PK）
• predictable peak：Disney+ 新片首發（軸 4 走 scheduled scaling）
• sustained growth：Amazon Ads / Capcom（軸 1 + 軸 5 → provisioned + auto-scaling）
• surge baseline permanent shift：Zoom 30x DAU 不會回去（軸 3 → 重評 mode）
• B2B sustained + 高可用：Genesys 99.999%（軸 5 + 軸 6 → managed 工時釋放比 cost 重要）

不是用「peak/avg > 5x」單一閾值決策、是事件型分類 × 軸合成。

Sibling 與 cross-link

• partition-key-antipatterns — capacity mode 不解 hot partition、mode × partition 交叉判讀
• single-table-design-pattern — access pattern 影響 peak/avg ratio 跟 read/write ratio
• gsi-lsi-design — GSI 多時 cost 跟 mode 互動
• global-tables-conflict — 多 region capacity 規劃放大、軸 5 工時釋放在 multi-region 更顯著
• Migration playbook：跨 vendor cost optimization（如 Zomato TiDB → DynamoDB）對應 type C operational hybrid
• 替代路由：cost 極度敏感 + 流量穩定 + DBA 團隊已存在 → 自管 PostgreSQL / MySQL 可能更便宜（軸 6 crossover）、回 PostgreSQL vendor
• 跟 Zoom 9.C18 互引：30x permanent surge 後的 mode 重評（軸 3 主案例）
• 跟 Capcom 9.C19 + Lemino 9.C29 互引：DBA 工時釋放（軸 5 主案例）
• 跟 Aurora read-replica-scaling 共軸 cross-link：本篇從 KV 層 mode 選擇切入、5 模式分類在本篇主寫；Aurora 從 SQL 讀副本視角切入、事件分級表（FanDuel 平日 / playoff / championship / Super Bowl）跟雙 SLO 並行（DraftKings 讀寫雙峰錯位）+ fleet 治理在 Aurora 端主寫、本篇不重複展開