Capex vs Opex 與成本最佳化

簡介 — 為何成本經濟學對 PCA 至關重要

Professional Cloud Architect (PCA) 考試經常出現「最便宜的正確架構」就是正解的題目。考試藍圖要求你在技術契合度與 Google Cloud 工作負載的 Total Cost of Ownership (TCO) 之間取得平衡 — 涵蓋運算、儲存、網路、資料以及操作這些服務的人力成本。本學習筆記說明考試會測驗的成本思維模型、計價工具、帳單遙測與 FinOps 維運實務。

考試很少單獨問你「哪個 VM 最便宜」。取而代之的是把成本織進設計題裡：挑選儲存層級、挑選折扣工具、挑選帳單匯出 Schema、挑選正確的告警閾值。評分標準是你能否用美元而非僅憑功能來辯護一個設計決策。

Capex vs Opex — 雲端的思維轉變

地端基礎設施屬於 Capital Expenditure (Capex)：你籌措一筆大額預算、購買伺服器、按 3 到 5 年攤提折舊，並承擔供給過剩或不足的殘餘風險。Google Cloud 則翻轉成 Operational Expenditure (Opex)：每一秒 vCPU、每一 GiB 對外流量、每一個 query slot 都被計量並按月結算。

為何思維轉變會改變架構

Capex 思維鼓勵按尖峰負載定容量，因為硬體一旦買下，閒置容量「不要錢」。Opex 思維則鼓勵自動擴縮與無狀態服務，因為每一分鐘閒置都是帳單上的一行。PCA 考生必須能在情境題中認出傳統假設 — 例如「我們是按黑色星期五容量規劃的」 — 並用 managed-instance-group 自動擴縮、Cloud Run 縮至零、或 BigQuery on-demand slots 來取代它。

財務報表的影響

Capex 進入資產負債表並逐年攤提；Opex 則立刻沖入損益表。遷上雲端的 CFO 可能要求用 3 年期 Committed Use Discounts (CUDs) 重建 Capex 的固定月費感，因為 CUD 給出近似折舊表的固定月度承諾。題目中提到「可預測的月度成本」或「財務團隊偏好固定預算」即是 CUDs 的訊號。

混合雲 TCO 比較

利用 Google Cloud Pricing Calculator 與 Migration Center TCO Assessment，將完整載入的地端年運行成本（電力、冷氣、機房不動產、汰換週期、人力）與 3 年雲端成本投影比較。考試預期你記得：地端 TCO 鮮少只是硬體標價而已。

白話文解釋 (Plain English Explanation)

把 GCP 的成本經濟學對映到日常的金融決策，就會變得很直覺。

類比 1 — 買房 vs 租房 (Capex vs Opex)

Capex 像是買房：頭期款很大、30 年房貸、資產屬於你，但空房間的養護成本你也得永遠吞下去。Opex 像是按晚計費的 Airbnb：睡幾晚付幾晚、明天可以換城市、水電由房東（Google）處理。Committed Use Discounts 介於兩者之間 — 就像簽 1 年或 3 年的折扣租約，換來「住或不住都得付」的承諾。

類比 2 — 電力公司計費 (按表計量的 Opex)

Google Cloud 像電力公司一樣計費：你不買發電機，而是讓 kWh 電表跑。Sustained Use Discounts (SUDs) 是電力公司在你撐過月份 25% 後給的忠誠回饋 — 持續供電愈久，邊際電價愈便宜，Compute Engine 上最多可達標準價格的 30% 折扣。Spot VMs 則像在電力批發現貨市場買電 — 最高 91% 便宜，但電力公司可以用 30 秒的提前警告在尖峰時段切斷你的供應。

類比 3 — 信用卡帳單 (Billing Export)

匯出到 BigQuery 的 Cloud Billing 就是逐項列示的信用卡帳單。每一行顯示誰刷卡（project）、在哪家店刷（service / SKU）、是哪位家人刷的（labels），以及多少回饋金沖抵（credits 欄）。Budgets and alerts 是你在青少年把家用信用卡刷爆時設定的簡訊通知；Recommender API 則像銀行的 AI 提醒你取消已 90 天沒用的健身房會員。

Google Cloud 計價模式

PCA 考生必須熟記折扣工具及其適用情境。

On-demand (標價)

每一秒、每一 byte、每一次操作都付全價標價。沒有承諾、彈性最大。適合原型、無法預測的尖峰、以及短暫存在的環境。

Sustained Use Discounts (SUDs)

對 Compute Engine 與 GKE on-demand vCPU 與記憶體自動套用的月度折扣，條件是執行時間超過該帳單月份的 25%。折扣隨執行時間線性增加，整月執行可達標價的 約 30% 折扣。N1 與 custom machine types 賺取 SUDs；N2/N2D/E2/T2D 則賺取較小的自動 infrastructure discount。SUDs 完全不需要動作 — Google 在開立發票時自動套用。

Committed Use Discounts (CUDs)

你承諾 1 年 或 3 年 的支出，Google 給你折扣。

Spot VMs (與 GKE 上的 Spot Pods)

最高可比 on-demand 折扣 91% 的可被搶占運算。Google 可以用 30 秒 關機訊號將其收回。Spot 取代了舊版 Preemptible VMs（24 小時上限） — Spot 沒有最長執行時間，但也沒有 SLA。非常適合批次處理、CI worker、Dataflow flex worker，以及具備跨區故障轉移的無狀態 web tier。

Flat-rate / reservations (資料平台)

• BigQuery Editions（Standard、Enterprise、Enterprise Plus）按自動擴縮 baseline + max 賣 slots，以 slot-hour 計費。搭配 1 年或 3 年 slot commitments 取得更多折扣。
• Cloud Storage Autoclass 在無需手動 lifecycle 規則的情況下，自動把物件降級到較便宜的層級（Nearline、Coldline、Archive） — 適合無法預測存取模式時使用。

帳單帳號與資源階層

考試要求你熟悉資金如何在 GCP Organization → Folder → Project 樹狀結構中流動。

帳單帳號類型

• Self-serve (online) billing account — 信用卡付款、月結對帳單。
• Invoiced billing account — 月結 30 天，企業使用；月支出超過美金 10K 或需要 marketplace 合約承諾時必選。
• Sub-accounts — 經銷商 / 合作夥伴用來把費用轉嫁給下游客戶。

Project 與 billing 的對映關係

任一專案在同一時間必須連結到 唯一一個 Cloud Billing Account。連結可在不重建資源的情況下更換，但若專案變成未連結狀態，資源建立會被擋下。請使用指令 gcloud billing projects link PROJECT_ID --billing-account=BILLING_ID。

Chargeback 與 showback 模式

多數企業以三種模式之一向內部團隊計費：

1. Project-per-team — 每個團隊一個專案，帳單天然可歸屬。
2. Label-based — 共用專案，掛上 team、cost_center、environment 等 labels；帳單匯出按 label 分組。
3. Folder-based — folders 對應業務單位；CUDs 掛在 billing-account 層級在整個 Organization 共用。

帳單匯出至 BigQuery

Cloud Billing 提供三種 BigQuery 匯出資料流；考試要求你能挑選對的那一種。

Standard usage export

每日彙總成本資料：按專案、服務、SKU、label 的合計。Schema 包含 cost、currency、usage.amount、credits[]、labels[]、project.id、sku.description。足以支撐月度成本報表與儀表板。

Detailed usage export

額外加入 resource-level 資料列：每個 resource.name（例如每一台 VM、每一個 Cloud SQL instance、每一個 Cloud Storage bucket）都有獨立的資料列。當你需要按個別資源做 chargeback、除錯某一台 Cloud SQL instance 為何更貴、或建立 per-resource right-sizing 儀表板時就需要它。

Pricing export

每日快照價目表本身 — 每一個 SKU 的單位成本、地理區、tier 分段，以及 commitment 折扣。可用來預估「同樣工作負載在 europe-west1 vs us-central1 會花多少？」而不必實際運行。

你應該認得的 schema 重點

• cost (FLOAT) — 以 currency 計價的扣抵前淨費用。
• credits (REPEATED RECORD) — SUDs、CUDs、free-tier、與促銷回饋；合計為負值。
• usage.amount / usage.unit — 消耗量（例如 byte-seconds）。
• labels (REPEATED RECORD) — 使用當下掛在資源上的使用者自訂 labels。
• export_time — 資料列寫入時間（注意：完整對帳可能延後到 5 天，部分調整最晚 30 天 才到位）。

Chargeback 查詢範例

SELECT
  project.id AS project,
  service.description AS service,
  (SELECT value FROM UNNEST(labels) WHERE key = 'cost_center') AS cost_center,
  SUM(cost) + SUM(IFNULL((SELECT SUM(amount) FROM UNNEST(credits)),0)) AS net_cost
FROM `billing_dataset.gcp_billing_export_v1_XXXX`
WHERE _PARTITIONTIME BETWEEN '2026-04-01' AND '2026-04-30'
GROUP BY project, service, cost_center;

Budgets、Alerts 與程式化成本控管

Cloud Billing Budgets 是阻止失控的自動擴縮器產生五位數帳單的安全網。

Budget 結構

一份 budget 包含：

1. Scope — 帳單帳號、一或多個專案、一或多個 labels、或一或多個服務。
2. Amount — 固定金額，或「上一期實際支出 + X%」的動態目標。
3. Thresholds — 通常是預算的 50%、90%、100%、120%，可基於實際或預測支出。
4. Notifications — 寄信給帳單管理員，並可選擇通知 Pub/Sub topic 進行程式化動作。

程式化自動關機模式

當你需要硬性的關機開關（而非僅僅一封信），把 budget 連到 Pub/Sub topic，再觸發 Cloud Function 或 Cloud Run 服務執行：

1. 讀取 budget 事件 payload（budgetAmount、costAmount、alertThresholdExceeded）。
2. 呼叫 Cloud Billing API 將違規專案解除連結：projects.updateBillingInfo(billingAccountName="")。
3. 寫 log 到 Cloud Logging，並透過 PagerDuty 通知 on-call。

這就是經典的失控實驗帳號模式。PCA 考試常用「實習生週五下班後忘記關 GPU TPU pod」的情境題來測。

Budgets 的限制

Budgets 屬於告警機制，不是強制執行機制。它本身不會停下任何資源 — 只有 Pub/Sub 驅動的自動化才會。Quotas（下一節）才是真正具有預防性的硬上限。

Quota Manager — 預防性的成本硬上限

Quotas 是唯一能預防資源建立而非僅告警其費用的機制。

Quota 類型

• Rate quotas — 每分鐘 API 請求數（例如 Compute API 每專案 1,500 req/min）。
• Allocation quotas — 同時在用的資源總量（例如 region 內的 CPUs、T4 GPUs、persistent disk 總 GiB）。

Cloud Quotas (Quota Adjuster)

Cloud Quotas API（前身為 Service Usage 的 quota endpoint）讓你以程式化方式提高與降低 quota。具備 PCA 思維的團隊會把 dev/sandbox 專案的 GPU 與 public IP quota 降低到硬上限 — 即便失控腳本嘗試開 500 顆 GPU，也只有 4 顆會成功。

Quota override 範例

使用 gcloud alpha services quota update 或 Cloud Quotas console 覆寫：

gcloud quotas update \
  --service=compute.googleapis.com \
  --consumer=projects/lab-sandbox \
  --quota-id=NVIDIA_T4_GPUS-per-region \
  --override=4 \
  --location=us-central1

與 budgets 搭配後形成縱深防禦：quota 擋住資源建立、budget 擋住已運行的支出。

成本歸屬 — Labels 與 Resource Manager Tags

Labels 與 tags 是你切分帳單資料的工具，但用途並不相同。

Labels

掛在多數資源上（VM、disk、bucket、Cloud SQL、BigQuery dataset）的 key-value 字串。每個資源最多 64 個 labels、key 最長 63 字元、value 最長 63 字元。Labels 會傳遞到 billing export 成為 labels[] repeated 欄位 — 這就是 chargeback 查詢所依據的維度。

Resource Manager Tags

是另一套構造，掛在 organisation/folder/project 層級。Tags 被 IAM Conditions 與 Org Policy 用於存取控制 — 例如「只有掛 env=prod tag 的資源才可附 public IP」。Tags 同樣會流到 billing export 的 tags[]，因此也兼具成本維度。

歸屬策略

PCA 等級的 label 分類體系大致長這樣：

• cost_center — chargeback 桶（例如 cc-12345）。
• environment — prod / staging / dev。
• team — 工程擁有者。
• application — 邏輯應用或服務。
• data_classification — public / internal / restricted。

透過 Org Policy gcp.resourceLocations + custom constraint 或 Terraform pre-commit checks 強制要求 labels。沒有 label 的資源無法計費歸屬 — 它們會被丟到「無歸屬」桶裡，財務團隊極不喜歡。

Recommender API — 自動化的成本節省

Recommender API 是 Google 以機器學習驅動的成本最佳化引擎，呈現在 console 的 Active Assist 分頁。

必背的成本 recommenders

與 FinOps 自動化整合

程式化客戶端可透過 gcloud recommender recommendations list 拉取建議，再餵進 Cloud Workflows 管線自動套用低風險動作（例如刪除掛 30 天以上的未附掛 disk）。考試很愛出「答案是使用 Recommender API」而非「自己寫腳本」的情境題。

Carbon Footprint 與永續成本

永續性日益成為成本議題 — 受規範產業需要揭露 Scope 3 排放，而部分區域對碳定價亦不相同。

Cloud Carbon Footprint 產品

Cloud Carbon Footprint 將每個專案、服務的地點別 (location-based) 總排放與市場別 (market-based) 淨排放匯出至 BigQuery。Schema 欄位：

• carbon_emissions_kgCO2e — 該使用週期的總排放。
• carbon_model_version — 方法學版本（與 GHG Protocol 對齊的模型）。
• region / service — 與 billing export 相同的維度，方便 join。

區域選擇取捨

選擇低碳區域（例如 europe-north1 芬蘭、us-west1 奧勒岡、northamerica-northeast1 蒙特婁）可比高碳區域減少多達 90% 的揭露排放量。但延遲與資料主權限制經常凌駕在區域選擇之上 — PCA 情境題可能要你為某個 ESG 驅動的客戶證明選擇略貴的低碳區域是合理的。

永續性槓桿

• 在再生能源占比高的區域或時段排程批次與訓練工作負載（Carbon Aware 排程模式）。
• 偏好 Spot VMs — 搶占閒置容量比預留它能源效率更高。
• 用 Recommender Right-size — 減少浪費的循環同時直接降低成本與碳排。

FinOps Foundation Framework 對應 GCP

FinOps Foundation 定義三個迭代階段，各自對應特定 GCP 服務。

階段 1 — Inform (可見度)

目標：人人都能看到自己花了什麼。GCP 工具：

• console 中的 Cloud Billing Reports（成本趨勢、Top 服務、Top SKUs）。
• Billing export to BigQuery + Looker Studio 儀表板。
• 在組織層級貫徹 labels and tags 政策。
• Carbon Footprint export 提供永續性 KPI。

階段 2 — Optimize (消除浪費、買入折扣)

目標：砍掉浪費、鎖定承諾折扣。GCP 工具：

• Recommender API 找出閒置 / 過大資源。
• CUD analysis report 拿來決定 1 年 vs 3 年承諾額度。
• Storage Autoclass + Lifecycle Policies 降級冷資料。
• BigQuery slot reservation tuning 對比 on-demand 計費。

階段 3 — Operate (持續治理)

目標：成本紀律成為習慣。GCP 工具：

• Budgets + Pub/Sub 自動關機防失控。
• Cloud Quotas 在非正式環境做預防性硬上限。
• Org Policy 強制要求 labels 並禁止 dev 使用昂貴 SKU（例如禁止 sandbox folder 開 A100 GPU）。
• Cloud Billing API 整合至 FinOps SaaS 工具（Apptio Cloudability、Vantage、CloudHealth）。

考試可能直接點名階段（「該團隊正處於 Inform 階段，下一步需要什麼？」），預期你回答儀表板、labelling 或 BigQuery 匯出。

Cloud Billing API 與 FinOps 自動化

Cloud Billing API 是 FinOps 自動化的程式化骨幹。

關鍵 endpoints

• billingAccounts.list / get — 列出你能存取的帳單帳號。
• billingAccounts.projects.list — 列出帳單帳號下的所有專案。
• projects.updateBillingInfo — 連結 / 解除連結專案（自動關機的關鍵控制點）。
• services.list 與 services.skus.list — 列出價目表本身（同時暴露為 pricing export）。
• billingAccounts.budgets（Cloud Billing Budgets API） — 以程式化方式建立 / 更新 budgets。

必背的 IAM 角色

• roles/billing.admin — 對帳單帳號的完整控制。
• roles/billing.user — 連結專案至帳單帳號。
• roles/billing.viewer — 唯讀發票與報表。
• roles/billing.costsManager — 管理 budgets、檢視成本，但不可變更帳單層級的設定。

此處的最小權限原則至關重要：多數工程師應該拿 costsManager，而非 admin。不小心給出 billing.admin 等於放任有人把正式環境專案解除連結。

整合在一起 — 參考成本架構

正式等級的 GCP 成本架構結合以上所有層次：

1. Organisation 階層：以 folders 切業務單位，每個 folder 連到單一帳單帳號。
2. Label 分類體系：由 Org Policy 與 Terraform CI 強制。
3. Resource-based 3 年期 CUDs 覆蓋穩定的正式環境基線；突發與批次工作負載用 on-demand + Spot。
4. Detailed billing export 匯入 finops-warehouse BigQuery dataset，按 _PARTITIONTIME 分區。
5. Looker Studio 儀表板 建在 export 之上，做 per-team chargeback，每日更新並保留 5 天緩衝。
6. Budgets 在每個專案設 50% / 90% / 100% / 120% 預測值閾值；100% 閾值連到 Pub/Sub 觸發的 Cloud Function，自動解除失控 sandbox 的帳單連結。
7. Cloud Quotas 在 dev / sandbox folder 對 GPU、public IP、Cloud SQL CPU 設預防性硬上限。
8. Recommender API 每週由 Cloud Workflows 管線掃描，自動套用 idle-disk 刪除並寄信通知 right-sizing 候選。
9. Carbon Footprint export 與 billing export join 起來算永續性 KPI。
10. 月結 在第 +5 日進行，最終對帳 在第 +30 日，以吸收延遲的 credits。

這是 PCA 等級的標準架構；你應該能在白板上畫出來並為每一個方塊辯護。

FAQ — GCP 上的 Capex/Opex 與成本最佳化

Q1. 何時該選 1 年期 CUD vs 3 年期 CUD？

當工作負載穩定但底層技術可能演進時（例如預期一年內從 N1 遷到 N2），請選 1 年期 CUD。當基礎正式環境工作負載你打定主意要長期跑在同一系列上時，請選 3 年期 CUD — 比 1 年期多出來的約 20 個百分點折扣通常在 18 個月內就會回本。

Q2. Sustained Use Discounts 能否與 Committed Use Discounts 共用？

CUDs 先套用到你的使用量；剩餘的 on-demand 使用量再賺取 SUDs。你永遠不會「雙重折扣」 — 但同樣不會因兩者並存而吃虧。SUDs 只套用在承諾額度之上的殘餘 on-demand 部分。

Q3. Preemptible VMs 與 Spot VMs 有何差異？

Preemptible VMs（舊版）有 24 小時的硬性執行上限與固定折扣。Spot VMs（替代品，2021 年起 GA）沒有執行時間上限但折扣是浮動的 — 最高 91% 折扣會隨需求波動。兩者都能被 30 秒 SIGTERM 搶占。新設計應使用 Spot；Preemptible 僅保留作為向後相容。

Q4. Budget 能單獨阻止工作負載繼續運行嗎？

不行。Budgets 只通知（email + Pub/Sub）。要強制硬停，必須把 Pub/Sub topic 接到 Cloud Function 並呼叫 projects.updateBillingInfo(billingAccountName="") — 解除帳單連結可阻止新資源建立，並在短暫寬限期後停下多數資源。Quotas 才是事前阻止資源建立的唯一機制。

Q5. 如何把成本歸屬到與另外三組共用一個專案的某個團隊？

在團隊擁有的每個資源上掛 labels（team=engineering-platform、cost_center=cc-12345），然後在 billing export 上以 GROUP BY (SELECT value FROM UNNEST(labels) WHERE key='team') 查詢。若 labels 不可靠，請改成一個團隊一個專案 — 專案邊界是唯一零模糊的計費維度。

Q6. Recommender API 收費嗎？

不收。Recommender insights 與取得它們的 API 呼叫都是免費。你只為自己採取的動作付費（例如刪除 disk 前的 snapshot）。題目提到「不需額外成本即可偵測節省機會」就是在指 Recommender。

Q7. BigQuery 帳單匯出的資料有多新？

標準匯出延遲約數小時，但完整對帳對多數 credits 而言可能延後到 5 天，少數長尾調整甚至要 30 天。引用前期成本時，請至少保留 5 天緩衝；月結對帳請在第 30 天再跑一次以取得審計級數字。

最後的架構師建議

GCP 上的成本最佳化不是一次性專案，而是一套持續實踐，含三個回饋迴圈：每日（budgets 與 alerts）、每週（Recommender 檢視）、每季（CUD / slot commitment 重新議定）。考試獎勵那些從第一天就把這些迴圈織進設計裡的考生，而非在收到驚人帳單後才補強的人。猶豫時，請選那個技術上正確又會在 billing export 上產生最小一筆金額的架構 — 它幾乎一定就是出題人想要的答案。