GCP 帳單怎麼看？從用量找出能省的地方

帳單比上個月高，第一反應常是「有沒有折扣可以買？」先等等。多出來的費用可能是忘了關的測試 VM、跨區流量，也可能是服務真的成長了。這三種情況需要的做法不同，買 CUD 只會處理其中一部分。

這篇從找出費用變化開始，再談資源調整、儲存與網路費用，最後比較 CUD、SUD 和 Spot VM。價格和折扣會隨產品、區域與合約變動；文章不放固定「每月可省多少」的數字，估算時請用自己的帳單和 Google Cloud Pricing Calculator。

帳單變高，先問是哪裡變了

打開 Cloud Billing 的 Reports，把時間範圍切到本月和上月，先依專案，再依服務與 SKU 分組。比起只看總額，這樣比較容易分辨是某個專案新增了資源，還是原有服務的用量上升。

接著看三件事：

1. 費用從哪一天開始增加？ 對照部署、壓測、資料匯入或流量活動的時間。
2. 是哪個專案、服務和 SKU？ 「Compute Engine 變貴」還不夠，得再看是哪種 VM、磁碟或網路用量。
3. 用量、單價還是折扣變了？ 如果用量沒有增加，檢查區域、機型、計價模式，以及原本的折扣是否仍適用。

要和正式發票對帳，改用 Cost table 看當期明細、稅額與抵免。Reports 適合看趨勢，但不同時間範圍和篩選條件不一定會顯示與單張發票完全相同的總數。帳單資料也可能延後入帳，不要把「現在還沒看到費用」當成資源免費。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

BigQuery Export 很有用，但不是每個團隊都需要先建一套報表。內建 Reports 已能回答問題時，就先用它。若確實要匯出，最好在建立帳單帳戶時就啟用，並確認資料集位置、權限與匯出範圍；不要假設日後開啟就能補齊所有歷史資料。

例如 Reports 顯示某個專案的 Compute Engine 費用從週二開始上升，就繼續拆到 SKU：是 VM 運行時數增加，還是磁碟、對外 IP 或跨區傳輸變多？若同一天正好部署了新服務，找服務負責人確認容量是否符合預期。若只是壓測機忘了關，才安排停機。這樣追，比看到總額上升就要求所有團隊一律縮規格更有用。

先處理明顯浪費，再談折扣

折扣可以降低符合條件的用量單價，卻不會讓閒置資源變成有用。找到費用來源後，先看這幾類：

• 只短期需要的 VM 還在跑。 開發或測試環境若有固定使用時段，可評估 instance schedules。停機前先確認服務依賴；VM 停止後，磁碟等附屬資源仍可能計費。
• 規格可能大於需求。 參考 FinOps Hub 的閒置與 right-sizing 建議，再看 CPU、記憶體、尖峰流量和可靠性目標。建議顯示可省錢，不代表縮小規格一定不影響服務。
• 磁碟、快照或保留 IP 沒人負責。 先找到擁有者，確認資料是否需保留、是否有還原或稽核要求，再決定要不要移除。不要只憑名稱帶有「old」就刪除。
• 費用分不到團隊。 專案、Label 與成本中心的命名要一致。Label 只能追蹤加上後的用量，不能替過去沒有標記的資源自動補歸屬。

如果想從建議頁下手，先把「可能節省」當成待驗證的估算，不要當成已經省下的金額。

儲存：看讀取方式，不只看每 GB 單價

Cloud Storage 的 Standard、Nearline、Coldline、Archive 有不同的最低保存期和讀取費。越冷的類別，儲存單價通常越低，但提早刪除或頻繁讀取可能把節省吃掉。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

這只是起點，完整條件請看官方儲存類別說明與當期定價。要自動轉換類別，可比較 Object Lifecycle Management 和 Autoclass；設定刪除規則前，先確認備份、保留政策和提前刪除費。

例如每週都會被還原測試讀取的備份，不見得適合直接搬到 Archive。先估一年會讀幾次、每次讀多少，再把取回與操作費加進去，才知道便宜的是哪一種。

網路：先畫出資料到底走去哪裡

同一個服務反覆跨區域讀資料，網路費和延遲都可能跟著放大。查看帳單上的網路 SKU，再對照實際流量路徑：應用和資料庫在哪些區域？哪些回應能快取？有沒有把大量資料每次請求都重新傳一次？

不要套用「同區域一律免費」或「某區域一定最便宜」這類口訣。跨 zone、跨 region、對外傳輸、負載平衡器與 CDN 有不同計價方式；估算時以網路定價頁和相關產品的價格表為準。調整部署位置之前，也要把延遲、資料落地要求與備援設計一起算進去。

CUD、SUD、Spot VM 要解決的是不同問題

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

CUD：用穩定用量換折扣

Compute Engine 的 CUD 有資源型與消費型等不同方案。資源型承諾特定合格資源；Compute Flexible CUD 則依符合條件的消費金額運作。涵蓋哪些服務、機型、區域與折扣，應按實際購買的方案核對，不能把某一張折扣表套到所有 VM。

購買前，先清理閒置資源並看一段能代表平日與尖峰的逐時用量。再到 CUD analysis 看現有承諾的涵蓋率與使用率。若使用率偏低，先找原因；若涵蓋率偏低，也不等於一定要再買，因為未來需求可能下降。

假設一組服務白天需要八台 VM、夜間只需要五台，而且這個模式已維持幾個月。先確認夜間那五台能否縮規格或排程停機，再比較剩下的穩定用量適合哪種承諾。別把白天的尖峰當成全天基線，也不要用固定的「買到用量七成」當公式。

帳單上 CUD 的呈現方式也可能不同。多數消費型 CUD 已改用折扣後價格的計費模式；分析舊報表或 BigQuery Export 時，請先看官方說明，別把折扣後價格和舊式 credit 當成同一欄位直接相加。

SUD：符合條件的用量才會自動折

SUD 不用事先購買，但只套用在符合條件的 Compute Engine 資源。折扣依機型與當月使用時間而變；已被 CUD 涵蓋的同一段用量，不會再疊一次 SUD。別把「CUD 加 SUD」理解成同一台 VM 的同一小時可拿兩份折扣；超出承諾範圍的合格用量，才可能另取得 SUD。

Spot VM：便宜的前提是可以被中斷

Spot VM 使用剩餘容量，可能在任何時間被回收。Google 對許多機型標示最高可達 91% 的折扣，但那不是每台 VM、每個區域都能拿到的價格，也不代表週末一定比較有貨。

批次處理、可分段的資料轉換或能保存 checkpoint 的訓練工作，可以先試 Spot。設計時把任務切小、定期保存進度，並確認被中斷後誰來重試。若工作不能停，或中斷後重跑的代價比折扣還高，就不要只因標示價格低而選它。正式估算請查看目標區域的價格、容量與歷史中斷資訊。

預算告警是提醒，不是萬用煞車

先為重要專案或帳單帳戶設 Budget Alerts，把通知交給真的會處理的人。一般的 alerts-only budget 不會自動停止資源，而且帳單資料有延遲；若要研究 spend cap budget，還要確認它目前的預覽狀態、適用服務和限制，不能把兩者混成同一功能。

費用突然偏離平常模式時，可看 Anomalies，並設定有意義的金額與偏差比例門檻。告警到了，仍要有人判斷是正常活動、部署變更，還是資源真的失控。

需要自動化處置時，官方支援透過 Pub/Sub 通知觸發後續流程。但「超過預算就停止所有非 production VM」太粗糙：標籤可能漏設，停止也可能影響測試或資料處理。先明確列出可停的資源、例外條件、審核與回復方式，再讓程式動手。

一輪成本檢查可以這樣做

1. 在 Reports 找出變動最大的專案、服務與 SKU，記下開始變動的日期。
2. 對照當時的部署與流量；確認是用量、單價還是折扣造成差異。
3. 找到負責人，再檢查閒置資源、過大規格和固定時段的開發環境。
4. 檢查 Cloud Storage 的讀取頻率與跨區流量，不急著只換更便宜的儲存類別或區域。
5. 清理浪費後再評估 CUD；可中斷的工作才試 Spot，符合條件的持續用量則查看 SUD 是否生效。
6. 設定預算與異常通知，約定下次何時回頭驗證費用和服務品質。

準備 ACE 考試時，也用同一個順序判斷：先看題目要你找費用來源、估新價格、處理閒置，還是選折扣。不要看到「長期運行」就直接回答三年 CUD；要先確認那段用量是否穩定、是否符合方案，也別把 Spot 當成不能中斷服務的廉價替身。

成本優化不是保證能省某個百分比，而是每次調整都能說清楚：這筆錢買到了什麼、服務有沒有因此變差、下個月要用哪個數字驗證。

延伸閱讀

• Cloud Billing 文件
• Google Cloud Pricing Calculator
• CUD 方案總覽
• Google Cloud 免費試用與 Free Tier：怎麼練習又不讓帳單失控
• 上一篇：ACE-301：搬上 Google Cloud 前，先把遷移計畫排清楚
• 下一篇：ACE-303：GCP 認證怎麼準備？從 ACE 到 PCA 的學習路線