帳單的維度：付的是用量，不是機器

雲端計費的基本單位是用量，分散在幾個獨立的維度上。運算按時間乘規格計費（開多久、多大台）、儲存按量乘類型計費（存多少、哪種儲存等級）、網路按流出的流量計費、請求類服務按呼叫次數計費、磁碟按 IOPS 計費。這些維度各自累加，一個「看起來很小」的服務可能因為某個維度爆量而帳單很大——例如運算很少、但網路流出巨大。

看帳單要先拆到維度，才找得到真正的成本驅動。把整張帳單當成一個數字，只能看到「這個月比上個月多」，看不到「多在網路流出、不在運算」。拆到維度、再拆到單位請求成本（一個請求分攤到運算、儲存、網路各多少），成本才可歸因、可優化——這條 cost per request 的拆法在 模組五 成本模型 展開。

承諾模式：用彈性換折扣

在用量計費之上，雲端提供幾種「用承諾換折扣」的模式，取捨的軸是彈性與單位成本：on-demand 彈性最高、單位成本最貴，reserved 用 1 到 3 年的承諾換折扣，spot 用可被中斷換更深的折扣。這三種模式的折扣幅度、以及哪種配哪種工作負載（基準用 reserved、峰值用 on-demand、可中斷的批次用 spot），在 模組五 成本模型 展開過。這一章補模組五沒細講的第四種承諾模式——savings plan。

reserved 之外還有一種容易混淆的承諾模式：savings plan。差別在承諾的對象——reserved 承諾的是「某個規格的機器」，換規格或換區域就綁不住；savings plan 承諾的是「每小時花多少錢」（例如每小時至少花 10 美元的運算），只要總消費達到承諾，用什麼規格、什麼區域都算數。savings plan 用彈性換一點折扣深度——它的折扣通常略低於同期的 reserved，但換到了「規格可以自由調整」的自由度。規格常變的服務用 savings plan、規格穩定的用 reserved，是這兩者的分界。

reserved 到底值不值得，判準是承諾期內用不用得滿。一個確定會穩定跑滿 1 到 3 年的基準負載買 reserved 幾乎穩賺——那 30% 到 60% 的折扣是實打實省下的。一個可能半年後就下線、或架構還會大改的服務買 reserved，是拿折扣換被套牢的風險：承諾付了、需求卻沒了。所以買 reserved 前要先確認兩件事——這個規格的需求真的穩定、而且已經做過 right-sizing。別用三年的承諾鎖住一個過大或即將改變的規格，那會把浪費也一起鎖三年。

隱藏成本：帳單上的意外

帳單最常見的意外來自幾個容易被忽略的維度。第一個是網路流出（egress）——資料進雲端通常免費，出雲端要收費，而且跨可用區的內部流量也收費。一個把大量資料傳給用戶、或在可用區之間頻繁搬資料的服務，egress 可能是帳單裡最大的一塊，卻最容易在規劃時被忽略。第二個是 NAT gateway 的流量費——私有子網路的機器透過 NAT 出去的流量，除了機器本身，NAT 這一層也按流量收費，量大時很可觀。

第三個隱藏成本是被遺忘的資源，不算在任何計費維度的名目下：開了忘了關的測試機器、沒人用卻還在計費的孤兒資源（沒掛載的磁碟、閒置的負載平衡器、忘記釋放的固定 IP）。這些資源不服務任何流量、卻每小時都在計費，是純粹的浪費。它們的共通點是「開的時候有理由、關的時候沒人記得」——這正是 成本監控與告警 要抓的異常。

下一步路由

• 配置規格貼近實際用量、砍掉過度配置 → Right-sizing
• 抓出忘了關的資源與異常支出 → 成本監控與告警
• 承諾模式怎麼配工作負載、單位請求成本怎麼算 → 模組五 成本模型

計費模式有三種，取捨的軸是「彈性 vs 單位成本」。On-demand（按用量計費）彈性最高、不用承諾，但單位成本最貴；reserved（預留，承諾 1 到 3 年）單位成本降 30% 到 60%，代價是承諾期內用不滿就浪費；spot（用雲端的閒置容量）單位成本降 70% 到 90%，代價是隨時可能被收回中斷。三者是組合使用、不是三選一。

三種計費模式的最佳組合

成本最佳的配置是按工作負載的性質分配三種計費模式：永遠用得到的基準負載用 reserved（吃它的長期折扣）、峰值與無法預測的爆量用 on-demand（吃它的彈性）、不在關鍵路徑上、可以被中斷的批次工作用 spot（吃它的深折扣）。這個組合讓每一份負載都用到最匹配它性質的計費模式——基準負載穩定所以能承諾、峰值不穩定所以要彈性、批次工作能容忍中斷所以能吃 spot。

Spot 的中斷風險要靠分散來管。把 spot 池同時涵蓋多種機型、多個可用區（例如同時要 m5、m5a、m5n 三種相近機型、每個可用區都有），單一機型的池被收回時，其他機型還在，工作不會整批中斷。Spot 便宜但會被收回，分散是讓「被收回」不等於「工作失敗」的辦法。

單位請求成本讓成本可歸因

成本模型要能算到單位請求成本，才能判斷哪裡貴、哪裡值得優化。最粗的算法是月帳單總額除以月總請求數，得到平均的單位請求成本——但平均值藏了太多資訊。有用的做法是分階段拆解：一個請求的成本分攤到應用運算、資料庫讀、資料庫寫、快取、網路流出、第三方 API，各階段有自己的單位成本，加起來才是這個請求真正花的錢。

再往下要分端點算。不同端點的成本差幾個數量級——一個登入請求可能是萬分之一美元，一個結帳請求可能是千分之一，差 10 倍，因為結帳走更多階段、可能跨區域、要呼叫第三方支付。把所有請求當等成本來估容量與收費，會嚴重誤判哪個功能在燒錢。最後把單位成本對齊業務指標（每活躍用戶成本、每筆交易成本、每次推論成本），成本才跟商業決策接得上，而不只是一個雲端帳單數字。

Right-sizing：把規格調到剛好

Right-sizing 是定期檢查每個資源的規格是不是配得剛好。常見的浪費有三種：訂了太大的機型（CPU、記憶體長期只用 30%）、用了過時的機型世代（還在用舊代、沒升級到單位效能更好的新代）、以及 reserved 買太多用不滿。這三種浪費都不會自己冒出來報警，要靠定期 review 才抓得到——成本模型不是建一次就好，是要持續對照實際用量調整。

過度與不足配置的經濟學

配多配少各有代價，成本模型的判斷是找兩者的平衡點。過度配置的成本很好算——每個月多付的錢，直接看帳單。不足配置的成本難算，它是「故障機率乘以每次停機時間乘以每分鐘的營收損失」，要靠歷史事故率跟停機影響估。這兩個成本的平衡點就是經濟上最佳的 headroom。

平衡點會隨工作負載的關鍵程度移動。金融、醫療、支付這類關鍵負載，不足配置的代價（一次停機的損失）極高，寧可過度配置 30% 到 50%；內部工具、分析、批次這類非關鍵負載，停機代價低，可以貼近最低配置跑。同一套成本模型，關鍵負載算出來要留厚 headroom、非關鍵負載算出來可以壓薄——差別不在保守或積極，在不足配置的代價不同。

Autoscaler 的 max 是財務斷路器

自動擴縮的三個參數（最小、最大、目標）同時是成本的控制點。最小值太低會冷啟動、太高會平日浪費；目標利用率太高會等進膝點才反應、太低會頻繁擴縮浪費；而最大值是財務上的斷路器——它設多少，就是這個服務單月成本的上限。最大值設成無限大是常見的成本事故：一次流量異常（可能是攻擊、可能是重試風暴）觸發無上限擴容，月底收到爆掉的帳單。最大值要當成「願意為這個服務付的成本上限」來設，而不是「怕限流所以設高一點」。

自建與託管的人力成本

成本模型只算雲端帳單會漏掉一大塊：人力。自建一套資料庫、佇列、快取，需要 DBA 或 SRE 持續維護（打補丁、備份、故障轉移）；託管服務把這些交給供應商。兩者的人力成本可以差幾倍到一個數量級（常見的經驗區間是 3 到 10 倍，實際看自管元件的維運複雜度）——一個資深 DBA 的年薪不便宜，而工程師花在維運自建系統上的時間是機會成本，那些時間本可以做產品。算自建划不划算，只比雲端費用而忽略人力，會得出錯誤的結論。真實的成本決策裡，這塊人力差常常比機器費用還大——有團隊把自管叢集換成託管，省下的主要不是機器錢，是叢集管理的人力與維運簡化。

下一步路由

• 成本模型的輸入——容量怎麼算出來 → 規模拐點判斷
• 峰值預備的成本（為峰值留的 headroom 要付多少）→ 峰值估算
• 完整的雲端成本治理、計費模式的深入操作 → 模組八 成本管理