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

雲端計費的基本單位是用量，分散在幾個獨立的維度上。運算按時間乘規格計費（開多久、多大台）、儲存按量乘類型計費（存多少、哪種儲存等級）、網路按流出的流量計費、請求類服務按呼叫次數計費、磁碟按 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
• 抓出忘了關的資源與異常支出 → 成本監控與告警
• 承諾模式怎麼配工作負載、單位請求成本怎麼算 → 模組五 成本模型