8.4 成本模型分析#
本節目標#
- 建立 Cloudflare Workers 生態（Workers、D1、R2、KV、DO）的免費額度與計費單位心智模型。
- 比較 Workers Free / Paid 訂閱模型的數學。
- 估算一個「小型業務網站」的月成本，並回答何時該升級。
計費的世界觀：平台用「操作」計費，不是「機器」#
傳統雲端賣的是長出一台機器的時間（EC2 以小時計）；Cloudflare 邊緣平台賣的是請求與計算量：
\[ \text{月成本} = \text{固定月費} + \text{單價} \times \text{用量超額} \]
這個模型對「流量起伏大」的網站最友善（1.1 節的 OpEx 概念），但代價是你要讀得懂每個產品的單位：
- Workers：請求數（request）＋ CPU 毫秒（compute）
- D1：讀列數（rows read）＋寫列數（rows written）＋儲存 GB
- R2：儲存 GB ＋ Class A（寫、列表）＋Class B（讀、head）操作數
- KV：讀 ＋ 寫 ＋ 儲存 ＋ 刪除
- Durable Objects：請求 ＋ 儲存 ＋ 運行時間（GB-hour）
免費方案限制表（2024–2025 公開數字，以官方文件為準）#
| 產品 | Free 方案額度 | Paid 方案 |
|---|---|---|
| Workers 請求 | 10 萬次 / 天，10ms CPU / invocation | 1,000 萬次 / 月起，CPU 上限 30ms |
| Workers Observability | 約 20 萬 log 事件 / 天 | 每月百萬級起，隨用量 |
| D1 | 5 GB 儲存；500 萬列讀 / 天；10 萬列寫 / 天 | 25 億列讀/月起，儲存首 5 GB 後計量 |
| R2 | 10 GB 儲存；100 萬 Class A / 月；1,000 萬 Class B / 月 | \(0.015 / GB·月；A\) 4.50/百萬；B $0.36/百萬 |
| KV | 10 萬讀 / 天；1 千寫 / 天；1 GB 儲存 | 百萬級起付單價（讀 $0.50 / 百萬等） |
| Durable Objects | （隨 Workers Paid 提供，免費版無 DO） 10 萬請求 / 天實驗額度 | $0.15 / 百萬請求＋儲存＋時長 |
| 靜態資源（Workers Assets） | 免費計入請求 | 部分請求型樣不另外計費 |
解讀兩個容易誤解的點：(1) D1 的是 5 GB 不是 10 GB；(2) 「10 萬請求 / 天」是 Workers 的天花板，超出即 1015 錯誤——不是降速，是硬停，這對正式服務是關鍵設計考量。
訂閱方案對比：Free vs Paid（每月 $5 起）的數學#
Workers Paid：固定 $5 / 月，內含 1,000 萬請求 + 3,000 萬 CPU-ms，超出部分：
| 項目 | 單價 |
|---|---|
| 額外請求 | $0.30 / 百萬 |
| 額外 CPU 時間 | $0.02 / 每百萬 CPU-ms?（以官方最新公告為準，近年持續降價） |
| Cron Triggers | 免費額度 + 超量計費 |
用平衡點算「何時值得付 $5」：
\[ N^* = \frac{\texttt{Paid 內含}}{\texttt{30 天}} = \frac{10{,}000{,}000}{30} \approx 33\text{ 萬請求 / 天} \]
也就是說：日流量 > 10 萬請求 / 天（Free 上限）且 < 33 萬 / 天 的甜蜜區帶，Paid 幾乎是「白送」一倍的容量還讓 CPU 上限從 10ms 提到 30ms、開啟 Durable Objects、Logpush 等功能。這個帶外的數學請自己用第 1 節的公式重新推導。
估算：一個小型業務網站月成本#
情境假設（中型個人品牌/小型電商）：
| 項目 | 月用量 | Free 可容？ | 月成本 |
|---|---|---|---|
| 頁面與 API 請求 | 60 萬請求（2 萬/天） | ✅ 免費內 | $0 |
| 靜態資源流量 | 8 GB | ✅（不計費） | $0 |
| D1 讀 | 900 萬列 | ✅（30 萬/天額度內） | $0 |
| R2 圖片儲存 | 18 GB | ❌ 超 10 GB | 8 GB × \(0.015 =\) 0.12 |
| R2 操作 | 200 萬 B 類 | ✅ | $0 |
| KV 文章緩存 | 5 萬讀 / 天 | ⚠️ 額度緊 | 視當月而定 |
| 合計 | ≈ \(0～\) 0.2 |
若流量成長到 5 萬請求/天（150 萬/月）：Workers Free 的上限在月中某天就會被撞穿，最務實的答案就是升級 Workers Paid \(5，取得 10 倍額度，且 D1 計量邏輯、DO、Logpush、Rate Limiting 全解鎖 —— 多數小型網站的終點就是這條\) 5。
與傳統方案對照（直覺錨點）#
- 一台 1C1G VPS：$5～10 / 月，但你得管開機、備份、每天掛不掛；流量尖峰無彈性。
- Serverless（Lambda + API Gateway）：同樣用量計價，但跨區延遲與 egress 費用常是 Workers 的數倍。
- Workers 本身的 egress 零費用（R2 對外傳輸免費），這是「把資料放旁邊」架構最省的地方。
什麼時候該升級？#
- 日請求逼近 10 萬：Free 是硬上限，1015 錯一秒都嫌多——提前升級。
- 單請求 CPU > 10ms：Free 的 10ms 限可被大 JSON 轉換、重量級運算打爆；出現 occasional 1102 錯誤就是訊號。
- 需要 Durable Objects、Logpush、Rate Limiting rule：功能面被鎖。
- D1 已觸頂：資料量未到 5 GB 但寫入 > 10 萬列/天，先升級再談寫入延伸。
反向建議：**不值得為了省 \(5 而提前自己架機器**——工程時數一小時就超過\) 5；省錢的正確做法是：把可快取的資源推到 s-maxage（8.2）降低請求數、用取樣率（8.1）壓 log 額度。
小結與練習#
重點回顧
- 邊緣平台的計費單位是「請求 × 操作 × 儲存」，讀對單位才算對錢。
- 免費額度最大的天花板是 Workers 的 10 萬請求/天（硬停機），不是流量、不是頻寬。
- 跨過 Free 上限後，Workers Paid $5 幾乎無對手；成本優化的槓桿在快取命中率與 log 取樣率。
練習
- 用你的站的真實流量組合，重算上表的月用量，並標出「離升級還剩幾 %」。
- 假設你的 Worker 平均花 8ms CPU，計算在第幾萬個請求時 CPU 時間會撞上 Free 10ms 上限，以及 Paid 後的月 CPU 附加費。
- 對照 1.1 節的 OpEx 公式，寫一段 3 行文字向不懂技術的老闆解釋「為什麼我們的帳單不會因流量尖峰翻倍」。