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

最直接的手段是排程關機——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 治理好習慣

計費模式有三種，取捨的軸是「彈性 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 要付多少）→ 峰值估算
• 完整的雲端成本治理、計費模式的深入操作 → 模組八 成本管理