Google Cloud 免費試用與 Free Tier 完整指南：怎麼練習又不讓帳單失控

Google Cloud 有免費試用，也有部分產品的每月免費用量，但「有 Free Tier」和「不可能收到帳單」是兩件不同的事。

最容易出問題的情況，是只記住「一台免費 VM」或「每月 200 萬次請求」，卻漏看區域、計算範圍、網路流量、磁碟與其他相依資源。另一個常見誤會，是把所有 Budget 都當成相同機制：一般的 Alerts-only Budget 只警示、不會限制消費；2026 年推出 Preview 的 Spend Cap Budget 能暫停部分合格服務的新用量，但範圍有限、不是即時，也不會停止所有持續性費用。

這篇不承諾「照做就永遠零元」，而是把免費方案的邊界和實際防護方法整理清楚。以下內容以 2026-08-04 的官方文件為準，實作前仍應再看一次 Google Cloud Free Program 的最新表格。

Google Cloud 免費資源與安全護欄：限時試用額度、每月重置用量、暫時 Lab 與促銷方案分別進入練習專案；預算告警只會提醒，真正限制風險要靠關機、配額、區域限制與資源清理 — 「免費」至少有四種機制：一次性的 Trial Credit、每月重置的 Free Tier、隔離且會回收的 Lab，以及期間限定 Promotion。它們的到期與計費規則不同；右上角的開門特別提醒： **Alerts-only Budget 只按鈴，不會替你關資源**；Spend Cap 也只涵蓋合格服務，完整護欄仍要靠配額、權限、規模限制與清理流程。

先分清楚四種「免費」

Google Cloud 四種免費類型：一次性的免費試用額度、每月有服務與區域限制的 Free Tier、各有條款與期限的產品促銷，以及限指定課程或 Lab 的點數 — 「免費」可能是一次性試用、每月用量額度、產品促銷或課程點數，四者不能混用。啟用前要核對 Billing、 SKU、Region、重置或到期時間，以及超過限制後是停止服務還是開始計費。

類型	內容	到期方式	超過之後
Free Trial	新符合資格的使用者取得 $300 Welcome credit	啟用後 90 天，或額度先用完	未升級為付費帳號時，試用帳務帳戶關閉、資源停止
Free Tier	指定產品每月有一定免費用量	官方目前沒有結束日期，但可提前 30 天通知後調整	付費帳號按標準費率計費；試用帳號由 Welcome credit 支付
產品專屬試用	例如 Cloud SQL、Spanner 或 AlloyDB 的個別試用	每項產品有自己的期限與條件	依該產品方案處理
免費工具或學習環境	例如 Cloud Shell、部分 Skills Boost lab	依服務規則與課程資格	不一定能保存正式專案的長期資源

以前許多文章把 Free Tier 稱為 Always Free。官方頁面目前仍會使用「always-free products」這類行銷文字，但條款同時保留調整或取消額度的權利。所以比較精確的說法是：它不是 90 天試用，現行方案沒有結束日期；它也不是十年不變的保證。

新符合資格的使用者進入 90 天或 300 美元先到為準的 Free Trial；期間也可使用月度 Free Tier。手動升級後保留原期限內未用完的 credit，但超出抵免與 Free Tier 的用量會計費；未升級而試用結束則停止資源並進入 30 天 grace period。

一、$300／90 天免費試用怎麼運作？

誰符合資格？

依官方目前規則，申請者必須同時符合：

過去不曾成為 Google Cloud、Google Maps Platform 或 Firebase 的付費使用者
過去沒有申請過 Google Cloud Free Trial

申請時需要有效的信用卡或其他付款方式，某些國家也可能要求銀行帳戶驗證。Google 會送出小額的暫時授權保留來驗證付款方式；這不是正式扣款，解除時間則由銀行處理。

如果資格、付款方式或國家規定與你看到的教學不同，以 Console 顯示的條款為準，不要為了取得重複試用而建立多組帳號。

試用期間會不會扣款？

Free Trial billing account 在試用期間不會被 Google Cloud 用量收費。試用會在下列任一條件先發生時結束：

啟用後經過 90 天
$300 Welcome credit 用完
你手動升級成 Paid billing account

手動升級後，剩餘額度仍可用到原本 90 天期限，但付費帳號會對「未被剩餘額度、Free Tier 或其他抵免涵蓋」的用量收費。按下 Activate 之前，要先把它視為正式的付費環境，而不是免費試用的無風險延長。

試用結束後資源會怎樣？

如果 90 天到期或額度用完，而且沒有升級為付費帳號，Free Trial billing account 會關閉，專案中的資源停止，並進入 30 天 grace period。這段時間升級，可能可以復原資源與資料；若沒有升級，試用資源會被永久刪除。

不要把 grace period 當成備份機制。重要程式碼應在版本控制，資料也要在試用結束前匯出到合適的位置。

試用帳號有哪些限制？

目前官方列出的限制包括：

不能為 VM 加上 GPU
不能使用 Google Cloud Marketplace
不能申請提高 quota
不能建立 Windows Server 映像的 VM
不能建立 VMware Engine 資源
$300 額度不能支付 Google AI Studio 的 Gemini API，也不能用於指定的第三方生成式 AI 模型

限制會變動，不要背過去文章中的固定 vCPU 或 GKE 節點數。要做特定 lab 前，直接查該產品的 quota 與 Free Trial restrictions。

二、Free Tier 是「每月用量」，不是免費產品清單

使用 Free Tier 仍需要有效的 Cloud Billing account。每項服務各自規定：

用量按 billing account 還是 project 計算
是每日還是每月重設
哪些地區符合
免費的是運算、儲存、操作次數，還是其中一部分
網路出站、IPv4、建置產物與相依服務是否另計

如果付費帳號超過限額，超出的部分會照標準費率計費。未使用的額度通常也不能累積到下個月。

下面只整理初學者最常用的項目，不把二十多個產品全部抄進文章。完整且即時的數字應以官方 Free Tier 表格與各產品 pricing page 為準。

常用 Free Tier 額度速查

產品	目前免費用量摘要	最容易漏看的條件
Compute Engine	每月相當於 1 個 non-preemptible `e2-micro` 的時數、30 GB-month standard persistent disk、1 GB 北美對外傳輸	VM 限 `us-west1`、`us-central1`、`us-east1`；總時數跨符合區域合併計算；GPU、TPU 不免費
Cloud Run	request-based billing 每月 200 萬次請求、180,000 vCPU-seconds、360,000 GB-seconds memory、1 GB 北美對外傳輸	三種額度都可能先用完；建置、映像、log、網路與相依服務另算
Cloud Storage	每月 5 GB-month regional storage、5,000 次 Class A、50,000 次 Class B、100 GB 指定北美對外傳輸	儲存額度只適用 `us-east1`、`us-west1`、`us-central1`，且跨三區合併計算
BigQuery	每月 1 TiB query、10 GiB storage	查詢掃描量與儲存量分開計算；不是每個 project 各 1 TiB 的承諾
Firestore	每 project 1 GiB storage；每日 50,000 reads、20,000 writes、20,000 deletes；每月 10 GiB outbound	讀寫刪除按天、儲存與流量按月；索引與備份等功能另看 pricing
App Engine	只限 Standard：每日 28 F1 instance-hours、9 B1 instance-hours、1 GB outbound	Flexible 不適用；instance-hours 是所有執行個體加總，不是單台時鐘時間
Cloud Build	每月 2,500 build-minutes，限 `e2-standard-2`	其他 machine type、private pool 與建置產物可能收費
Artifact Registry	每月 0.5 GB storage	舊映像與多個 tag 會累積；資料傳輸與弱點掃描另看方案
Cloud Logging	每 project 每月前 50 GiB log data，預設保留期內不另收 retention	高流量 access log 很快累積；自訂 retention、route 與其他 Observability 項目分開計費
Pub/Sub	每月 10 GiB messages	跨區或網路傳輸仍要看架構與 pricing
Secret Manager	每月 6 個 active secret versions、10,000 次 access operations、3 次 rotation notifications	Secret 與 version 不同；停用或舊 version 也要盤點
GKE	每月抵免一個 Autopilot 或 zonal Standard cluster 的 cluster charge	只抵 cluster charge，節點運算、儲存與網路仍可能計費
Cloud Shell	免費使用，含 5 GB persistent disk	適合互動式管理與練習，不是 24 小時應用主機

表格中的單位也值得看懂。例如「一個 e2-micro」其實是符合區域內所有 e2-micro 的總使用時間，上限等於當月小時數。若同時開兩台，免費時數會更快耗完。

VM、Cloud Run、BigQuery 與 GKE 各自都有 Free Tier 入口，但實際架構還會建立磁碟、IP、映像、建置、日誌、資料庫、網路、節點與負載平衡器；每個 SKU 都要分別確認區域、額度與計費條件。

三、三個最常踩到的「我以為免費」

1. VM 停止後，其他資源仍可能計費

停止 Compute Engine VM 通常會停止 vCPU 與記憶體的執行費，但 persistent disk、snapshot、部分外部 IP、映像與網路資源可能繼續存在。真正不再需要時，要盤點並刪除相依資源，不是只看 VM 狀態顯示 TERMINATED。

# 執行個體
gcloud compute instances list

# 即使 VM 停止，也要另外檢查磁碟與保留的 IP
gcloud compute disks list
gcloud compute addresses list
gcloud compute snapshots list

刪除前先確認資料與目標 project、zone。教學文章裡的一行 delete 指令很簡單，資料救援通常不簡單。

2. Cloud Run scale to zero，不代表整套系統零成本

沒有請求時，Cloud Run service 可以縮到零個執行個體；但一個實際部署還可能用到：

Cloud Build
Artifact Registry
Cloud Logging
Cloud SQL、Firestore、Storage 或 Secret Manager
對外與跨區資料傳輸
minimum instances 或 instance-based billing

部署測試服務時可以先限制最大執行個體：

gcloud run deploy hello-lab \
  --source=. \
  --region=us-central1 \
  --no-allow-unauthenticated \
  --max-instances=2 \
  --memory=256Mi

這能限制服務擴張速度，但不是帳單硬上限。若程式會呼叫付費 API、寫大量 log 或產生大量網路流量，兩個執行個體仍可能花錢。

3. 選到 Free Tier 地區，不代表所有流量都免費

Compute Engine 與 Cloud Storage 的免費額度只適用指定美國區域，網路額度也有來源與目的地條件。把應用放在美國、資料庫放在台灣，可能省到一項運算，卻增加延遲與跨區傳輸。

區域選擇應先考慮資料位置、使用者延遲、法規與整套架構成本，不能只挑價格表上看起來免費的一格。

四、Budget 很重要，但要分清楚兩種模式

Alerts-only Budget 與成本防護流程：資源用量形成帳單，跨過門檻後透過 Email 或 Pub/Sub 通知人工或自動化流程，但不會自動停止資源；Quota、Org Policy 與 Sandbox 是另一層事前護欄 — 這張圖描述一般的 Alerts-only Budget：它是偵測與通知機制，不是硬性消費上限。要降低意外帳單，仍需用 Quota、Org Policy、Sandbox Project、規模限制與清理流程做事前防護。

Cloud Billing 目前提供兩種目的不同的 Budget：

模式	能做什麼	不能保證什麼
Alerts-only Budget	依範圍追蹤實際或預測成本，以 email／Pub/Sub 發送通知	不會在門檻到達時停止服務或計費
Spend Cap Budget	Preview；到 100% 時暫停單一 project、單一合格服務的新用量	不涵蓋所有服務；不是即時；不停止 in-flight request 或持續性固定費用

Alerts-only Budget：監測整體成本

Alerts-only Budget 可以依 billing account、project、service 等條件追蹤實際或預測成本，並在門檻到達時寄信或送出 Pub/Sub 通知。它適合做較廣的帳務監測。

建議初學者至少建立：

50% 實際支出警示：提早知道有用量
80% 實際支出警示：開始檢查並停止非必要資源
100% 實際支出警示：立即確認是哪個 SKU 增加
一個較低的 forecasted cost 警示：提早發現照目前速度會超出預算

門檻要依你真的願意支付的金額設定。官方建議把 Budget 設在可用金額以下，為帳務資料延遲留緩衝。

Spend Cap Budget：有限範圍的暫停機制

Spend Cap Budget 在 2026 年 7 月仍是 Preview，目前只能套用到單一 project 的單一合格服務。官方目前列出的服務包括 Gemini API、Agent Platform、Cloud Run 與 Cloud Run functions；清單可能繼續調整。

當估算的 gross usage cost 超過 100% 時，系統會暫停該服務的新用量，直到管理者手動解除。但要特別注意：

已在處理中的請求會執行完並可能產生費用
Persistent compute、storage 等持續性固定用量不會因此停止
執行不是即時的，延遲期間的超額費用仍由使用者負擔
成本按 gross cost 計算，不扣 Free Tier、credit 或 CUD 等 savings
不能涵蓋整個 billing account、多 project 或多服務

初學者若使用合格服務，可以在 sandbox project 評估 Spend Cap，同時保留涵蓋整體帳務的 Alerts-only Budget。因為它仍是 Preview，不應把正式環境的可用性全部綁在這個機制上。

Alerts-only Budget 在達到門檻後發出 email 或 Pub/Sub，再由人員或受控自動化處理；Spend Cap 只對單一 project 的單一合格服務生效，到 100% 後暫停新用量，但 in-flight request、非合格服務與持續性固定費用仍可能繼續。

為什麼 Alerts-only 不能當上限？

因為成本不是每一秒同步寫進 Billing：

資源使用到費用出現在報表之間有延遲
Budget email 只在門檻達成時發送
連接 Pub/Sub 後，狀態通知通常一天送出數次，第一則可能等數小時
Pub/Sub 是 at-least-once delivery，訊息可能重複或順序顛倒

因此，「Alerts-only 到 100% 就自動停掉所有服務」不是內建行為。自行串接的自動化若沒有去重、權限隔離與例外清單，還可能關掉正式環境、遺失資料，或只停止一部分資源卻讓其他費用繼續發生。

官方確實提供透過 Pub/Sub 和 Cloud Run function 控制資源或停用 billing 的範例，但它應被視為需要設計與測試的 FinOps 自動化，不是複製貼上就完成的防爆開關。

五、比「自動斷電」更可靠的練習環境做法

單一控制無法攔住所有費用。比較實際的做法是把身分與 project 隔離、規模與配額、Budget 偵測、資源生命週期和事後帳務確認疊在一起。

最外層先用獨立 project 與最小權限隔離，再限制服務、區域、規模與 quota；中間以 Alerts-only 和合格服務的 Spend Cap 偵測，接著用到期標記與清理流程縮短生命週期，最後回 Billing report 按 project、service、SKU 核對。

1. 練習專案和正式專案分開

建立專門的 sandbox project，不要在公司正式 project 直接照著教學開 API。分開之後，Budget、IAM、quota 與清理範圍都比較清楚。

專案命名可以讓用途和到期日一眼看懂，例如：

lab-cloud-run-202607
lab-bigquery-delete-20260731

再加上 owner、environment=sandbox、expires-on 等 label。Label 本身不會自動刪除資源，但能讓盤點與帳務篩選容易很多。

2. 先用 Cloud Shell 與臨時 lab

只是在練 gcloud、IAM 或某個引導式操作時，Cloud Shell 通常比開一台 VM 更合理。若課程提供 Skills Boost lab，優先使用課程配置的臨時帳號與專案；lab 結束後環境會回收，也不會和個人正式 billing 混在一起。

Cloud Shell 的 5 GB persistent disk 是工具設定與小型檔案空間，不應拿來長期託管服務或保存唯一一份資料。

3. 在建立資源時就限制規模

比起收到帳單後再停機，更有效的是一開始就縮小爆炸半徑：

Cloud Run 設定 max-instances
Compute Engine 使用小型 machine type，並檢查 boot disk 大小
BigQuery 在查詢前看 estimated bytes processed，必要時設定 maximum bytes billed
API 使用 quota 或 per-user quota，避免迴圈無限呼叫
資料設定 lifecycle 或 TTL，但先確認刪除與保留規則
不需要 public access 就不要開放 allUsers

Quota 可以限制資源量或 API 速率，但它也不是通用的金額上限。某些 quota 可以調高、某些資源不共用同一個 quota，而且網路與儲存仍可能獨立計費。

4. 每次 lab 都包含清理步驟

把「建立、驗證、清理、再次確認」當成完整 lab，而不是做到畫面成功就關瀏覽器。

Lab 從核對 project、帳務與區域開始，建立最小資源後立即驗證目標；接著列出相依資源、備份重要資料並清理，隔天再查 Billing report。若 SKU 仍增加，就回到資產盤點而不是重複建立。

# Cloud Run
gcloud run services list --region=us-central1
gcloud run services delete hello-lab --region=us-central1

# Compute Engine
gcloud compute instances list
gcloud compute disks list
gcloud compute addresses list

# Cloud Storage
gcloud storage buckets list

# Artifact Registry
gcloud artifacts repositories list --location=all

每條 delete 指令執行前都要確認目前的 project：

gcloud config get-value project

如果整個 project 只為一次練習而建，確認沒有重要資料與共用資源後，刪除 project 通常比逐項猜漏了什麼更完整。這是不可逆操作，必須在 Console 再核對 project ID 與保留需求。

5. 隔天再看一次 Billing report

清理完成不代表帳務資料已完整出現。隔天回 Billing report 檢查：

Cost by project
Cost by service
Cost by SKU
Credits 是否正確套用
是否還有持續增加的用量

若想長期學習 FinOps，可以把 detailed billing export 送到 BigQuery，再用標籤與 SKU 分析成本。不過 billing export 也會建立資料與查詢用量，仍要納入管理。

六、一個低風險的學習順序

如果你剛開始接觸 Google Cloud，不必第一天就開 GKE、Cloud SQL 和 GPU。

先在 Cloud Shell、Console 和臨時 lab 理解 project、IAM 與 Billing；再建立可立即刪除的 Storage、私人 Cloud Run 與受限 BigQuery 查詢；最後才學習會產生多個相依資源的 VM、Cloud Run 完整供應鏈與 GKE。每一階段都包含清理與帳務回查。

第一階段：不建立長期資源

用 Cloud Shell 熟悉 gcloud config、project 與 IAM
用 Console 查看 Billing account 類型、Free Trial 到期日與剩餘 credit
建立 project-scoped Budget 與 email 通知
完成 Skills Boost 的臨時 lab

第二階段：建立可立即刪除的資源

建立一個 Cloud Storage bucket，上傳測試檔後完整刪除
部署私人 Cloud Run service，測試後刪除 service 與舊映像
在 BigQuery 查詢前確認掃描量，不從 SELECT * 開始

第三階段：學習有相依資源的服務

Compute Engine：VM、boot disk、external IP 與 firewall 一起盤點
Cloud Run：build、Artifact Registry、Logging 與 downstream database 一起看
GKE：cluster charge、node、disk、load balancer 與 external IP 分開理解

這個順序的目的不是拖慢學習，而是先養成「看到架構圖就能列出計費資源」的習慣。

七、開始 lab 前的 60 秒檢查

先確認 billing account 類型與可接受金額，再核對價格、Region、Free Tier 條件與所有相依 SKU；接著確認規模限制、Budget、owner、結束時間、備份與刪除方法。任何一項不知道就先暫停查證，全部清楚才開始。

帳務

我知道目前是 Free Trial 還是 Paid billing account
我知道 trial 到期日與剩餘 credit
這個 project 已有低門檻 Alerts-only Budget；合格服務也評估過 Spend Cap

資源

我看過產品 pricing page，不只看教學文章
區域、machine type、儲存類別符合 Free Tier 條件
設定了合理的 maximum instances、quota 或查詢上限
知道這個服務還會建立哪些磁碟、映像、IP、log 或網路流量

清理

我知道如何列出剛建立的資源
我知道停止和刪除的差別
重要資料已有備份
lab 結束時間已記在行事曆或 project 名稱

常見問題

信用卡驗證的小額金額是帳單嗎？

申請試用時，Google 可能送出 $0 到 $1 美元之間的暫時授權保留。官方說明這不是實際扣款，銀行通常會在數天到一個月內解除。若交易狀態異常，應向銀行或 Cloud Billing support 確認。

Free Tier 可以不用綁 Billing account 嗎？

不行。官方要求有效的 Cloud Billing account 才能使用 Google Cloud Free Tier。免費的是符合條件的用量，不是免除帳務設定。

Paid billing account 用量在免費額度內，就一定是零元嗎？

不一定。一個服務可能同時使用多個 SKU，而 Free Tier 只涵蓋其中一部分。區域、網路出站、IPv4、儲存、建置與相依服務都可能另外計費。

Alerts-only Budget 設成 $1，費用會在 $1 停止嗎？

不會。Alerts-only Budget 只產生警示，成本資料也有延遲。若建立的是合格服務專用的 Spend Cap Budget，新用量會在門檻觸發後暫停，但執行不是即時，in-flight request、其他服務與持續性固定費用仍可能產生費用。

免費試用到期後，Free Tier 還能用嗎？

可以，但需要升級或另有有效的 billing account 才能繼續使用。Paid billing account 超過 Free Tier 或使用不受額度涵蓋的項目時，就會計費。

結論

Google Cloud 的免費方案很適合學習，但真正能避免意外帳單的不是背下二十個免費數字，而是理解每個數字的計算範圍。

把 Free Trial 當成有期限的抵免，把 Free Tier 當成附條件的月度用量，再用 Alerts-only Budget、合格服務的 Spend Cap、quota、maximum instances、獨立 project 與清理流程縮小風險。當你能回答「這個架構會建立哪些可計費資源」，才算真的掌握了免費方案。

官方資料

免費額度、區域、產品條件與 Spend Cap 支援清單可能調整。本文最後查核日期為 2026-08-04；建立資源前請再確認官方 Free Tier 表格、產品 pricing page 與 Console 顯示的 billing account 狀態。