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

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

找出過度配置的資源

right-sizing 的起點是量測實際用量，跟配置規格比對。過度配置有幾種常見形態。最直接的是規格訂太大——CPU、記憶體長期只用一小部分，配了 8 核卻總在 2 核以內晃。第二種是機型世代過時——還在用舊世代的機型，沒升級到單位效能更好的新代，同樣的錢買到更少的效能。第三種是 reserved 買太多用不滿——當初承諾的量高於實際需求，多出來的承諾照付卻沒用到。

這三種浪費都不會自己報警，要靠定期 review 才抓得到。量測看的是利用率指標（CPU、記憶體、網路、IOPS 的實際使用率），長期偏低就是 downsizing 的候選。這裡要看的是「持續的」利用率，不是某個瞬間——一台平時 20%、但每天有一段跑到 90% 的機器，不能只看平均就砍。

Downsizing 不能砍過飽和點

Downsizing 有一條不能越過的線：不能把規格砍到系統的膝點以下。膝點（knee）是利用率升高時、延遲從平穩轉為快速劣化的那個轉折點——過了它，多一點負載就換來不成比例的延遲惡化。一台利用率長期 30% 的機器看起來浪費，但如果把它砍到平時就跑在 70%，就沒有 headroom 應付突發了——突發一來直接把利用率推過膝點、延遲飆升。飽和曲線與膝點的位置在 模組五 規模拐點判斷 講過，right-sizing 要在那條曲線上留足 headroom：砍掉純浪費的部分、但保住應付波動與 forecast 誤差的緩衝。

所以 downsizing 是有邊界的優化，不是「利用率越高越省」。目標是把利用率調到健康區間（膝點以下的 50% 到 70%），而不是頂到極限。砍過頭省下的機器錢，會用一次突發時的服務降級賠回來，而且賠得更多。downsizing 之後要觀察一段時間，確認新規格在真實流量（含波動）下站得住，再確定這個尺寸。

機型世代與 reserved 回收

機型世代升級是低風險的 right-sizing。雲端持續推出新世代的機型，同樣的規格、新世代常常更便宜或效能更好——換過去幾乎沒有壞處，只需要一次規格變更。定期檢查有沒有停在舊世代，是最容易拿到的成本節省之一。

reserved 過剩的回收比較麻煩。買了用不滿的 reserved，錢已經承諾出去了，處理的方式是看能不能把承諾轉移到還在用 on-demand 的其他工作負載上，或在有二級市場的情況下轉售。這也是為什麼 reserved 的承諾要保守——承諾的是「確定長期用得到」的基準量，把不確定的部分留給 on-demand。買 reserved 前先把 right-sizing 做完，才不會用折扣鎖住一個過大的規格：一台過度配置的機器買了 reserved，等於用三年的承諾把浪費也鎖了三年。

下一步路由

• 砍規格不能越過的膝點在哪、headroom 怎麼算 → 模組五 規模拐點判斷
• reserved 的承諾模式、怎麼配工作負載 → 計費模式理解
• 定期 review 靠什麼監控、異常怎麼抓 → 成本監控與告警

歸因是監控的地基

有了歸因，成本才從一個總數變成一張可查詢的報表。雲端的成本分攤工具（AWS Cost Explorer、Cost Allocation Tags、GCP 的 billing label）用標籤當分群維度，於是「team-payments 這個月花多少」「staging 環境占總成本幾成」變成一次查詢、而不是一場翻帳的會議。這套 tag schema 與啟用機制由 infra 鋪好，成本管理直接用它的產出——不重複鋪地基，聚焦在「有了歸因之後做什麼」。

歸因裡最關鍵的一個維度是擁有者。一個沒有擁有者標記的資源，出事時沒人認領、要不要關掉沒人能決定，就變成孤兒資源長期計費。擁有者標記讓每個資源都有一個「出事找誰」的答案，這也是後面告警能自動路由到對的團隊的前提。

異常告警：抓突增，然後定位

成本監控要主動、不能等月底帳單。做法是設異常告警——日均花費超過基線某個幅度就通知，把「這個月怎麼這麼貴」的驚訝提前到花費突增的當天。雲端提供成本異常偵測（如 AWS 的 anomaly monitor，可設每日頻率、超過某個絕對影響就發通知），這套 IaC 也由 infra 的治理地基提供，成本管理引用它、聚焦在告警觸發後的處置。

告警的價值在於它配上歸因能立刻定位。成本突增的三個常見來源都很具體：開發者開了大型機器測完忘了關、自動擴縮的上限設太高在尖峰長出一堆機器、NAT gateway 的出站流量灌爆帳單。告警響的時候，因為資源都有標記，可以馬上看出是哪個團隊的哪類資源在漲，而不是對著一個總數乾瞪眼。抓到之後的處置就接回前面幾章：忘了關的關掉、規格過大的做 right-sizing、可中斷的批次轉 spot。

Showback 還是 chargeback

歸因鋪好之後，有一個制度選擇決定成本控制的力度：showback 還是 chargeback。showback 是純展示——把每個團隊的花費算出來、給大家看，靠透明度促成節約，但不實際扣任何人的預算。chargeback 是實扣——每個團隊的雲端花費真的從它自己的預算裡出，成本變成團隊要對自己負責的數字。

兩者的取捨是「效果 vs 組織複雜度」。chargeback 的節約效果強得多——當花費真的從自己的預算出，團隊自然會在意 right-sizing、會記得關測試機；但它需要組織上把預算真的下放到團隊、需要一套公認公平的分攤規則，複雜度高。showback 複雜度低、阻力小，適合起步或組織還沒準備好下放預算的階段。很多團隊從 showback 開始（先讓大家看到自己花多少），等文化成熟、分攤規則穩定，再進到 chargeback。細緻的 chargeback 報表不必第一天就做——歸因的地基要早（day-1 就把 tag 立好），但制度化的分攤可以等成本真的成為議題時再上。

成本 review 併進容量 review

成本監控最有效的做法是把它併進既有的容量檢討，而不是當成一個獨立的活動。每個月的成本 review 跟容量 review 一起做：看預算對實際的差距、找出前幾名的成本驅動、追月度趨勢裡的異常、跟容量團隊一起討論哪些資源該 right-sizing。成本跟容量本來就是一體兩面——容量規劃決定要開多少資源，成本管理決定這些資源花得值不值得，兩者放在同一個檢討裡，right-sizing 的決策才有容量數據支撐。

下一步路由

• tag schema、成本分攤標籤啟用、anomaly monitor 的 IaC 地基 → infra 治理好習慣
• 告警抓到過度配置之後怎麼調規格 → Right-sizing
• 非 production 環境的成本怎麼系統性壓下去 → 開發環境成本控制
• 成本 review 對應的容量檢討 → 模組五 容量規劃

排程關機：非上班時間關掉

最直接的手段是排程關機——dev 跟 staging 在非上班時間自動關機、上班前自動開機。一個只有工作日白天有人用的環境，關掉晚上跟週末，運轉時間從一週 168 小時降到約 50 小時，成本直接省下七成。這對開發環境幾乎沒有副作用：沒人在用的時候關掉，早上開機幾分鐘就回來，換來的是大幅的成本下降。

排程關機的邊界是「哪些環境真的可以關」。跑著共用測試、或有人在跨時區使用的環境不能無腦關；但絕大多數團隊專用的 dev、staging，晚上關掉沒有任何人受影響。判斷的標準是這個環境有沒有「非上班時間必須在」的用途——沒有，就該排程關掉。

Ephemeral 環境：用完即拆

比排程關機更徹底的是 ephemeral 環境——按需建立、用完就拆，而不是常駐。典型做法是每個 PR 自動起一個獨立的預覽環境，PR 合併或關閉就自動銷毀。這種環境的存在時間只有它真的被用到的那幾小時或幾天，不用時根本不存在、自然不計費。

ephemeral 的好處不只省錢，還順帶解掉了環境漂移的問題——每次都從乾淨的 IaC 重建，不會累積手動改動。它的前提是環境要能完全用 IaC 重現、且建立夠快（不能每次等半小時）。做得到的話，ephemeral 是開發環境成本控制的理想形態：成本只在真的用的時候發生。

CI 與批次工作跑 spot

CI 跟批次工作是 spot instance 的理想場景。spot 便宜（單位成本遠低於 on-demand），代價是可能被中斷——而 CI 本來就能容忍中斷：一個 job 被收回，重跑就好，不像 production 服務中斷會影響用戶。把 CI runner、批次的資料處理、壓測這類「可中斷、失敗可重跑」的工作放到 spot，成本大幅下降而不影響正確性。

要讓 spot 的中斷不變成整批失敗，除了靠多機型、多可用區分散降低同時被收回的機率（這條在 模組五 成本模型 講過），還要讓工作本身能優雅承接中斷。雲商通常在收回前提前約兩分鐘發中斷通知，job 收到通知時該做的是把當前工作標記成待重跑、或 checkpoint 進度，讓它換一台接續而不是靜默地掉在半路。對無狀態、冪等的 CI job 這幾乎是免費的（重跑就好）；對有中間狀態的批次，checkpoint 讓被收回的那段能接續而非從頭。spot 省的錢，前提是中斷處理做對。

Per-team 成本上限

前面幾個手段是省，這一個是防失控。給每個團隊、每個非 production 環境設一個成本上限（budget），超過就告警甚至自動限制。它防的是開發環境特有的失控模式——有人開了一台大機器做實驗忘了關、某個測試腳本失控地建資源、自動擴縮在測試環境把上限設太高。這些在 production 有嚴格審查，在開發環境卻常常沒人盯，一個手滑就是一筆意外帳單。per-team 的上限讓每個團隊的實驗有一個成本天花板，配上 成本監控與告警 的歸因，超標時知道是誰、哪個環境。

下一步路由

• CI 用的 spot、spot 的中斷風險怎麼管 → 模組五 成本模型
• per-team 上限配的歸因與告警地基 → 成本監控與告警
• ephemeral 環境要能完全 IaC 重現的前提 → infra 治理好習慣

自架跟雲端/商業方案的成本抉擇，關鍵在兩條成本曲線的交叉點。這兩條曲線的形狀根本不同：自架的成本成長得很慢（sublinear）——處理 1 個用戶跟 100 個用戶的基礎設施成本差異極小，只在規模拉大、維運人力上來時才逐步爬升；商業或雲端託管的成本隨規模線性上升——按事件量、用戶數、或主機數計費，業務成長直接乘上費用。小規模時自架的平坦曲線更低，某個規模之後商業的規模經濟勝出，交叉點就在兩條線相交的地方。

兩條曲線為什麼形狀不同

自架成本成長慢，是因為它的主要成本是一次性的建置與相對固定的維運，跟用量幾乎脫鉤（真正隨規模上升的是維運人力，不是機器）。一套自己跑的監控、資料處理，處理的事件多一個數量級，機器可能只需要多開一點，但架構、維護的成本不變。商業成本線性，是因為它的計量單位（事件、主機、席位）直接綁在業務成長上——用戶翻倍、事件翻倍，帳單就翻倍。這是計量模式跟業務規模綁定的結果，不是單價高低的問題。

交叉點的位置沒有硬數字，是經驗估算：使用者數少（約百人以下）時，自架的總成本（建置加維護加硬體）通常低於商業方案的年費；規模大（約千人以上）時，商業的規模經濟與省下的人力勝出。中間是一段灰色地帶，取決於功能需求與團隊能力。給幾個錨點感受量級——典型商業監控方案年費約數百美元起、按規模往上，不少方案有免費額度（如某些錯誤追蹤方案免費到每月數千個事件、某些分析方案免費到每月百萬級事件），小規模可以零成本起步。這些免費額度耗盡後轉按量付費，帳單就開始爬那條線性曲線。

交叉點不是一個點，是一段光譜

把選擇當成「自架」跟「用雲端」的二元，會錯過中間大片的漸進選項。真實的選擇是一道光譜，差別在「哪些層自己管、哪些交給平台」：完全用商業 SaaS（只管埋點、其餘全外包）、用 BaaS 加 serverless（自己寫邏輯、平台管伺服器與資料庫維運）、用 PaaS（跑自己的程式碼、平台管佈署與 TLS）、到完全自架（全部自己管）。從左到右，自己扛的越來越多、單位成本越來越低、但人力投入越來越大。

這道光譜讓「交叉點」變成「可漸進遷移的區間」。小規模時用商業方案的免費額度零成本起步、同時保留自訂的彈性；規模成長、成本爬升到某個點，再往光譜的自架端遷移。關鍵是遷移方向的成本不對稱——從自架換到商業容易（改個埋點端點就好）、從商業換回自架難（要從零建起整套收集、儲存、儀表板）。所以起步時選哪個位置，要把「將來往哪個方向遷」算進去。

不在帳單上的成本

自架的帳單很便宜，但它的主要成本不在帳單上——在人力。自架系統的功能上限等於團隊願意投入的工程量：基本的查詢自己寫幾行就有，但儀表板、告警、進階分析，每一個功能都是數週到數月的開發；規模大了之後，高可用、擴容、備份的維運又是持續的人力。這些是自架真正的成本，只比雲端帳單而忽略人力，會嚴重低估自架的代價——這跟 模組五 成本模型 講的「自建與託管人力差 3 到 10 倍」是同一件事。

商業方案的隱藏成本則在 lock-in 與合規。深度用了某個 vendor 的私有 schema 與功能，遷出的代價很高——這是前面說的方向不對稱。合規則可能把天平推向自架、且與規模無關：資料落地（data residency）的要求下，自架能完全控制資料位置，商業方案只有部分供應商提供特定區域、免費方案的區域選擇還可能受限。一個有嚴格資料落地要求的服務，可能不管規模多小都得自架。算自架划不划算，要把人力、lock-in、合規這三筆帳單外的成本一起算進去，才是真實的交叉點。

下一步路由

• 自建與託管的人力成本差、承諾模式怎麼配 → 模組五 成本模型
• 計費的維度與隱藏成本（egress、lock-in）→ 計費模式理解
• 監控 SaaS 的部署光譜與自架對照 → monitoring 商業方案比較