白板上寫著一個問題：

星際活動系統即將上線

選擇計費模式：
□ Provisioned - 預先配置容量，按小時計費
□ On-Demand - 按實際使用計費，無需配置

如何決策？

洛基站在白板前，大師遞給他一杯茶。

「第 1 天，」大師說，「你知道有這兩種模式，但不知道怎麼選。」

洛基點頭，回想起當時只是匆匆看過文件。

「現在，」大師繼續，「你已經會設計表結構、建立索引、整合 Streams、監控系統。是時候做出正確的容量決策了。」

洛基看著白板：「兩個都試試，看哪個便宜？」

「如果我說 On-Demand 比較貴呢？」大師問。

「那就選 Provisioned，」洛基理所當然地說。

大師微笑：「真的嗎？」

不只是價格：兩種模式的本質差異

「Provisioned 便宜，為什麼還要有 On-Demand？」大師反問。

洛基愣了一下，開始思考這個問題。

大師在白板上列出兩種模式：

Provisioned 模式

On-Demand 模式

洛基看著對比：「On-Demand 確實比較貴...等等，『28 RCU 運行 1 小時』是什麼意思？」

「算算看，」大師鼓勵。

洛基計算：「28 RCU × $0.00013 × 1 小時 = $0.0036...但 On-Demand 是 $0.25，貴了 70 倍？」

「不對，」大師糾正，「你算的是容量成本。但 On-Demand 是『實際使用』成本。如果你配置 28 RCU 但一小時只用 1 萬次讀取呢？」

洛基理解了：「Provisioned 是『租用容量』，不管用不用都要付錢。On-Demand 是『用多少付多少』。」

「所以，」大師說，「不是哪個便宜，而是哪個適合你的流量模式。」

決策框架：如何選擇模式

洛基翻開筆記本：「那要怎麼判斷？」

大師畫出決策樹：

步驟 1：評估流量模式

流量可預測嗎？（每天模式相似）
├─ 是 → Provisioned 較划算
│        （預先配置，成本低）
│
└─ 否 → On-Demand 較安全
         （間歇性使用、新產品、測試環境）

步驟 2：計算交叉點

假設平均流量 X QPS：
- Provisioned 成本 = 配置容量 × 小時費率 × 730 小時/月
- On-Demand 成本 = 實際請求 × 請求費率

如果流量持續穩定，Provisioned 通常在 20-30% 利用率以上就划算

洛基問：「20-30% 利用率？」

「對，」大師解釋，「假設你配置 100 RCU，但平均只用 20 RCU。這時 On-Demand 可能更便宜，因為你不用為那 80 個閒置 RCU 付費。」

「但如果平均用 70 RCU，」洛基接著說，「Provisioned 就划算了，因為總成本比按次計費低。」

「正確，」大師說，「關鍵在於利用率。」

實戰案例：星際活動系統的容量決策

「Hippo，」大師說，「顯示星際活動系統的流量數據。」

Hippo 的聲音響起：「過去 30 天監控數據如下。」

螢幕顯示：

流量統計（過去 30 天）

主表讀取：
- 平均 QPS：200
- 峰值 QPS：500（工作日 10:00-12:00）
- 夜間 QPS：50
- 每次大小：平均 2KB

主表寫入：
- 平均 QPS：50
- 峰值 QPS：150
- 每次大小：平均 2KB

GSI-主題索引：
- 讀取 QPS：50（波動大，某些主題突然熱門）
- 寫入：跟隨主表

洛基開始計算：「主表讀取 200 QPS，每次 2KB...」

「先別急著算，」大師說，「先分析特徵。」

洛基重新審視數據：「主表讀取很穩定，每天都是這個模式。但 GSI 讀取波動大...」

「對，」大師說，「現在算成本。」

洛基在筆記本上計算：

方案 A：全部 Provisioned

主表容量配置（使用強一致性讀取）

GSI 容量配置

總成本：$336.96 / 月（主表 $187.20 + GSI $149.76）

洛基看著計算結果，眉頭一皺：「$187.20...比我預期的高。」

他突然意識到：「等等，我剛才計算時...200 QPS 需要多少 RCU？」

大師微笑：「這取決於你用強一致性讀取（Strongly Consistent）還是最終一致性讀取（Eventually Consistent）。」

「差別是？」

「強一致性讀取：1 RCU = 1 次/秒讀取 4KB，」大師解釋，「最終一致性讀取：1 RCU = 2 次/秒讀取 4KB。所以如果用最終一致性，成本會減半。」

洛基恍然大悟：「所以剛才的計算用的是強一致性。如果改用最終一致性...」

「200 QPS 只需要 100 RCU，峰值 500 QPS 只需要 250 RCU，」大師說，「成本會降到 $23.40。但你要確認業務是否能接受最終一致性。」

洛基點頭，記下這個重點。

「而且，」大師繼續，「為什麼要按峰值配置？平常不是浪費了嗎？」

洛基想了想：「這就是為什麼需要 Auto Scaling？」

大師笑了：「正確。」

Auto Scaling：動態調整容量

「Auto Scaling，」大師說，「可以根據實際流量自動調整容量。」

他在白板上畫出運作方式：

Auto Scaling 運作流程：

1. 監控容量使用率
   └─ 目標：維持在 70%

2. 使用率 > 70% 持續 2 分鐘
   └─ 自動增加容量

3. 使用率 < 70% 持續 15 分鐘
   └─ 自動減少容量

4. 限制範圍
   ├─ 最小容量：平均需求
   └─ 最大容量：峰值需求 × 1.5

「為什麼目標是 70% 而不是 100%？」洛基問。

「因為擴展需要時間，」大師解釋，「從偵測到擴容完成，可能需要 2-3 分鐘。70% 到 100% 這段緩衝，讓系統有反應時間。」

洛基理解了：「如果設 100%，一旦超過就立即限流，Auto Scaling 來不及反應。」

「正確，」大師說，「現在重新計算成本。」

方案 B：Provisioned + Auto Scaling

說明：

• 最小容量：平均需求（100）
• 最大容量：峰值需求 × 1.5（250 × 1.5 = 375 RCU；300 × 1.5 = 450 WCU）
• Auto Scaling 根據 70% 目標利用率自動調整

洛基驚訝：「從 $163.80 降到 $65.52？」

「對，」大師說，「因為大部分時間流量不高，Auto Scaling 會縮小容量。」

混合策略：不同資源用不同模式

「GSI 呢？」洛基問，「流量不穩定，Auto Scaling 配置困難...」

「可以用混合策略，」大師說，「主表 Provisioned，GSI On-Demand。」

Hippo 顯示計算：

混合方案成本：

主表（Provisioned + Auto Scaling）：
- RCU: $10.92 / 月
- WCU: $54.60 / 月
- 小計：$65.52 / 月

GSI-主題索引（On-Demand）：
- 讀取：50 QPS × 60秒 × 60分 × 24小時 × 30天 = 129.6M requests
- 每次 2KB 需要 1 RRU（強一致性）
- 讀取成本：129.6M RRU × $0.25/M = $32.40
- 寫入：跟隨主表 50 QPS = 129.6M requests
- 每次 2KB 需要 2 WRU
- 寫入成本：129.6M × 2 WRU × $1.25/M = $324
- 小計：$356.40 / 月

總計：$65.52 + $356.40 = $421.92 / 月

洛基看著數字：「等等...GSI On-Demand 比 Provisioned 還貴？」

「是的，」大師說，「如果 GSI 流量持續穩定，Provisioned 更划算。On-Demand 適合真正不可預測的流量。」

「所以，」洛基總結，「要看實際流量模式，不是盲目選 On-Demand。」

大師點頭：「這就是為什麼需要監控數據做決策。」

他在白板上寫下決策原則：

混合策略決策：

主表：
- 流量穩定 → Provisioned + Auto Scaling
- 省成本，可控

GSI：
- 流量穩定 → Provisioned
- 流量不可預測 → On-Demand
- 測試/開發環境 → On-Demand

不是「哪個便宜選哪個」，而是「哪個適合選哪個」

GSI 的獨立容量配置

洛基翻到筆記本前面：「第 23 天提到，GSI 有獨立的容量配置...」

「對，」大師說，「每個 GSI 都可以單獨選擇 Provisioned 或 On-Demand。」

他展示範例：

星際活動系統的完整容量設計

總成本：$186.14 / 月（主表 $65.52 + GSI1 $95 + GSI2 $5.62 + GSI3 $20 估）

洛基看著這個設計：「所以可以混合使用——穩定的用 Provisioned 省錢，不確定的用 On-Demand 避免風險。」

「正確，」大師說，「而且可以隨時切換模式——先用 On-Demand 觀察流量，穩定後切換成 Provisioned。」

寫入放大的成本影響

「還記得第 23 天的『寫入放大』嗎？」大師問。

洛基點頭：「每次寫入主表，所有 GSI 也要寫入。如果有 3 個 GSI，寫入成本變成 4 倍。」

「對，」大師說，「現在算算實際成本。」

寫入放大的成本計算

場景：每秒 50 次寫入，每次 2KB

洛基驚訝：「8 倍？」

「這就是為什麼要謹慎設計 GSI，」大師說，「第 23 天提到『不是每個查詢都需要索引』，現在你理解成本影響了。」

洛基翻回筆記本：「所以 GSI3 如果改成 Provisioned...」

「會省很多，」大師說，「如果流量穩定的話。」

生產環境容量規劃流程

「實際上線時，」洛基問，「要怎麼規劃容量？」

大師在白板上寫下完整流程：

容量規劃六步驟：

步驟 1：收集需求
□ 預期 QPS（queries per second）
□ 資料大小（平均項目大小）
□ 峰值比例（峰值 vs 平均）
□ 成長預測（未來 6-12 個月）

步驟 2：計算基礎容量
□ RCU = QPS × (項目大小 / 4KB)
□ WCU = QPS × (項目大小 / 1KB)
□ 考慮一致性需求（強一致性 vs 最終一致性）

步驟 3：加入安全邊際
□ 建議 × 1.2-1.5
□ 應對未預期的流量突增

步驟 4：配置 Auto Scaling
□ 最小容量 = 平均需求
□ 最大容量 = 峰值需求 × 1.5-2
□ 目標利用率 = 70%

步驟 5：選擇計費模式
□ 穩定流量 → Provisioned
□ 不可預測 → On-Demand
□ 混合策略（主表 vs GSI 可以不同）

步驟 6：監控與調整
□ CloudWatch 持續監控
□ 每月檢視成本報告
□ 根據實際調整配置

洛基看著這個流程：「所以不是一開始就能算準，而是需要持續觀察調整。」

「對，」大師說，「這就是第 28 天監控的價值——提供調整容量的依據。」

成本優化的最佳實踐

Hippo 的聲音響起：「根據過去 30 天數據，發現三個優化機會。」

螢幕顯示：

優化建議：

1. GSI3 流量已穩定
   - 當前：On-Demand，成本 $324 / 月
   - 建議：切換成 Provisioned，預估 $95 / 月
   - 節省：$229 / 月

2. 主表夜間容量過剩
   - 當前：Auto Scaling 最小 100 RCU
   - 夜間實際：平均 50 RCU
   - 建議：調整最小容量為 50 RCU
   - 節省：約 $15 / 月

3. GSI2 稀疏索引利用率低
   - 當前查詢量：每月 10 萬次
   - 建議：評估是否需要此索引
   - 潛在節省：$5.62 / 月

總優化潛力：$249.62 / 月

洛基看著這些建議：「所以成本優化是持續的過程，不是一次性設定。」

「而且，」大師補充，「有時候優化不是降低容量，而是『正確配置』。」

他舉例：

反向案例：配置不足的隱藏成本

場景：
- 為省錢，配置 50 RCU
- 但實際需求 100 RCU
- 導致 50% 請求被限流

表面成本：$6.5 / 月（省了一半）

隱藏成本：
- 使用者體驗差，流失率增加
- 工程師花時間處理錯誤
- 業務損失遠大於省下的 $6.5

真正的優化：在成本與體驗間找平衡

洛基點點頭，理解了「便宜」不等於「優化」。

大師闔上筆記本。

洛基看著白板上的決策框架、成本計算、優化建議...從一開始的「選便宜的就好」，到現在理解容量規劃是一門需要數據、監控、持續調整的學問。

「最後一個問題，」洛基說，「如果我一開始選錯了怎麼辦？」

「可以隨時切換，」大師說，「Provisioned 和 On-Demand 可以互相切換，一天只能切一次。所以建議：」

上線策略：

階段 1：剛上線（0-1 個月）
- 全部用 On-Demand
- 觀察實際流量模式
- 避免容量規劃錯誤

階段 2：流量穩定（1-3 個月）
- 根據監控數據評估
- 主表切換成 Provisioned + Auto Scaling
- GSI 依流量特性決定

階段 3：持續優化（3 個月後）
- 根據成本報告調整
- 移除低使用率的 GSI
- 優化 Auto Scaling 參數

「所以不用怕一開始選錯，」洛基說，「重點是持續觀察和調整。」

大師微笑：「這就是雲端的優勢——彈性。不像傳統機房，買了伺服器就是固定成本。」

洛基收起筆記本，他現在理解，容量規劃不是數學題，而是在成本、效能、管理複雜度之間找平衡的決策過程。

「明天，」大師說，「我們會學習效能調優——如何在不增加成本的前提下，提升系統效能。」

洛基點頭，期待最後一天的內容。