防止 GCP 帳單爆炸，核心是做好 5 件事：保護 API 金鑰、刪除閒置服務、設定消費上限、啟用預設關閉的安全機制、建立即時監控。這 5 個步驟每步不超過一小時，但少做任何一步，就有機會讓你跟 Jesse 一樣，一覺醒來帳單多出台幣 58 萬。
真實案例：一覺醒來帳單暴增 2,500 倍
澳洲開發者的 25,000 澳幣慘劇
澳洲 AI 顧問 Jesse Davies 在 LinkedIn 和 Reddit 分享了他的親身經歷。
他在 Google AI Studio 做了一個小測試專案，用「Deploy to Cloud Run」一鍵部署到雲端，之後就沒再理它。
帳戶預算通知設定是 10 澳幣（約新台幣 210 元）。
某天早上起床，信用卡已經被扣了 10,000 澳幣。
他立刻聯絡 Google 客服。但在等待回覆的過程中，帳戶又被多刷了 15,000 澳幣。
最終帳單是 25,672.86 澳幣，折合約 18,391 美元（新台幣 58 萬左右）。
攻擊者做了什麼？他們根本沒有偷走 API 金鑰。
他們只是找到 Jesse 部署在 Cloud Run 上的公開網址，直接朝這個網址送請求。
Cloud Run 容器裡以明碼形式存放的 API 金鑰，就會幫攻擊者一筆一筆簽好請求，送到 Vertex AI 上去跑。
短短一個晚上，攻擊者送出了超過 60,000 次請求。
最後 Google 同意撤銷這筆費用，但這個過程讓 Jesse 整整驚嚇了好幾天。
原始貼文如下：
Google Cloud 自動升級消費上限的隱藏機制
這個案例裡還有一個關鍵細節，很多人不知道。
Davies 的帳戶原本是 Tier 2，消費上限大約是 2,000 美元。
Google Cloud 的帳單/用量層級可能會依帳戶歷史消費與資格自動提升；在某些案例中，Tier 2 帳戶累積消費達到門檻後，可能被提升到更高層級，對應上限可達 20,000 至 100,000 美元以上。
雖然不是「偷偷加額度」，但確實代表預設風控不足時，帳單風險會被放大 。
注意 Google 的 AI Studio 帳戶建立超過 30 天、且終生消費達 1,000 美元的帳戶，系統可能自動將可用消費額提高至 100,000 美元。這個機制設計初衷是讓正常業務不中斷，但在 GCP 帳單爆炸的情境下，它反而成為放大損失的燃料。
詳情可以查看以下連結：
https://ai.google.dev/gemini-api/docs/rate-limits?hl=zh-tw
後來 Google 就在 AI Studio 加入每月專案支出上限設定，一旦專案的支出超過上限，系統將在約 10 分鐘內暫停該專案的請求。
但也因為這個延遲，在這段期間內仍可能產生超額費用，並且還是由使用者自行負擔。
為什麼 GCP 帳單爆炸這麼容易發生？
GCP 帳單爆炸之所以容易發生，是因為 Google Cloud 的預設設定把 9 項安全機制全部關閉、消費上限設計成可自動升級，而開發者往往在測試後忘記關閉公開服務。三個條件同時成立，帳單爆炸就只差一個攻擊者。
API 金鑰公開在前端的致命風險
API 金鑰（API Key）是一組用來識別呼叫者身份的字串，當它出現在公開的前端程式碼或 URL 中，任何人都能用它以你的身份呼叫付費服務。
Google Maps API 金鑰數年前被設計成允許放在前端使用，因為當時 Maps API 的計費邏輯相對友善。
但後來 Gemini、Veo 等高價模型加入之後，這個設計就變成潛在漏洞：如果同一把 API 金鑰被賦予存取 Gemini 的權限，任何拿到這把金鑰的人都能用它呼叫 Gemini，費用算在你頭上。
資安公司 Truffle Security 在 2026 年 2 月已公開警告這個問題，詳情可以看這篇文章。
Cloud Run 部署後忘記關閉的代價
Cloud Run 是 GCP 的容器化服務執行平台，讓你可以把應用程式打包成容器並部署到雲端對外提供服務，預設為公開可存取。
問題在於：你的服務有一個公開的 HTTPS 網址，任何人都可以發請求給它。如果你的容器裡有 API 金鑰（特別是明碼形式存放的），每一次外部請求都會觸發真實的 API 呼叫，並產生費用。
很多開發者在測試完之後，只是停用服務，沒有完整刪除。
只要網址還在、API 還沒停掉，攻擊者只要找到這個網址，就能開始刷費用。
GCP 預設關閉的 9 項安全機制是什麼
Davies 在事後整理發現，Google Cloud 內建了 9 項安全機制，可以有效阻擋這類攻擊。
但它們全部預設關閉，需要你自己進設定頁面逐一啟用。
這 9 項機制包含：
- API 金鑰的 HTTP referrer 限制
- IP 位址限制
- Cloud Audit Logs 稽核日誌
- Cost Anomaly Detection 成本異常偵測
- Cloud Armor 防護規則
- VPC Service Controls
- Budget Alert 預算警報
- Cloud Run 的身份驗證要求
- IAM 最小權限原則
後面的步驟章節會逐一說明如何啟用其中最關鍵的幾項。
防止 GCP 帳單爆炸：Step 1 保護你的 API 金鑰
API 金鑰是整個問題的核心。把它保護好，GCP 帳單爆炸的機率就降低 80% 以上。
不要把 API 金鑰以明碼形式放進環境變數
明碼環境變數（Plaintext Environment Variable）是指直接把 API 金鑰字串寫進容器設定或程式碼的做法，這樣做會讓任何能存取容器的人直接讀到金鑰值，是造成 GCP 帳單爆炸最常見的根本原因之一。
這樣做有 2 個根本問題：
- 任何能存取容器的人（包含攻擊者）都能直接讀到金鑰值
- 金鑰跟著容器映像一起存在，就算你之後想換金鑰，舊的映像版本裡還是有原本的金鑰
正確的做法是改用 GCP Secret Manager 或短期憑證來取代長期金鑰。
使用 GCP Secret Manager 管理敏感憑證
GCP Secret Manager 是 Google Cloud 提供的機密管理服務，讓你可以把 API 金鑰、密碼、憑證等敏感資料集中存放，並透過 IAM 權限控制誰可以讀取。
Secret Manager 的基本設定步驟
- 在 GCP Console 搜尋「Secret Manager」，進入服務頁面
- 點擊「建立密鑰」（Create Secret），輸入名稱（例如
gemini-api-key） - 在「密鑰值」欄位貼上你的 API 金鑰，點擊「建立密鑰版本」
- 進入 IAM 頁面，只賦予你的 Cloud Run 服務帳號「Secret Manager Secret Accessor」這個角色
- 在 Cloud Run 的程式碼中，改用 Secret Manager SDK 動態讀取金鑰，而不是從環境變數讀取
設定完成後，你的 API 金鑰不再存放於容器內部。就算攻擊者拿到容器映像，也讀不到金鑰內容。
搭配服務帳號短期 Token 取代長期金鑰
更進一步的做法是完全不使用 API 金鑰，改用服務帳號（Service Account）搭配短期 Token（OAuth 2.0 access token，一種有時效限制的身份驗證憑證）。
短期 Token 的有效期間最長為 3,600 秒（1 小時），到期後自動失效。
就算被攻擊者截取，也只有在有效期間內能被使用，損失窗口遠比長期 API 金鑰小得多。
設定方式：讓你的 Cloud Run 服務以特定服務帳號身份運行，並透過 Workload Identity 機制自動取得短期 Token，不需要手動管理任何長期憑證。
防止 GCP 帳單爆炸：Step 2 關閉或刪除閒置服務
就算你的 API 金鑰保護做得再好，只要有一個公開的服務端點還在運行，就是潛在的攻擊入口。
如何找出帳號內所有公開的 Cloud Run 服務
- 進入 GCP Console，在左側選單點擊「Cloud Run」
- 選擇你要檢查的專案，查看所有已部署的服務列表
- 對每個服務點擊進入，查看「觸發條件」（Triggers）和「安全性」（Security）分頁
- 確認「需要驗證」（Require authentication）是否已勾選，未勾選代表該服務完全公開
- 如果你不確定這個服務還有沒有在用，查看「指標」（Metrics）分頁，若過去 30 天請求數為 0，直接刪除
建議每季做一次這個檢查，把所有不再使用的服務清掉。
這些服務沒在使用時，沒有機器也沒有費用產生，但設定和網址仍然保留，你點擊一下網址它們就恢復運行。
除非你直接刪除，要不然隨時都會有被啟動的風險。
如果你擔心刪除後需要回復，可以先把部署設定（Cloud Run YAML 或 Terraform 設定）存到版本控制系統，之後需要時重新部署即可。
App Engine 和 Cloud Functions 的相同風險
Cloud Run 不是唯一有這個問題的服務。App Engine 和 Cloud Functions 也有相同的風險：
- App Engine 的版本（Version）在停用後，對應的 URL 在某些情況下仍然可存取
- Cloud Functions 的 HTTP 觸發函式預設也是公開的
- 這 2 個服務都需要同樣的定期清查動作
原則一樣：凡是超過 90 天沒有收到任何請求的服務，就直接刪除，不要只是停用。
防止 GCP 帳單爆炸：Step 3 設定消費上限與預算警報
API 金鑰保護和服務管理是預防攻擊，預算設定是當攻擊發生時的最後一道防線。
在 Google Cloud Console 建立預算通知
預算通知（Budget Alert）是 GCP 提供的消費警報機制，當你的消費達到設定門檻時，會發送 Email 通知。
設定步驟：
- 進入 GCP Console，點擊左側選單的「帳單」（Billing）
- 選擇「預算與快訊」（Budgets & alerts）
- 點擊「建立預算」（Create budget）
- 設定預算名稱和涵蓋範圍（可以只針對特定專案）
- 設定預算金額（例如新台幣 500 元）
- 在「快訊門檻」至少設定 50%、75%、100% 三個通知點
- 在「通知方式」填入你的 Email，或設定 Pub/Sub 主題以觸發自動化動作
PS. 你也可以像我這麼極端，我的通知門檻是「每多 1 USD 就直接通知 1 次」，雖然常看到通知信很煩，但能確保時時都能收到通知。
重要提醒：預算通知不會自動停止計費，它只發送通知。要真正截斷消費，你需要額外設定自動化動作（見下方步驟）。
了解 GCP 自動升級帳戶等級的觸發條件
這是 Davies 案例中讓損失放大 50 倍的關鍵機制，你一定要了解。
1,000 美元門檻與 100,000 美元上限的來龍去脈
根據 Google 官方說明，GCP 帳戶有信用額度分層機制：
- 新帳戶（建立未滿 30 天）：消費上限約在 2,000 美元
- 舊帳戶（建立超過 30 天）且終生消費達 1,000 美元：系統可能自動將上限提高至 20,000 至 100,000 美元
- 這個升級動作完全自動，不需要使用者確認，也不一定會發送通知
換句話說，你在不知情的狀況下，帳戶的實際可消費金額已經是你預期的 50 倍。
如何手動鎖定帳戶消費上限
GCP 目前沒有提供「硬性消費上限」功能（Hard Cap），只能透過以下 3 種方式控制：
- 透過預算快訊 + Cloud Pub/Sub + Cloud Functions 建立自動化截斷機制：當消費達到設定金額時，自動停用指定的 API 或服務 (要注意這個自動停用的 Cloud Functions 程式，還是要自己寫)
- 在個別 API 的 Google Cloud Console 設定中查看「配額」（Quota），把每日請求數限制在可接受的範圍
- 聯絡 Google Cloud 支援，要求在帳戶層級設定更嚴格的消費限制
這是目前最接近「硬性上限」的做法。需要一點工程工作，但一次設好就能長期保護你。
2026 4 月開始，AI Studio 可以設定上限
請先到 Google AI Studio Dashboard 選單的 Spend，再點擊 Set spend cap
設定 Gemini API 的每月花費上限
防止 GCP 帳單爆炸：Step 4 啟用 GCP 內建的安全機制
GCP 內建了 9 項安全機制，但全部預設關閉。這一節帶你把最關鍵的 3 項打開。
9 項預設關閉的安全設定在哪裡找
這 9 項設定散落在 GCP Console 的不同位置，沒有統一入口。你需要逐一進入各個服務的設定頁面手動啟用。
最快的方法是使用 GCP 的「安全性指揮中心」（Security Command Center，一個集中管理 GCP 安全問題的控制台）。
進入 GCP Console，搜尋「Security Command Center」，點擊「漏洞」（Vulnerabilities）分頁。
這裡會列出你帳號中偵測到的安全問題，包含沒有啟用身份驗證的 Cloud Run 服務、過於寬鬆的 IAM 權限等。
Security Command Center 的詳情可以查看這篇文章。
API 金鑰限制：綁定 HTTP referrer 與 IP 位址
如果你的 API 金鑰無法立刻換成 Secret Manager，至少要做這件事：限制 API 金鑰的使用範圍。
設定步驟：
- 進入 GCP Console，搜尋「API 和服務」（APIs & Services）
- 點擊「憑證」（Credentials）
- 找到你要保護的 API 金鑰，點擊進入編輯
- 在「應用程式限制」（Application restrictions）選擇「HTTP referrer（網站）」，填入你的網域（例如
https://yourdomain.com/*） - 在「API 限制」（API restrictions）選擇「限制金鑰」，只勾選這把金鑰真正需要使用的 API
- 點擊「儲存」
完成後，就算有人拿到你的 API 金鑰字串，在非你網域的環境下使用它，GCP 會直接拒絕這個請求。
設定只能呼叫哪些 API
啟用 Cloud Audit Logs 追蹤異常呼叫
Cloud Audit Logs（雲端稽核日誌）是 GCP 記錄所有 API 呼叫行為的機制，讓你在事後追查「誰在什麼時間呼叫了什麼 API」。
預設只有管理活動日誌（Admin Activity Logs）是開啟的。
資料存取日誌（Data Access Logs）預設關閉，但這才是追蹤異常 API 呼叫最重要的日誌。
啟用方式：
- 進入 GCP Console，搜尋「IAM 與管理員」（IAM & Admin）
- 點擊「稽核日誌」（Audit Logs）
- 找到你要啟用的服務（例如 AI Platform、Cloud Run），勾選「資料讀取」和「資料寫入」
- 點擊「儲存」
啟用之後，你就能在 Cloud Logging 中查詢：過去 24 小時內，所有 Gemini API 的呼叫次數、來源 IP、使用的金鑰。在異常發生時，你有完整的事後追查能力，也能把日誌資料提供給 Google 客服作為退款申請的佐證。
防止 GCP 帳單爆炸：Step 5 建立異常偵測與即時告警
前面 4 個步驟都是預防，這個步驟是監控——讓你在帳單失控的前 30 分鐘就收到通知，而不是睡一覺起來才發現。
Cost Anomaly Detection 的設定方式
Cost Anomaly Detection（成本異常偵測）是 GCP 的自動化機制，會分析你的歷史消費模式，當消費突然偏離預期時，發送警報 Email。
啟用方式：
- 進入 GCP Console，點擊「帳單」（Billing）
- 選擇「異常狀況」（Cost anomalies）分頁
- 點擊「管理異常狀況」，設定要自動產生門檻，或手動自己設定
- 在「通知設定」填入你想接收警報的 Email 地址
但要記住 AWS 那個案例的教訓：Cost Anomaly Detection 只涵蓋直接計費的服務。如果你透過 Marketplace 或第三方管道計費，這個偵測在那些項目上無效。記得確認你所有 GCP 服務的計費路徑。
為什麼光靠預算通知還不夠
預算通知有 2 個根本限制：
- Email 通知有延遲，GCP 帳單的計算週期不是即時的，有時候通知寄到的時候，費用早就超標了
- 預算通知只有在你的帳戶達到設定門檻時才發送，如果攻擊在短短幾小時內讓費用從 0 衝到 5,000 美元，中間你不會收到任何通知
這就是為什麼需要加上 Cloud Monitoring 的即時 Alerting Policy。
結合 Cloud Monitoring 設定即時 Alerting Policy
Cloud Monitoring（雲端監控）是 GCP 的指標監控服務，可以讓你針對任何 GCP 指標設定即時警報。
設定步驟：
- 進入 GCP Console，搜尋「Monitoring」，進入 Cloud Monitoring
- 點擊「警報」（Alerting），再點擊「建立政策」（Create Policy）
- 在「選取指標」中，搜尋
serviceruntime.googleapis.com/api/request_count（API 請求次數） - 設定觸發條件：例如「過去 10 分鐘內，Gemini API 的請求次數超過 1,000 次」
- 在「通知管道」設定你的 Email 或 Slack 通知
- 點擊「儲存」
完成後，當有人在 10 分鐘內對你的 API 發出超過 1,000 次請求，你的手機就會立刻收到警報，而不是隔天早上才看到帳單。
常見問題：帳單已經爆了，現在怎麼辦？
如果你看到這篇文章時，帳單已經在爆炸了，這個章節是給你的。動作越快，損失越小。
立刻停用金鑰和服務的操作順序
按照這個順序執行：
- 進入 GCP Console，點擊「API 和服務」→「憑證」，找到所有 API 金鑰，點擊刪除或停用
- 進入「Cloud Run」，找到所有公開服務，點擊「刪除」
- 進入「IAM 與管理員」，找到異常的服務帳號，點擊「停用」
- 進入「帳單」，查看「本月消費明細」，確認是哪個服務在產生費用
- 直接停用該服務對應的 API（進入「API 和服務」→「已啟用的 API 和服務」，找到對應的 API，點擊停用）
整個流程在 10 分鐘內應該可以完成。每晚一分鐘，就多幾美元的損失。
如何向 Google Cloud 申請帳單減免
Davies 的案例最後有退款，但這不是自動的，需要你主動申請。
申請步驟：
- 進入 GCP Console，點擊右上角的「支援」（Support）圖示 （要注意你有購買 Google 官方的技術支援方案）
- 選擇「建立案例」（Create case）
- 在問題類型選擇「帳單」（Billing）
- 詳細描述事件：攻擊發生的時間、你發現的方式、你已採取的緊急措施
- 附上 Cloud Audit Logs 的截圖或匯出資料，作為攻擊行為的佐證
- 明確要求「費用撤銷」（Credit request 或 Billing adjustment）
Google 不保證一定退款。但根據公開案例，在能提供明確攻擊證據、且帳號本身沒有不當行為的情況下，退款機率相當高。
隱藏密技，從這裡點選就不需要先購買技術支援方案。
被扣款後帳號被鎖定，怎麼取回日誌權限
這是 Davies 案例中最令人抓狂的環節：因為帳單欠款，GCP 帳號被限制，他一度無法進入 Cloud Logging 查看攻擊日誌。
如果你遇到這個狀況：
- 先嘗試透過 Google Cloud Console 的帳單頁面補繳欠款，部分情況下補繳後帳號限制會立刻解除
- 如果無法補繳（例如信用卡已被鎖定），直接聯絡 Google Cloud 支援，說明你正在收集攻擊佐證，需要暫時恢復日誌存取權限
- 要求 Google 客服協助匯出你帳號的 Audit Logs，這是他們技術上可以做到的事
- 同步提出費用撤銷申請，兩件事可以一起處理
結語：GCP 帳單爆炸不是你的錯，但防護是你的責任
GCP 的預設設定就是把 9 項安全機制全部關掉，把消費上限設計成會自動升級。這確實是平台設計的問題。
但等 Google 改好設計，可能要等很久。
防止 GCP 帳單爆炸，你能做的就是這 5 件事：保護 API 金鑰、刪除閒置服務、設定預算上限、啟用安全機制、建立即時監控。每一步都花不到一小時。但少做任何一步，都有機會讓你睡一覺起來帳單多出台幣 58 萬。
現在就去 GCP Console 打開那 9 項設定吧。
常見問題（FAQ）
Q1：GCP 預算通知設定後，消費真的會被自動停止嗎？ A：GCP 帳單爆炸最常見的誤解就是這個——預算通知只發 Email，不會自動停止計費。要實現自動截斷，需要額外設定 Cloud Pub/Sub 加上 Cloud Functions，讓警報觸發自動停用服務的程式。這個架構需要一點工程工作，但做一次就能保護所有專案。
Q2：我只是用 GCP 跑實驗，金額很小，需要這麼麻煩嗎？ A：需要。Davies 的案例就是從「只是跑個實驗」開始的。攻擊者不管你的帳戶是否在活躍使用，只要 Cloud Run 網址存在、API 金鑰有效，就是攻擊目標。實驗完成後，刪除服務是最小成本的防護動作，花不到 2 分鐘。
Q3：Secret Manager 收費嗎？費用大概是多少？ A：收費，但金額很小。根據 GCP 官方定價，Secret Manager 每 10,000 次存取操作收費 0.03 美元，每個活躍密鑰版本每月收費 0.06 美元。對大多數開發者來說，每月費用會在 1 美元以下，比起 GCP 帳單爆炸的風險，這筆錢完全值得。
Q4：我有多個 GCP 專案，每個都要做一遍嗎？ A：金鑰保護和服務清查需要在每個專案個別執行。但預算設定可以在帳單帳戶（Billing Account）層級設定，一次涵蓋所有專案。Cost Anomaly Detection 也可以在帳單帳戶層級啟用，不需要逐一設定。
Q5：如果我用的是 Firebase，也有同樣的風險嗎？ A：有。Firebase 專案底層就是 GCP 專案，Firebase 的 API 金鑰同樣可以用來呼叫 GCP 的付費服務。如果你在 Firebase 專案中啟用了 Gemini API 或其他付費服務，一樣需要做 API 金鑰的限制設定。
Q6：Cloud Armor 是什麼？它能防止帳單爆炸嗎？ A：Cloud Armor 是 GCP 的 Web Application Firewall（Web 應用程式防火牆），可以封鎖特定 IP、地區或請求模式。它能減少惡意請求的數量，但不能直接限制消費金額。建議把 Cloud Armor 當作補充防護，而不是主要防線，且它需要額外費用，適合已有穩定流量的正式服務。
Q7：Google Maps API 金鑰和 Gemini API 金鑰是同一把嗎？ A：在 GCP Console 裡，同一個專案的 API 金鑰預設可以存取該專案啟用的所有 API。如果你在同一個專案裡同時啟用了 Maps API 和 Gemini API，你的 Maps API 金鑰在技術上也能呼叫 Gemini。正確做法是在 API 金鑰設定中明確指定這把金鑰只能用於哪些 API。
Q8：我已經把 API 金鑰換掉了，舊金鑰還需要特別處理嗎？ A：需要立刻刪除舊金鑰。進入 GCP Console，點擊「API 和服務」→「憑證」，找到所有舊的 API 金鑰，點擊「刪除」而不是只是停用。停用的金鑰在特定條件下可能被重新啟用；刪除才能確保舊金鑰永久失效，是防止 GCP 帳單爆炸的必要步驟。
Q9：攻擊者是怎麼找到我的 Cloud Run 網址的？ A：常見的途徑有 3 種：在 GitHub、GitLab 或 Bitbucket 的公開 repo 中搜尋 Cloud Run 網址（攻擊者有自動化工具掃描這些平台）；透過搜尋引擎索引到公開的 API 文件或設定檔；從 Google AI Studio 的部署紀錄或相關社群貼文中找到。任何 Cloud Run 網址都不要出現在公開的程式碼或文件裡。
Q10：除了 GCP，其他雲端服務（AWS、Azure）也有同樣的問題嗎？ A：有，而且 AWS 還有額外的盲點。透過 AWS Marketplace 計費的 Bedrock 服務不在 AWS Cost Anomaly Detection 的偵測範圍內。Azure 的 API Management 服務有類似的公開端點風險。每個雲端平台的預設安全設定都不夠嚴格，原則相同：任何公開端點加上任何付費 API 的組合，都需要額外的保護機制。