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

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

最容易出問題的情況，是只記住「一台免費 VM」或「每月 200 萬次請求」，卻漏看區域、計算範圍、網路流量、磁碟與其他相依資源。另一個常見誤會，是以為建立 Budget 之後，Google Cloud 會在金額到達時自動斷電。官方文件寫得很清楚：Budget 是警示，不是消費上限，而且用量發生到帳務資料出現之間會有延遲。

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

先分清楚四種「免費」

類型	內容	到期方式	超過之後
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 天試用，現行方案沒有結束日期；它也不是十年不變的保證。

一、$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 的總使用時間，上限等於當月小時數。若同時開兩台，免費時數會更快耗完。

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

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 很重要，但它不會幫你踩煞車

Cloud Billing Budget 可以依 billing account、project、service 等條件追蹤實際或預測成本，並在門檻到達時寄信或送出 Pub/Sub 通知。

建議初學者至少建立：

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

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

為什麼不能把 Budget 當上限？

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

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

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

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

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

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，而不是做到畫面成功就關瀏覽器。

# 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 熟悉 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 秒檢查

帳務

我知道目前是 Free Trial 還是 Paid billing account
我知道 trial 到期日與剩餘 credit
這個 project 已有低門檻 Budget 與可收到信的通知對象

資源

我看過產品 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、儲存、建置與相依服務都可能另外計費。

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

不會。Budget 只產生警示，成本資料也有延遲。要降低風險，應同時使用低門檻通知、規模限制、quota、權限隔離、生命週期與固定清理流程。

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

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

結論

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

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

官方資料

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