Azure成本應如何控制？
雲端開支不像實體伺服器般一次過付款，而是每個月按用量結算，使用量稍有增加，帳單便會明顯上升。本文由成本失控的原因說起，逐步說明如何用 Azure 內建的成本管理工具建立預算、分析開支、執行節約措施，並配合管理機制防止用量無止境增長。
成本失控的主要原因
了解雲端帳單為什麼會「突然」上升，是控制成本的第一步。Azure 的計費模式以用量為基礎，帳單上升通常不是單一事件造成，而是多個因素同時累積的結果。
資源未有計劃地建立
開發人員按需要即時建立虛擬機器或資料庫，完成測試後沒有刪除，空轉的實例每個月持續產生費用。這是最常見的「沉睡成本」來源，Microsoft 的成本管理文件把「消除不確定性」列為成本管理的首要工作。
規格超出實際需要
選擇實例時按「最多可能」而非「實際需要」選購，中央處理器核心數與記憶體容量遠超負載所需。Azure 提供實例規格建議（VM sizing recommendations），可根據實際使用率找出偏大的規格。
計費模式選擇不當
需要長期使用的資源以按量付費方式運作，而非預留容量（Reserved Instance）或節省計劃，基礎運算單位的單價便會長期偏高。Azure 文件指出，預留容量對持續運行的虛擬機器可顯著降低成本。
資料傳輸與儲存持續累積
儲存帳戶中的備份、日誌與舊版本檔案不斷累積，加上跨區域的資料傳輸費用，成為帳單上容易被忽略的固定項目。
以上四個因素有一個共通點：它們都不是單次事件，而是長期存在的結構性問題。因此成本控制不是「這個月少用一點」的臨時動作，而是一套持續的流程。
用成本分析找出錢花在哪裡
控制成本的前提，是知道錢花在哪裡。Azure 的成本管理（Cost Management）模組提供成本分析（Cost Analysis）功能，把帳單按訂閱、資源群組、服務類型與標籤逐層拆解，這是在動手刪除任何資源之前必做的第一步。
成本分析的核心概念有三個：
- 範圍（Scope）——分析可以從管理群組、整個訂閱或單一資源群組開始。範圍越小，越容易找出問題所在，實務上應由「帳單總額突然上升」的訂閱開始，逐層收窄到群組與資源。
- 維度（Dimension）——同一筆費用可按服務（虛擬機器、儲存、頻寬）、位置（區域）、標籤與資源類型等維度查看。把費用按服務排列，即可看出佔比最大的項目；再把該服務按資源展開，即可找出是哪一部虛擬機器或哪一個儲存帳戶造成。
- 期間比較——成本分析支援按月、按日查看，並可與上一期間對比。把「本月」與「上月」的明細並排比較，新增或倍增的費用項目會直接浮現，這是診斷帳單異常最有效的方法。
成本分析的資料每日更新一次，並有約 24 至 48 小時的延遲；Microsoft 的官方文件把成本資料的更新時間與準確性列明為使用前須了解的項目。因此以「今天的數字」做即時警報並不準確，預算警報的設計應考慮這個延遲（見下節）。
需要協助？成本分析與預算的設定細節較多，由熟悉 Azure 架構的工程人員協助核對，可更快找出浪費的資源與偏高的項目。WhatsApp → 建立預算與警報
預算（Budget）與警報（Alert）是把成本控制從「事後檢討」變成「事前攔截」的機制。Azure 內建的預算功能以金額為單位設定上限，當用量接近或超過上限時，系統會向指定的聯絡人發出電郵通知。
- 決定預算的範圍——預算可設定於管理群組、訂閱或資源群組層級。一般做法是訂閱層級設「總額上限」，每個部門或專案的資源群組再設各自的預算，兩者並行。
- 設定金額與期間——預算按月或按季設定金額，並以使用量的預測值自動推算「預計超支」的趨勢。若上月用量為 80%，本月趨勢顯示將達 120%，系統會提前警示。
- 設定警報閾值——每個預算可設最多五個閾值（例如用量的 50%、80%、100%），每個閾值可指定不同的通知對象。100% 的警報對象應包括財務與管理層，而非只有工程人員。
- 結合動作群組——警報可觸發動作群組（Action Group），自動執行後續動作，例如把通知轉發至通訊群組，或呼叫自動化流程。這使預算警報不限於「通知」，更可連動後續處理。
- 持續檢討閾值——用量下降後應把閾值收緊，用量上升後則檢討是否屬於永久性增長；預算不是設定一次便完成的文件。
預算警報須注意成本資料的更新延遲：Azure 的成本資料約每一至兩天更新一次，因此警報反映的是過去一至兩日的累計用量，而非即時數字。對接近上限的帳單，應把警戒閾值設於 80% 至 90% 之間，預留資料更新的空檔。
節約成本的四個實務方向
找出成本來源並設好預算後，下一步是實際把金額降下來。以下四個方向按照見效速度與改動風險排列，適合逐步執行。
停用空轉資源
檢查成本分析中佔比最大的虛擬機器，核對其 CPU 與網絡使用率。連續七天平均使用率低於 5% 的實例，應先排定停機時間表（VM start/stop schedule），確認無人使用後再刪除。刪除前須確認沒有存放唯一資料，並先建立最後一次備份。
改用預留容量
確認需要長期（一年或三年）持續運行的虛擬機器、SQL 資料庫與儲存，改用預留容量或 Azure 節省計劃購買，可大幅降低單位價格。Microsoft 官方文件建議以「過去 12 個月實際用量」為依據決定預留規模，而非按規格表估算。
以自動縮放配合實際負載
負載有明顯日夜或季節變化的系統，以自動縮放（Autoscale）按用量增減實例數量；辦公時間外的非核心服務，則以排定的關機指令在晚間與假日停止運行。兩者合併可消除「為尖峰負載長期開機」的浪費。
優化儲存層級
把不常存取的資料移至較低成本的儲存層級，刪除無用的快照與舊版虛擬機器磁碟。Azure 儲存提供熱、冷與封存等層級，每層級的成本與存取時間不同，適合不同的資料生命周期階段。
執行節約措施時應保留記錄：每一項改動對應的預期節省金額、執行日期與負責人，都記入成本管理的註記。這樣下一個結算周期核對帳單時，才能分辨「省了多少」與「用量又增加了多少」。
以標籤與治理防止成本再度失控
節約措施只能解決現有的浪費，防止新的浪費出現，需要依靠治理機制。Azure 提供兩套互相配合的工具：標籤（Tag）與 Azure 原則（Azure Policy）。
標籤是附加在資源上的名稱與值配對（例如「部門＝財務」、「環境＝生產」）。成本分析支援按標籤分組，設好標籤後，每一筆費用都可以歸屬到部門或專案，財務部門因而能知道每個業務單位的雲端開支。標籤的價值在於統一：公司應事先訂立標籤命名規範，規定哪些標籤為必填，再由系統強制執行。
強制執行的工具是 Azure 原則。它可以在資源建立時檢查標籤是否存在，若資源缺少必填標籤，可以直接拒絕建立，或自動補上預設值；原則亦可限制虛擬機器只能使用已核准的規格系列，防止同事「順手」建立超出預算的旗艦級實例。Azure 原則與角色型存取控制（RBAC）不同：後者決定「誰可以做甚麼」，前者決定「資源本身的設定是否符合規範」。
治理的另一個層面是定期檢討。建議每月固定一天執行「成本檢討」：核對預算達成率、找出新出現的異常費用、檢視上月節約措施的成效，並把結果發送給相關部門。成本管理是持續流程，而非一次性的整改專案。
香港企業採用 Azure 的實際情況
香港企業採用雲端服務時，除了技術層面，還須考慮法規與合規要求。《個人資料（私隱）條例》第 4 項保障資料原則規定，資料使用者須採取切實可行的步驟，防止個人資料未經授權或意外地被查閱、處理、刪除或喪失；把資料放到雲端時，企業須確認雲端供應商的合約與技術措施足以履行這項責任，並在成本預算中計入資料備份與存取控制的開支。
政府方面，數字政策辦公室（OGCIO）持續推動政府部門及公營機構採用雲端服務，其數碼化策略文件列明雲端為數碼政府發展的關鍵基建，私人企業採用雲端時亦須考慮與政府或公營客戶合作時的一致標準，例如資料在地域上的存放位置。
成本控制在香港企業還有一個現實考慮：多數中小企的雲端帳單由內部 IT 人員兼管，並無專職的財務分析。因此預算警報的收件人清單應包含負責人以外的主管，並以書面記錄每月的用量趨勢，即使人員變動，控制流程仍可延續。定額預算配合季度檢討，是本地中小企最務實的起步做法。