路由（Routing）是網路世界裡「決定資料封包要走哪條路」的機制。

每一筆網路請求——不管是你打開網頁、傳訊息還是下載檔案——背後都是一包一包的資料在傳送。

這些資料包不會自己知道要去哪，需要有人告訴它「往這個方向走」。這個「決定方向」的過程，就叫路由。

用生活類比理解路由：郵差怎麼決定走哪條路

想像你寄一封信給台北市大安區的朋友。

郵差不會隨機亂走，他會查地址，然後依照規則：

1. 台北市的信先送到台北郵局
2. 大安區的信再分配到大安郵局
3. 最後才送到那條街

這個「查地址、決定往哪送」的流程，就是路由在做的事。

網路裡的路由器（Router）就是那個郵差。

它負責看每一個資料包的目的地 IP，然後決定要從哪個介面把它轉出去。

路由和交換器的差別：別再搞混了

很多新手會把路由器和交換器（Switch）搞混。這兩個東西做的事完全不同。

交換器工作在第二層（Layer 2）。

負責在同一個區域網路（LAN）內，根據 MAC 地址把資料送到對的設備。

路由器工作在第三層（Layer 3）。

負責在不同網路之間，根據 IP 地址決定資料要往哪個方向走。

簡單說：交換器負責同一棟大樓裡的傳遞，路由器負責跨城市的快遞。

路由器、路由表、路由協定：三個核心名詞一次搞懂

學路由會遇到三個常見名詞，先把它們搞清楚。

路由器（Router） 是負責轉發資料包的設備或系統，可以是實體硬體，也可以是軟體模擬的。

路由表（Routing Table） 是路由器內部存的一張「地圖」，記錄了「去哪個網段，要走哪個介面、經過哪個 Gateway」。路由器每次轉發資料包，都是查這張表做決定。

路由協定（Routing Protocol） 是路由器之間互相溝通、交換路由資訊的規則，常見的有 OSPF、BGP、RIP。這篇文章不深入這個主題，你只需要知道它的存在。

學路由對你的職涯有什麼幫助？

路由不是只有網路工程師才需要懂，它的應用範圍比你想的寬。

懂路由基礎，能讓你在排查問題、評估架構、技術面試這三個場景，明顯比不懂的人更有效率。

哪些工作會用到路由知識？

以下這些職位，在日常工作中都會直接或間接碰到路由。

IT 支援／網路管理員：

公司網路出問題，第一個被叫去查的就是這個職位。能看懂路由表、會用 traceroute 追蹤封包，排查速度至少快 3 倍。

後端工程師：

部署服務到雲端時，常遇到「服務起來了但連不到」的問題。這類問題中，超過 80% 和網路設定有關，路由是最常見的原因之一。

懂路由，能自己排查，不用每次都等網路部門。

DevOps／SRE 工程師：

管理 Kubernetes 叢集、設定 VPC、處理跨區域連線，每天都在和路由打交道。

這個職位對路由的要求是「不只懂概念，還要能動手設定」。

雲端架構師：

設計多雲或混合雲架構時，路由決定了不同環境之間怎麼互通。架構設計錯了，後面的問題會很難收拾。

資安工程師：

滲透測試、網路隔離、零信任架構，都需要理解路由才能判斷流量走向和攻擊面。

就算你現在的工作完全不碰網路，懂路由基礎也能讓你在跨部門溝通時更有效率。

你看得懂網路部門在說什麼，他們說的問題你能快速判斷是不是和你有關。

懂路由，能讓你在團隊裡做什麼？

懂路由不會讓你變成網路專家，但會讓你在以下 3 個場景明顯不同於不懂的人。

場景一：服務上線後出現連線問題

不懂路由的人：「我的程式沒問題，是網路的事，讓網路部門來看。」

懂路由的人：先跑 ip route show 和 traceroute，3 分鐘內確認問題是在路由層還是應用層，再決定要找誰。

這個差異在緊急事故（Incident）時非常明顯。

場景二：評估雲端架構方案

不懂路由的人：看著架構圖點頭，但不知道兩個 VPC 之間的流量怎麼走。

懂路由的人：能直接問「這兩個網段之間的路由是怎麼設定的？有沒有非對稱路由的風險？」，讓討論更具體。

場景三：技術面試

後端、MIS、網管 的技術面試，網路基礎幾乎是必考題。

能說「我實際操作過 ip route 和 traceroute」，比只說「我知道路由的概念」有說服力得多。

為什麼要學路由指令？

工程師遇到網路問題，路由是第一個要查的地方

當你遇到「連不到某台主機」「某個服務突然無法訪問」這類問題，在 90% 的情況下可以用路由指令在 3 分鐘內縮小範圍。

不是說路由一定是問題所在，而是查路由表的成本最低、最快能排除或確認。

常見的排查邏輯是這樣：

1. 查路由表，確認有沒有通往目標網段的路徑
2. 如果路徑存在，用 traceroute 看封包卡在哪一跳
3. 根據結果判斷是路由問題、防火牆問題還是目標主機問題

路由指令能幫你做什麼：診斷、追蹤、設定

路由指令不只能「查」，還能做 3 件事。

診斷：確認目前這台機器的路由表長什麼樣，有沒有缺少某個網段的路徑。

追蹤：用 traceroute 看資料包實際走了哪幾跳，每一跳花了多少時間，找出延遲或中斷的位置。

設定：手動新增或刪除靜態路由，讓特定流量走特定的路徑。

用 GCP Cloud Shell 練習路由指令：不用付費、不用安裝環境

什麼是 GCP Cloud Shell？

GCP Cloud Shell 是 Google Cloud Platform 提供的免費線上終端機環境，讓使用者直接在瀏覽器裡執行指令，不需要在自己的電腦安裝任何工具。它的底層是一台 Debian Linux 虛擬機，預裝了 gcloud、git、python、vim 等常用工具，每個 Google 帳號都可以免費使用，不需要信用卡。

如何開啟 GCP Cloud Shell：只需要 Google 帳號

不需要建立任何 GCP 專案，也不需要輸入付款資訊，只要有 Google 帳號就能開啟。

Step 1：登入 Google Cloud Console

打開瀏覽器，前往 console.cloud.google.com，用你的 Google 帳號登入。

如果是第一次使用，Google 會要求你同意服務條款，接受即可，不會產生任何費用。

Step 2：點擊右上角 Cloud Shell 圖示

登入後，畫面右上角有一個「>_」的圖示，點擊它。

這個圖示在通知鈴鐺的左邊，滑鼠移過去會顯示「啟用 Cloud Shell」。

Step 3：等待環境啟動

點擊後，畫面下方會出現一個終端機視窗，Cloud Shell 環境需要約 30 秒啟動。

啟動完成後，你會看到類似這樣的提示符：

user@cloudshell:~ (your-project-id)$

這代表你已經在 Cloud Shell 環境裡了，可以開始輸入指令。

Cloud Shell 的限制與注意事項：路由設定重啟後會還原

開始操作之前，有一件事要先說清楚。

Cloud Shell 是臨時環境，每次關閉視窗或閒置超過 20 分鐘後，系統可能會重置。

你用指令手動新增的路由，重啟後會消失。這是正常行為，不是你操作錯誤。

對學習來說這反而是好事：你可以放心嘗試各種指令，不用擔心把環境搞壞。

但如果你是要在正式環境設定路由，Cloud Shell 不適合，要改用固定的伺服器或網路設備。

安裝路由相關套件

確認環境：Cloud Shell 預裝了什麼

Cloud Shell 的底層是 Debian Linux，部分路由工具已經預裝，部分需要手動安裝。

先執行以下指令確認目前有哪些工具可用：

which ip route traceroute netstat

有出現路徑的代表已安裝，顯示空白的代表需要手動安裝。

安裝 net-tools（提供 route、netstat 指令）

net-tools 是舊版網路工具套件，提供 route 和 netstat 這兩個指令。

雖然這些指令在新版 Linux 上已被 iproute2 取代，但很多教學文件和舊系統還在用，學起來有備無患。

在 Cloud Shell 執行：

sudo apt-get install -y net-tools

安裝完成後確認：

route --version

有顯示版本號代表安裝成功。

安裝 iproute2（提供 ip route 指令）

iproute2 是現代 Linux 的標準網路工具套件，提供 ip 這個主指令，包含路由管理、網路介面管理等功能。

Cloud Shell 通常已預裝 iproute2，但還是確認一下：

ip -V

目前看來應該已經有安裝了

如果顯示「command not found」，執行以下指令安裝：

sudo apt-get install -y iproute2

安裝 traceroute（提供封包追蹤功能）

traceroute 用來追蹤資料包從你的機器到目標 IP 經過了哪幾個節點。

Cloud Shell 不一定預裝這個工具，執行以下指令安裝：

sudo apt-get install -y traceroute

安裝完成後確認：

traceroute --version

基本路由指令實作

套件都裝好後，現在開始實際操作。

查看目前的路由表：ip route show

ip route show 是查看路由表最常用的現代指令，在 Cloud Shell 執行：

ip route show

你會看到類似這樣的輸出：

default via 10.88.0.1 dev eth0 
10.88.0.0/16 dev eth0 proto kernel scope link src 10.88.0.4 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

輸出結果怎麼看：每個欄位的意思

這些看起來很陌生的文字，其實每個欄位都有明確意思：

第一段：如果包裹要寄到「外縣市」或「國外」怎麼辦？

當你的 Cloud Shell 需要連上網際網路（例如去 Google 抓資料），它通常不知道全世界每一台電腦的確切位置。這時候，它需要一個「預設」的處理方式，這就帶出了第一行輸出：

default via 10.88.0.1 dev eth0

• default（預設路由）：這代表「其他所有不知道該送去哪裡的包裹」。只要目的地不在我們家附近，就套用這個規則。
• via 10.88.0.1（經由）：把包裹交給 10.88.0.1 這個 IP 位址。這個角色叫做 Gateway（通訊閘 / 閘道器），你可以把它想成是「郵件總處理中心」。你的電腦只要把包裹丟給總中心，總中心就會幫你轉送到外部網路。
• dev eth0（網路介面卡裝置）：dev 是 device（裝置）的縮寫。eth0 是你這台電腦主要對外的Network Interface（網路介面卡）。你可以把它想成是郵局的「大門」或「主要的送貨卡車」。

小結一下這行的意思：「只要不知道送去哪的資料，一律從大門 (eth0) 送出去，交給總中心 (10.88.0.1) 幫忙處理。」

第二段：如果包裹只是要寄給「同一個社區的鄰居」呢？

既然我們知道怎麼把資料送到外部網路了，那如果你的 Cloud Shell 只是想跟「同一個 GCP 內部網路」裡的其他機器講話呢？這時候把包裹送到「總中心」就太繞路了，我們應該直接走社區通道送過去就好。這就是第二行規則存在的目的：

10.88.0.0/16 dev eth0 proto kernel scope link src 10.88.0.4

• 10.88.0.0/16（目標網段）：這代表你所在的「本地社區」，在網路術語中稱為 Subnet（子網路）。只要目標地址是 10.88 開頭的，就代表是鄰居。
• dev eth0：一樣，要出門還是得走郵局的大門（主要的網路卡）。
• proto kernel（通訊協定）：這表示這條規則是由作業系統的 Kernel（核心） 自動建立的，不是人類手動輸入的。
• scope link（範圍）：這代表目的地跟我們是在同一個實體或虛擬網路上（Link-local），可以直接對話，不需要經過剛剛那個總中心（Gateway）。
• src 10.88.0.4（來源 IP）：這個資訊非常關鍵！src 是 source（來源）的縮寫。它告訴我們，你現在正在使用的這台 Cloud Shell，它自己的 IP Address（IP 位址） 就是 10.88.0.4。這就像是你寄信時，寫在信封背面的「寄件人地址」。

小結一下這行的意思：「如果資料是要寄給同社區的鄰居 (10.88.0.0/16)，就直接從大門 (eth0) 送過去，並在信封寫上我的地址 (10.88.0.4)。」

第三段：電腦裡面如果還有「房中房」，該怎麼送信？

現在我們知道怎麼對外（第一行）和對鄰居（第二行）溝通了。但是，Cloud Shell 是一個專門給工程師用的環境，它裡面內建了一個叫做 Docker 的工具。Docker 可以在你的電腦裡面再切出很多個獨立的「虛擬小房間」（稱為 Container 容器）來跑程式。

既然是獨立的小房間，它們就需要專屬的內部信箱系統。這就自然接到了最後一行規則：

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

• 172.17.0.0/16：這是專門保留給 Docker 虛擬小房間（容器）使用的「內部專用網段」。
• dev docker0：這是一個 Virtual Bridge（虛擬網橋）。你可以把它想成通往那些內部小房間的「專屬內部門」。這扇門的名字叫 docker0。
• proto kernel scope link：跟上一段一樣，這是系統核心自動建立的直接連線規則。
• src 172.17.0.1：這是這扇「內部門」本身的 IP 位址，也就是小房間們的內部管理員地址。
• linkdown（連線狀態中斷）：這是一個很重要的狀態提示。它代表 docker0 這扇門目前是「關閉 / 未啟用」的狀態。為什麼呢？因為你現在可能還沒有在 Cloud Shell 裡面啟動任何 Docker 容器（小房間裡沒人），所以系統暫時把這個內部通道關閉以節省資源。

小結一下這行的意思：「如果要送信給內部的 Docker 小房間 (172.17.0.0/16)，要走專屬的內部門 (docker0)，不過這扇門目前是關著的 (linkdown)。」

總結

這三行連貫起來，就是你的 Cloud Shell 完整的網路溝通藍圖：

1. 對外交給閘道器（Gateway）。
2. 對鄰居自己直接送（並秀出了你自己的 IP 是 10.88.0.4）。
3. 對內部虛擬容器有專屬通道，但目前沒在使用中。

查看路由表（舊指令）：route -n

route -n 是舊版的路由表查詢指令。-n 代表不要解析 hostname，直接顯示 IP 數字，速度比較快。

route -n

輸出格式像這樣：

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.88.0.1       0.0.0.0         UG    0      0        0 eth0
10.88.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

ip route 和 route -n 的差別

這兩個指令看的是同一份路由表，只是顯示格式不同。

ip route show 是現代指令，輸出用 CIDR 格式（如 /28），功能更完整，建議優先使用。

route -n 是舊指令，輸出用傳統子網路遮罩格式（如 255.255.255.240），在舊系統或舊教學文件上比較常見。

兩個都會，在任何環境下都不會被卡住。

新增靜態路由：ip route add

靜態路由（Static Route）是指你手動告訴系統「去這個網段，要走這個 Gateway」，不透過任何路由協定自動學習。

Step 1：確認目標網段

假設你要新增一條路由，讓去 192.168.100.0/24 這個網段的流量，走 Gateway 10.88.0.1。

先確認這個網段目前沒有路由：

ip route show | grep 192.168.100

如果沒有輸出，代表目前沒有這條路由，可以新增。

Step 2：指定 Gateway

確認你的 Gateway IP 是否可以到達：

ping -c 3 10.88.0.1

看到 3 packets transmitted, 3 received 代表 Gateway 可以連通。

Step 3：執行新增指令並確認結果

執行以下指令新增路由：

sudo ip route add 192.168.100.0/24 via 10.88.0.1

新增後，立刻確認有沒有成功加進路由表：

ip route show | grep 192.168.100

如果看到：

192.168.100.0/24 via 10.88.0.1 dev eth0

代表新增成功。

刪除路由：ip route del

刪除路由的語法和新增幾乎一樣，只是把 add 換成 del：

sudo ip route del 192.168.100.0/24 via 10.88.0.1

刪除後確認：

ip route show | grep 192.168.100

沒有輸出代表刪除成功。

追蹤封包走哪條路：traceroute

traceroute 會顯示封包從你的機器出發，每經過一個路由節點就記錄一次，讓你看到完整的路徑。

試著追蹤到 Google DNS 的路徑：

traceroute 8.8.8.8

輸出：

每一行是一個「跳」（hop），左邊的數字是第幾跳，後面是那個節點的 IP 和三次往返時間。

* * * 代表那個節點沒有回應，可能設定了不回應 ICMP，不一定是問題。

實際案例：用路由指令診斷網路問題

情境：連不到某個 IP，怎麼用路由指令找出問題

假設你在 Cloud Shell 裡 ping 192.168.50.1 完全沒有回應，不知道問題出在哪。

以下是標準的排查流程。

Step 1：先查路由表，確認有沒有對應路徑

ip route show | grep 192.168.50

如果沒有輸出，代表路由表裡根本沒有去 192.168.50.0/24 的路徑。

這時封包會走 default 路由（default via 10.88.0.1）。

但如果 default Gateway 也不知道怎麼到那個網段，封包就會被丟棄。

這種情況下，問題就是「缺少路由」。解法是新增一條靜態路由，或確認這個網段是否真的可達。

Step 2：用 traceroute 找出封包卡在哪一跳

如果路由表有對應路徑，但還是連不到，執行：

traceroute 192.168.50.1

看封包在哪一跳停下來（顯示連續的 * * *）。

如果第 1 跳就是 * * *，問題在 Gateway 這層。

如果走了幾跳後才停，問題在中間某個路由節點或目標主機。

Step 3：根據結果判斷是路由問題還是其他問題

排查路由問題後，如果路徑是通的但還是連不到，問題通常在以下 3 個地方：

1. 目標主機的防火牆擋掉了 ICMP（ping 不通但服務可能正常）
2. 目標主機根本沒有在監聽
3. 兩邊的路由不對稱（你能到它，但它的回程路由不知道怎麼回到你）

路由指令能幫你排除「路徑本身」的問題，剩下的就要用其他工具（如 curl、telnet、nmap）繼續追查。

常見錯誤與排查

指令找不到（command not found）：套件沒裝好

執行指令時出現 command not found，代表那個套件還沒安裝。

對照前面「安裝路由相關套件」的章節，確認對應套件有沒有裝好。

如果安裝過程中出現錯誤，先執行：

sudo apt-get update

更新套件清單後再重新安裝。

新增路由後 ping 還是不通：Gateway 設定錯誤

新增路由成功，但目標還是 ping 不通，最常見的原因是 Gateway IP 設錯了。

確認你指定的 Gateway 在路由表裡是可達的：

ip route get <你的 Gateway IP>

正常會看到像這樣：

如果顯示 RTNETLINK answers: Network is unreachable，代表這個 Gateway 本身就不可達，路由設定沒有意義。

Cloud Shell 重啟後路由消失：這是正常行為

手動新增的路由，Cloud Shell 重啟後會消失。

這是 Cloud Shell 的設計限制，不是你的操作問題。

如果你需要每次啟動 Cloud Shell 都自動套用路由設定，可以把指令寫進 ~/.bashrc：

echo "sudo ip route add 192.168.100.0/24 via 10.88.0.1" >> ~/.bashrc

這只適合學習和測試用途，正式環境不應該這樣做。

總結：路由指令你只需要記住這幾條

學路由不需要記很多東西。把這 5 條指令在 GCP Cloud Shell 跑過一遍，下次遇到網路問題，你就有具體的排查起點。

1. ip route show — 查看路由表
2. route -n — 查看路由表（舊格式，舊系統適用）
3. sudo ip route add <網段> via <Gateway> — 新增靜態路由
4. sudo ip route del <網段> via <Gateway> — 刪除路由
5. traceroute <目標 IP> — 追蹤封包路徑

常見問題（FAQ）

Q1：我沒有 GCP 帳號，可以用 Cloud Shell 嗎？ A：只要有 Google 帳號（例如 Gmail）就可以使用 GCP Cloud Shell，不需要額外申請 GCP 帳號，也不需要信用卡。前往 console.cloud.google.com 登入後，點右上角「>_」圖示即可開啟，整個流程不會產生任何費用。

Q2：Cloud Shell 的免費額度會用完嗎？ A：Cloud Shell 每個月提供 50 小時的免費使用時間，一般學習和練習完全夠用。這篇文章示範的所有路由指令都在免費額度內，不會產生任何費用。

Q3：ip route 和 route -n 哪一個比較建議用？ A：優先使用 ip route show。它是現代 Linux 的標準路由查詢指令，輸出格式更清楚、功能更完整。route -n 在舊系統或舊文件上還是很常見，兩個都知道，在任何環境下都不會被卡住。

Q4：靜態路由和動態路由有什麼差別？ A：靜態路由是你手動設定的，告訴系統「去這個網段走這條路」，不會自動更新。動態路由透過路由協定（如 OSPF、BGP）讓路由器之間自動學習路徑，網路拓撲改變時會自動調整。學習階段用靜態路由就夠了，大型正式環境幾乎都用動態路由。

Q5：traceroute 輸出中的 * * * 是什麼意思？ A：* * * 代表那個節點在規定時間內沒有回應。這不一定是問題——很多路由器或防火牆設定為不回應 traceroute 的封包。如果最終能到達目標，中間出現 * * * 通常不影響實際連線。

Q6：怎麼知道我的預設 Gateway 是什麼？ A：執行 ip route show，找開頭是 default via 的那一行，後面的 IP 就是預設 Gateway。例如 default via 10.88.0.1 dev eth0，預設 Gateway 就是 10.88.0.1。

Q7：新增路由時出現 Error: any valid prefix is expected rather than，是什麼問題？ A：這個錯誤代表網段格式有誤。路由指令的網段必須用 CIDR 格式，例如 192.168.100.0/24，不能只寫 192.168.100。確認網段後面有加 /數字 的子網路遮罩，再重新執行。

Q8：可以用 Cloud Shell 練習路由以外的網路指令嗎？ A：可以。Cloud Shell 是完整的 Linux 環境，ping、curl、nslookup、dig、netstat、ss 等常見網路指令都能在這裡使用，部分需要先安裝套件。對於想從零學習 Linux 網路指令的人，Cloud Shell 是免費又方便的練習環境。

Q9：路由表裡的 Metric 數字代表什麼？ A：Metric 是路由的優先權分數，數字越小代表優先權越高。當路由表裡有超過 2 條都能到達同一目標的路由時，系統會選擇 Metric 較小的那條。在有多張網路卡或多個 Gateway 的環境裡，Metric 的設定會直接影響流量走向。

Q10：這篇文章的路由指令可以直接用在 GCP 的 VM 上嗎？ A：可以，但要注意：GCP VM 的網路由 VPC 管理，單純在 VM 內新增路由不一定能讓流量真正改道，還需要在 GCP Console 的 VPC 路由設定裡同步調整。Cloud Shell 適合學習路由指令語法，正式環境需要搭配 GCP 網路架構一起考慮。

The post 路由是什麼？網路必學基礎知識 first appeared on 東東 GCP 教學 - GCP 實戰講師.

真實案例：一覺醒來帳單暴增 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 個根本問題：

1. 任何能存取容器的人（包含攻擊者）都能直接讀到金鑰值
2. 金鑰跟著容器映像一起存在，就算你之後想換金鑰，舊的映像版本裡還是有原本的金鑰

正確的做法是改用 GCP Secret Manager 或短期憑證來取代長期金鑰。

使用 GCP Secret Manager 管理敏感憑證

GCP Secret Manager 是 Google Cloud 提供的機密管理服務，讓你可以把 API 金鑰、密碼、憑證等敏感資料集中存放，並透過 IAM 權限控制誰可以讀取。

Secret Manager 的基本設定步驟

1. 在 GCP Console 搜尋「Secret Manager」，進入服務頁面
2. 點擊「建立密鑰」（Create Secret），輸入名稱（例如 gemini-api-key）
3. 在「密鑰值」欄位貼上你的 API 金鑰，點擊「建立密鑰版本」
4. 進入 IAM 頁面，只賦予你的 Cloud Run 服務帳號「Secret Manager Secret Accessor」這個角色
5. 在 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 服務

1. 進入 GCP Console，在左側選單點擊「Cloud Run」
2. 選擇你要檢查的專案，查看所有已部署的服務列表
3. 對每個服務點擊進入，查看「觸發條件」（Triggers）和「安全性」（Security）分頁
4. 確認「需要驗證」（Require authentication）是否已勾選，未勾選代表該服務完全公開
5. 如果你不確定這個服務還有沒有在用，查看「指標」（Metrics）分頁，若過去 30 天請求數為 0，直接刪除

建議每季做一次這個檢查，把所有不再使用的服務清掉。

這些服務沒在使用時，沒有機器也沒有費用產生，但設定和網址仍然保留，你點擊一下網址它們就恢復運行。

除非你直接刪除，要不然隨時都會有被啟動的風險。

如果你擔心刪除後需要回復，可以先把部署設定（Cloud Run YAML 或 Terraform 設定）存到版本控制系統，之後需要時重新部署即可。

App Engine 和 Cloud Functions 的相同風險

Cloud Run 不是唯一有這個問題的服務。App Engine 和 Cloud Functions 也有相同的風險：

1. App Engine 的版本（Version）在停用後，對應的 URL 在某些情況下仍然可存取
2. Cloud Functions 的 HTTP 觸發函式預設也是公開的
3. 這 2 個服務都需要同樣的定期清查動作

原則一樣：凡是超過 90 天沒有收到任何請求的服務，就直接刪除，不要只是停用。

防止 GCP 帳單爆炸：Step 3 設定消費上限與預算警報

API 金鑰保護和服務管理是預防攻擊，預算設定是當攻擊發生時的最後一道防線。

在 Google Cloud Console 建立預算通知

預算通知（Budget Alert）是 GCP 提供的消費警報機制，當你的消費達到設定門檻時，會發送 Email 通知。

設定步驟：

1. 進入 GCP Console，點擊左側選單的「帳單」（Billing）
2. 選擇「預算與快訊」（Budgets & alerts）
3. 點擊「建立預算」（Create budget）
4. 設定預算名稱和涵蓋範圍（可以只針對特定專案）
5. 設定預算金額（例如新台幣 500 元）
6. 在「快訊門檻」至少設定 50%、75%、100% 三個通知點
7. 在「通知方式」填入你的 Email，或設定 Pub/Sub 主題以觸發自動化動作

PS. 你也可以像我這麼極端，我的通知門檻是「每多 1 USD 就直接通知 1 次」，雖然常看到通知信很煩，但能確保時時都能收到通知。

重要提醒：預算通知不會自動停止計費，它只發送通知。要真正截斷消費，你需要額外設定自動化動作（見下方步驟）。

了解 GCP 自動升級帳戶等級的觸發條件

這是 Davies 案例中讓損失放大 50 倍的關鍵機制，你一定要了解。

1,000 美元門檻與 100,000 美元上限的來龍去脈

根據 Google 官方說明，GCP 帳戶有信用額度分層機制：

1. 新帳戶（建立未滿 30 天）：消費上限約在 2,000 美元
2. 舊帳戶（建立超過 30 天）且終生消費達 1,000 美元：系統可能自動將上限提高至 20,000 至 100,000 美元
3. 這個升級動作完全自動，不需要使用者確認，也不一定會發送通知

換句話說，你在不知情的狀況下，帳戶的實際可消費金額已經是你預期的 50 倍。

如何手動鎖定帳戶消費上限

GCP 目前沒有提供「硬性消費上限」功能（Hard Cap），只能透過以下 3 種方式控制：

1. 透過預算快訊 + Cloud Pub/Sub + Cloud Functions 建立自動化截斷機制：當消費達到設定金額時，自動停用指定的 API 或服務 (要注意這個自動停用的 Cloud Functions 程式，還是要自己寫)
2. 在個別 API 的 Google Cloud Console 設定中查看「配額」（Quota），把每日請求數限制在可接受的範圍
3. 聯絡 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 金鑰的使用範圍。

設定步驟：

1. 進入 GCP Console，搜尋「API 和服務」（APIs & Services）
2. 點擊「憑證」（Credentials）
3. 找到你要保護的 API 金鑰，點擊進入編輯
4. 在「應用程式限制」（Application restrictions）選擇「HTTP referrer（網站）」，填入你的網域（例如 https://yourdomain.com/*）
5. 在「API 限制」（API restrictions）選擇「限制金鑰」，只勾選這把金鑰真正需要使用的 API
6. 點擊「儲存」

完成後，就算有人拿到你的 API 金鑰字串，在非你網域的環境下使用它，GCP 會直接拒絕這個請求。

設定只能呼叫哪些 API

啟用 Cloud Audit Logs 追蹤異常呼叫

Cloud Audit Logs（雲端稽核日誌）是 GCP 記錄所有 API 呼叫行為的機制，讓你在事後追查「誰在什麼時間呼叫了什麼 API」。

預設只有管理活動日誌（Admin Activity Logs）是開啟的。

資料存取日誌（Data Access Logs）預設關閉，但這才是追蹤異常 API 呼叫最重要的日誌。

啟用方式：

1. 進入 GCP Console，搜尋「IAM 與管理員」（IAM & Admin）
2. 點擊「稽核日誌」（Audit Logs）
3. 找到你要啟用的服務（例如 AI Platform、Cloud Run），勾選「資料讀取」和「資料寫入」
4. 點擊「儲存」

啟用之後，你就能在 Cloud Logging 中查詢：過去 24 小時內，所有 Gemini API 的呼叫次數、來源 IP、使用的金鑰。在異常發生時，你有完整的事後追查能力，也能把日誌資料提供給 Google 客服作為退款申請的佐證。

防止 GCP 帳單爆炸：Step 5 建立異常偵測與即時告警

前面 4 個步驟都是預防，這個步驟是監控——讓你在帳單失控的前 30 分鐘就收到通知，而不是睡一覺起來才發現。

Cost Anomaly Detection 的設定方式

Cost Anomaly Detection（成本異常偵測）是 GCP 的自動化機制，會分析你的歷史消費模式，當消費突然偏離預期時，發送警報 Email。

啟用方式：

1. 進入 GCP Console，點擊「帳單」（Billing）
2. 選擇「異常狀況」（Cost anomalies）分頁
3. 點擊「管理異常狀況」，設定要自動產生門檻，或手動自己設定
4. 在「通知設定」填入你想接收警報的 Email 地址

但要記住 AWS 那個案例的教訓：Cost Anomaly Detection 只涵蓋直接計費的服務。如果你透過 Marketplace 或第三方管道計費，這個偵測在那些項目上無效。記得確認你所有 GCP 服務的計費路徑。

為什麼光靠預算通知還不夠

預算通知有 2 個根本限制：

1. Email 通知有延遲，GCP 帳單的計算週期不是即時的，有時候通知寄到的時候，費用早就超標了
2. 預算通知只有在你的帳戶達到設定門檻時才發送，如果攻擊在短短幾小時內讓費用從 0 衝到 5,000 美元，中間你不會收到任何通知

這就是為什麼需要加上 Cloud Monitoring 的即時 Alerting Policy。

結合 Cloud Monitoring 設定即時 Alerting Policy

Cloud Monitoring（雲端監控）是 GCP 的指標監控服務，可以讓你針對任何 GCP 指標設定即時警報。

設定步驟：

1. 進入 GCP Console，搜尋「Monitoring」，進入 Cloud Monitoring
2. 點擊「警報」（Alerting），再點擊「建立政策」（Create Policy）
3. 在「選取指標」中，搜尋 serviceruntime.googleapis.com/api/request_count（API 請求次數）
4. 設定觸發條件：例如「過去 10 分鐘內，Gemini API 的請求次數超過 1,000 次」
5. 在「通知管道」設定你的 Email 或 Slack 通知
6. 點擊「儲存」

完成後，當有人在 10 分鐘內對你的 API 發出超過 1,000 次請求，你的手機就會立刻收到警報，而不是隔天早上才看到帳單。

常見問題：帳單已經爆了，現在怎麼辦？

如果你看到這篇文章時，帳單已經在爆炸了，這個章節是給你的。動作越快，損失越小。

立刻停用金鑰和服務的操作順序

按照這個順序執行：

1. 進入 GCP Console，點擊「API 和服務」→「憑證」，找到所有 API 金鑰，點擊刪除或停用
2. 進入「Cloud Run」，找到所有公開服務，點擊「刪除」
3. 進入「IAM 與管理員」，找到異常的服務帳號，點擊「停用」
4. 進入「帳單」，查看「本月消費明細」，確認是哪個服務在產生費用
5. 直接停用該服務對應的 API（進入「API 和服務」→「已啟用的 API 和服務」，找到對應的 API，點擊停用）

整個流程在 10 分鐘內應該可以完成。每晚一分鐘，就多幾美元的損失。

如何向 Google Cloud 申請帳單減免

Davies 的案例最後有退款，但這不是自動的，需要你主動申請。

申請步驟：

1. 進入 GCP Console，點擊右上角的「支援」（Support）圖示 （要注意你有購買 Google 官方的技術支援方案）
2. 選擇「建立案例」（Create case）
3. 在問題類型選擇「帳單」（Billing）
4. 詳細描述事件：攻擊發生的時間、你發現的方式、你已採取的緊急措施
5. 附上 Cloud Audit Logs 的截圖或匯出資料，作為攻擊行為的佐證
6. 明確要求「費用撤銷」（Credit request 或 Billing adjustment）

Google 不保證一定退款。但根據公開案例，在能提供明確攻擊證據、且帳號本身沒有不當行為的情況下，退款機率相當高。

隱藏密技，從這裡點選就不需要先購買技術支援方案。

被扣款後帳號被鎖定，怎麼取回日誌權限

這是 Davies 案例中最令人抓狂的環節：因為帳單欠款，GCP 帳號被限制，他一度無法進入 Cloud Logging 查看攻擊日誌。

如果你遇到這個狀況：

1. 先嘗試透過 Google Cloud Console 的帳單頁面補繳欠款，部分情況下補繳後帳號限制會立刻解除
2. 如果無法補繳（例如信用卡已被鎖定），直接聯絡 Google Cloud 支援，說明你正在收集攻擊佐證，需要暫時恢復日誌存取權限
3. 要求 Google 客服協助匯出你帳號的 Audit Logs，這是他們技術上可以做到的事
4. 同步提出費用撤銷申請，兩件事可以一起處理

結語：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 的組合，都需要額外的保護機制。

The post GCP 帳單爆炸防護指南：5 個步驟讓你不再睡醒崩潰 first appeared on 東東 GCP 教學 - GCP 實戰講師.

GCP Organization Policy（組織政策）是 Google Cloud 提供的集中式資安政策管理工具，讓管理員統一設定「全公司的資源可以怎麼使用」，透過 Constraints（約束條件）在 Organization、Folder、Project 三層結構中強制執行安全限制。與 IAM 管理「誰能做什麼」不同，Organization Policy 管理「任何人都不能做什麼」——違規操作一律擋下，不受 IAM 角色影響。

如果說 IAM 是管理「誰可以做什麼」的工具，那 GCP Organization Policy 就是管理「全公司的資源可以怎麼使用」的守門員。兩者看起來很像，但扮演的角色完全不同。

1. 什麼是 GCP Organization Policy？

什麼是 Organization Policy？

GCP Organization Policy Service 是 Google Cloud 的集中式治理工具，透過定義 Constraints（約束條件），在整個雲端環境中統一規定哪些行為被允許、哪些行為被禁止。它是一種「護欄機制（Guardrail）」——不論操作者是誰、擁有什麼 IAM 角色，只要行為違反政策，一律擋下。

Organization Policy 的設定方式，是透過定義一系列的 Constraints（約束條件） 來實現。每個 constraint 對應一個特定的 Google Cloud 行為，例如：

• 可不可以建立有公開 IP 的 VM？
• 可不可以使用未受信任的 OS 映像檔？
• Storage bucket 能不能公開存取？

這些 constraint 可以套用在組織（Organization）、資料夾（Folder）或專案（Project） 層級，並依照層級結構自動向下繼承。

為什麼 Organization Policy 比 IAM 更重要？

IAM 和 Organization Policy 是 Google Cloud 安全架構的兩個不同層次，不能互相取代：

Organization Policy 的優先層級高於 IAM 授權。就算某個使用者有 Compute Instance Admin 的 IAM 角色，如果組織政策規定「所有 VM 不得有外部 IP」，他一樣無法建立有外部 IP 的 VM。

用比喻來說：

• IAM 是「員工識別證」——決定某個人能不能進入這棟大樓、使用這台機器。
• Organization Policy 是「公司規章」——不管是誰，所有人都必須遵守，違規一律擋下。

2. Organization Policy 的資源層級繼承架構

它是怎麼運作的？

Google Cloud 的資源以樹狀結構組織：

Organization（組織）
    └── Folder（資料夾）
            └── Project（專案）
                    └── Resources（資源）

當在 Organization 層級設定一個 Organization Policy 時，這個政策會自動往下繼承到所有 Folder、Project 和資源。組織管理員可以用最少的設定，達到全面覆蓋的效果。

實際情境： 假設你在 Organization 層級設定政策，禁止任何 VM 使用外部 IP 位址，那麼整個組織底下的所有 Folder、所有 Project，都不能建立有外部 IP 的 VM——除非有特別的 Override 設定。

inheritFromParent 是什麼？為什麼重要？

inheritFromParent 是理解 Organization Policy 繼承機制的核心欄位。

• 預設（inheritFromParent: true）：子層節點（Folder 或 Project）從父層繼承政策。
• 設定 inheritFromParent: false：該節點完全切斷與父層的政策繼承，改用自己設定的政策。

一旦子節點設定 inheritFromParent: false，它的政策就完全獨立運作。即使 Organization 層級允許某個網域，這個允許對該 Folder 完全無效——Folder 只認自己設定的規則。這是安全架構設計中最容易踩到的陷阱之一。

具體案例：

• Organization 層級：允許 abc.com 的成員
• Apps Folder 層級：只允許 def.com 的成員，並設定 inheritFromParent: false

結果：嘗試把 peter@abc.com 加入 Apps Folder 底下某個 Project 的 IAM 政策，會直接失敗。因為 Apps Folder 已完全切斷繼承，只認 def.com。

3. 兩大核心 Constraint 類型：List vs Boolean

List Constraint（清單限制）

List Constraint 用「允許清單（Allow List）」或「拒絕清單（Deny List）」控制特定資源的使用範圍：

• Allow（允許）操作：只有清單內的值才被允許，其他的全部拒絕
• Deny（拒絕）操作：清單內的值被禁止，其他的則允許

例如：compute.trustedImageProjects 是一個 List Constraint，用 Allow 操作把特定 Project 列入白名單，代表整個組織只能從這個 Project 的映像檔建立 boot disk。

Boolean Constraint（布林限制）

Boolean Constraint 只有兩個選項：開（Enforced） 或 關（Not Enforced）。

例如：constraints/iam.disableServiceAccountCreation，設定為 Enforced 後，整個組織就無法建立新的服務帳戶。沒有白名單、沒有例外，就是一個開關。

4. 限制可信任映像檔來源：compute.trustedImageProjects

為什麼要控制 Boot Disk 映像檔來源？

在企業環境中，VM 使用的 OS 映像品質直接影響整體安全性。隨意使用公開市場上未經審核的映像檔，可能引入：

• 映像檔內含已知漏洞（CVE）
• 映像檔被植入惡意程式
• 不符合企業安全強化（Hardening）標準

企業安全團隊通常會維護一個「黃金映像（Golden Image）」專案，所有 VM 只能從這個專案中的映像建立。

如何設定？

要讓所有 VM 只使用安全強化的 OS 映像，需要同時完成兩個步驟：

1. 設定 Organization Policy：在 Organization 層級啟用 compute.trustedImageProjects，以 Allow 操作列入受信任的 Project（例如 security-images-project）當你使用 Allow 動作，它就是白名單的方式，同時，會阻擋所有不在白名單的映像檔。
2. 設定 IAM 權限：在 security-images-project 中，授予組織內使用者 compute.imageUser 角色，讓他們有讀取並使用映像的權限

Policy 確保大家只能用這個 Project 的映像；IAM 確保大家有權限存取這個 Project。兩個步驟缺一不可。

為什麼用 Allow 而不是 Deny？ 因為 Allow 的語義是「只有這些才被允許」，天然具有「排除其他所有選項」的效果。如果用 Deny，你只是拒絕了你列出的幾個專案，但其他未列出的公開映像仍然可以使用——這不是我們要的結果。

5. 限制專案建立權限：集中管理 Project Creator 角色

為什麼要集中控制專案建立？

當你建立好一個 GCP 的組織機構，你會看到任何在這個網域的人員都有這兩個權限，專案建立者和帳單帳戶建立者。

在大型企業中，如果所有人都能自由建立 GCP 專案，很快就會出現「專案蔓延（Project Sprawl）」——到處都是沒人管的孤兒專案，浪費資源又製造安全風險。

怎麼做？

只讓特定團隊建立專案，需要同時執行兩個步驟：

1. 移除一般使用者的 Project Creator 角色：在 Organization 層級，把所有使用者從 Project Creator 角色中移除，一般使用者就無法自行建立新專案
2. 授權指定團隊：把負責專案管理的 DevOps 團隊群組，加入 Organization 層級的 Project Creator 角色

注意：兩個步驟必須同時執行。只移除一般使用者但沒有指定誰來建立，專案建立會完全癱瘓；只授權 DevOps 但沒移除一般使用者，限制就沒有意義。

6. 控制 VM 的公開 IP 位址：保護生產環境安全

為什麼生產環境不應有公開 IP？

給 VM 一個公開 IP 位址，等於把它直接曝露在網際網路上。對於資料庫伺服器、內部 API 服務、或任何不需要對外的 VM 來說，這是巨大的安全風險——攻擊者可以直接掃描公開 IP，嘗試暴力破解 SSH 或進行 DDoS 攻擊。

如下圖你可以看到，當我建立好一臺虛擬機器時，隨時都有駭客在掃描我的外部 IP 並且嘗試登入。

如何同時保留前端 IP，鎖定其他 VM？

現實情況往往是：前端 Web 伺服器需要公開 IP，但後端應用程式和資料庫不應該有。

使用 constraints/compute.vmExternalIpAccess 這個 constraint，在政策中明確列出哪些 VM 實例可以使用外部 IP（以資源名稱方式列入 Allow 清單），其餘的 VM 自動被禁止。這比 VPC 分割更精準（VPC 分割以子網路為單位，無法做到 VM 層級的細粒度控制），也比移除 IAM 角色更直接，並且不依賴工程師手動記得不勾選外部 IP。

7. 服務帳戶安全管控：三大 IAM 約束條件

服務帳戶（Service Account）是 GCP 中機器身分的代表，也是許多安全事件的攻擊目標。Organization Policy 提供三個相關 constraint 加強管控：

三個 Constraint 快速比較

disableServiceAccountKeyCreation 和 disableServiceAccountCreation 是兩個功能完全不同的 constraint，不能混用。前者只限制「金鑰的建立」，服務帳戶本身還是存在的；後者才是直接禁止「服務帳戶的建立」。混淆這兩者，是企業安全配置中最常見的錯誤之一。

而 disableServiceAccountKeyUpload，是因爲用戶可以任意建立金鑰並且上傳到 GCP 上，聽起來很方便，但這個金鑰是怎麼產生的？密碼強度夠不夠？甚至不知道這個金鑰是不是每個人都有，或者甚至是駭客上傳的。因此，在資安上會造成潛在的威脅。

CI/CD 場景的最佳實務

在 CI/CD 場景中，建議：

1. 為 CI/CD cluster 建立一個專屬的自訂服務帳戶
2. 在 Project 層級啟用 constraints/iam.disableServiceAccountKeyCreation
3. 讓 CI/CD 工具改用 Workload Identity Federation (如 Github) 或 Instance Metadata Service 取得短期憑證

這樣即使有人嘗試為服務帳戶建立金鑰，也會被 Policy 阻擋，從源頭消除靜態憑證洩漏的風險。

8. 保護 Shared VPC 主機專案不被誤刪

什麼是 Shared VPC？為什麼需要保護？

Shared VPC（又稱 XPN，Cross-Project Networking）讓多個專案共享同一個 VPC 網路。其中的 Host Project（主機專案） 負責提供 VPC 資源給其他 Service Projects 使用。如果 Host Project 被誤刪，所有依賴這個 VPC 的服務都會瞬間斷線。

Google Cloud 會自動為 Shared VPC Host Project 加上 **Lien（留置權）**防止被誤刪，但若使用者有足夠權限，可以手動移除這個 Lien 再刪除專案。啟用 compute.restrictXpnProjectLienRemoval 這個 constraint 後，就算使用者有 Project 刪除權限，也無法移除 Shared VPC Host Project 的 Lien，從根本保護關鍵網路資源不被誤刪。

9. 網域限制共用政策：iam.allowedPolicyMemberDomains

為什麼要限制外部網域存取資源？

在預設情況下，Google Cloud 的 IAM 允許把任何 Google 帳戶加入專案的 IAM 政策。如果工程師不小心把外部 Gmail 帳戶加入專案，外部人員就能存取企業的雲端資源。

constraints/iam.allowedPolicyMemberDomains 讓你指定哪些網域（以 Google Workspace 客戶 ID 或 Cloud Identity 客戶 ID 方式指定）才能被加入 IAM 政策，不在清單內的網域一律無法被授予任何權限。

如何為外部合作夥伴開設例外政策？

在維持 iam.allowedPolicyMemberDomains 政策的前提下，為外部合作夥伴開設例外的正確流程：

1. 暫時關閉 iam.allowedPolicyMemberDomains 政策
2. 將政策值設定為「Custom（自訂）」
3. 把外部合作夥伴的 Cloud Identity 或 Google Workspace 客戶 ID 加入 constraint 的例外清單
4. 確認設定正確後，重新啟用政策

注意：把合作夥伴帳號加入 Google Group 不能繞過這個限制。這個 constraint 是以客戶 ID為單位做網域驗證的。

10. Cloud Storage 安全防護：防止資料對外公開洩漏

什麼是 storage.publicAccessPrevention？

constraints/storage.publicAccessPrevention 是專門防止 Cloud Storage 資料外洩的 constraint。啟用後，組織內所有 Cloud Storage bucket（包含未來新建立的）都無法被設定為允許匿名的公開存取。

建立完整的 Cloud Storage 存取控制，建議搭配兩個設定的「黃金組合」：啟用 storage.publicAccessPrevention（防止 bucket 被匿名公開存取）+ 啟用 Uniform Bucket-Level Access（關閉 ACL，統一改用 IAM 管理 bucket 存取）。前者防止資料因設定疏漏而意外公開，後者防止因外部帳號被加入 IAM 而導致外洩。兩者相輔相成，缺一不可。

11. 強制使用 CMEK 加密：gcp.restrictNonCmekServices

什麼是 CMEK？

CMEK（Customer-Managed Encryption Keys，客戶自管加密金鑰） 是 Google Cloud 提供的加密機制。預設情況下，Google Cloud 使用自己管理的金鑰（GMEK）加密資料。CMEK 讓企業可以使用自己在 Cloud KMS 中管理的金鑰進行加密。

企業強制使用 CMEK 的主要原因：

• 法規合規：金融業、醫療業、GDPR 場景可能要求對加密金鑰有完整控制權
• 資料主權：企業可以隨時撤銷金鑰，確保資料的最終控制權在自己手中
• 審計要求：所有金鑰的使用記錄都可以在 Cloud KMS 中審計

如何強制使用 CMEK？Deny 才是正確做法

constraints/gcp.restrictNonCmekServices 的語義是「限制哪些服務可以不使用 CMEK」。要強制所有 Cloud Storage 資源必須使用 CMEK，正確設定是使用 Deny 操作，將 storage.googleapis.com 列入拒絕清單。如果誤用 Allow 操作，代表的是「允許 Cloud Storage 不用 CMEK」，效果完全相反。這是實務配置中最容易搞反的邏輯之一。

正確設定範例：

constraint: gcp.restrictNonCmekServices
binding at: org1
policy type: deny
policy value: storage.googleapis.com

12. 資源地理位置限制：GDPR 合規的利器

什麼時候需要 Resource Location Restriction？

當企業需要遵守 GDPR 或其他有資料落地要求的法規時，確保所有 Google Cloud 資源只建立在特定地理區域是非常重要的合規要求。

限制 Google Cloud 資源只能建立在特定地理區域，唯一正確的工具是 constraints/gcp.resourceLocations（Resource Location Restriction）。常見的錯誤做法包括：使用 IAM 自訂角色（IAM 沒有以地理位置為條件的授權機制）、使用 Identity-Aware Proxy（IAP 是管理使用者對應用程式的存取，和資源建立地點無關）、使用 Restrict Resource Service Usage（這個 constraint 是限制服務使用，不是限制地理位置）。

constraints/gcp.resourceLocations 支援以 Region、Multi-region 或具體的 Zone 為單位設定限制，能夠非常精確地控制資源的建立位置。

13. 組織政策被繞過了怎麼辦？常見原因排查

為什麼政策對某個 Project 失效了？

假設你在 Folder 層級設定了政策，禁止所有 VM 使用外部 IP，但兩天後發現某個 Project 底下的 VM 竟然有外部 IP。

最常見原因： 該 Project 在 Project 層級對這個 constraint 設定了 Override，把政策值改成了「Allow」，因此 Folder 層級的禁止設定對這個 Project 失效了。

排查步驟

1. 到 Google Cloud Console → Organization Policy，找到該 constraint
2. 查看政策的繼承情況，確認各個層級的設定值
3. 找出哪個層級有 Override，然後移除或修正

在 Google Cloud 的 Organization Policy 機制中，子層的 Policy 可以覆蓋父層的 Policy（除非父層政策設定了不允許 Override）。「沉默代表繼承」——如果你希望某個 Folder 或 Project 有不同的行為，必須明確在那個層級設定 Override；如果沒有設定，就代表接受上層的政策設定，沒有任何例外。

14. 預設網路與 CI/CD 管道的安全配置

compute.skipDefaultNetworkCreation 是什麼？

當一個新的 Google Cloud Project 被建立時，系統預設會自動建立一個 Default VPC 網路。這個預設網路有幾個問題：

• 防火牆規則預設允許許多常見的輸入連線（如 SSH、RDP），不符合最小權限原則
• 大型組織中，每個 Project 都有預設網路，網路架構會變得混亂難以管理
• 工程師可能直接在預設網路上部署資源，沒有任何額外的安全配置

解決方法： 在 Organization 層級啟用 constraints/compute.skipDefaultNetworkCreation。啟用後，所有新建立的 Project 都不會自動產生預設 VPC 網路，工程師必須根據企業的網路架構規範手動建立符合要求的 VPC。

15. 備戰重點整理與常見觀念陷阱

GCP Organization Policy 六大常見陷阱：

1. Allow vs Deny 搞反：compute.trustedImageProjects 用 Allow（只允許白名單）；gcp.restrictNonCmekServices 用 Deny（禁止不用 CMEK）
2. Boolean Constraint 混用：disableServiceAccountCreation（禁建帳戶）≠ disableServiceAccountKeyCreation（禁建金鑰）
3. 繼承機制誤解：inheritFromParent: false 會讓子節點完全獨立，父層允許的規則在此完全無效
4. 地理位置限制用錯工具：要限制資源建立地區，只能用 gcp.resourceLocations，IAM 和 IAP 都做不到
5. Shared VPC 保護工具記錯：用 compute.restrictXpnProjectLienRemoval，不是 restrictSharedVpcHostProjects
6. Cloud Storage 防護不完整：storage.publicAccessPrevention 要搭配 Uniform Bucket-Level Access 才形成完整防線

結論

GCP Organization Policy 是 Google Cloud 安全架構中不可或缺的一環，它在 IAM 之上提供更高維度的護欄——無論誰來操作、用什麼角色，只要行為違反組織政策，就一律擋下。從映像檔的來源控制、VM 的 IP 管理、服務帳戶的建立限制，到 Cloud Storage 的公開防護和 CMEK 加密強制，每一個 constraint 背後都對應著真實的企業安全需求。建議在設計組織的雲端安全架構時，把 Organization Policy 的規劃納入最早期的階段，先把護欄架好，讓工程師在安全的邊界內自由發揮。

常見問題解答（FAQ）

Q1：Organization Policy 和 IAM 條件（IAM Conditions）有什麼差別？ IAM Conditions 是在 IAM 授權基礎上加入額外條件（如時間、資源標籤）來細化授權；Organization Policy 則是從行為層面設定哪些操作根本不被允許，不管你有什麼 IAM 角色。

Q2：我可以在 Project 層級覆蓋 Organization 層級的政策嗎？ 預設情況下可以，子層可以 Override 父層的政策。但如果父層在設定 constraint 時鎖定了不允許 Override，子層就無法覆蓋。這是組織管理員需要仔細規劃的地方。

Q3：Organization Policy 的設定會即時生效嗎？ 是的，Organization Policy 通常在幾分鐘內就會生效。但需要注意：對於已經存在的資源（例如已有公開 IP 的 VM），Policy 不會自動修正，只會阻擋未來的違規操作。

Q4：什麼是 Constraint 的 Dry Run 模式？ Dry Run（模擬執行）模式讓你先評估一個 constraint 的影響範圍，而不實際執行限制。違規操作會被記錄在 Cloud Logging 中但不會被阻止，方便管理員在正式啟用前了解有哪些資源會受到影響。

Q5：如何查看目前組織內所有的 Organization Policy 設定？ 可以在 Google Cloud Console 的「IAM & Admin → Organization Policies」中查看，也可以使用以下指令：

bash

gcloud org-policies list --organization=ORGANIZATION_ID

Q6：compute.trustedImageProjects 可以套用在 Folder 層級嗎？ 可以。Organization Policy 可以套用在 Organization、Folder 或 Project 任何層級。套用在 Folder 層級時，該 Folder 底下的所有 Project 都會受到映像來源限制的約束。

Q7：storage.publicAccessPrevention 和 Uniform Bucket-Level Access 有什麼關係？ 兩者是獨立的設定，但相輔相成。publicAccessPrevention 防止 bucket 被匿名公開存取；Uniform Bucket-Level Access 則是關閉 ACL，統一用 IAM 管理存取權限。同時啟用兩者，可以建立更完整的 Cloud Storage 安全管控。

Q8：如果同一個 constraint 在 Folder 和 Project 層級都有設定，以哪個為準？ 以最接近資源的層級為準，也就是 Project 層級的設定會覆蓋 Folder 層級的設定（前提是 inheritFromParent 沒有特別限制）。理解這個優先順序，對排查政策衝突非常重要。

Q9：Resource Location Restriction 可以限制到具體的 Zone（區域）嗎？ 可以。constraints/gcp.resourceLocations 支援以 Region、Multi-region 或具體的 Zone 為單位設定限制，能夠非常精確地控制資源的建立位置。

Q10：Organization Policy 的設定有沒有辦法自動化管理？ 有。可以透過 Terraform 的 google_org_policy_policy 資源，或使用 Google Cloud 的 Organization Policy API，以程式碼方式管理所有 constraint 設定。這也是大型企業推薦的「Policy as Code」實踐方式，確保政策設定可被版本控管和自動化部署。

The post GCP Organization Policy 完全攻略：Google Cloud 安全工程師必備知識 first appeared on 東東 GCP 教學 - GCP 實戰講師.

不需要自己架防火牆主機，也不需要密碼學背景，最快 15 分鐘就能完成基礎設定。

這篇文章會帶你從頭搞懂 Cloud Armor 是什麼、用它之前要準備什麼、怎麼操作，以及 5 種常見的防禦規則範例，看完就能直接動手。

什麼是 GCP Cloud Armor？

GCP Cloud Armor 是 Google Cloud 提供的應用程式層防護服務，部署在 Google 的全球邊緣節點上，用來攔截進入你後端服務 (虛擬機、Cloud Run 或 Kubernetes) 之前的惡意 HTTP 流量。

它的角色是守門員：在流量進入你的後端服務之前，先根據你設定的規則篩選一遍。

符合規則的流量放行，不符合的直接拒絕，回傳 403 或自訂的錯誤回應。

因為 GCP Cloud Armor 運行在 Google 的邊緣基礎設施上，惡意流量甚至不會打到你的 VM 或 Cloud Run 服務，就已經在網路邊緣被攔截。

這是它和傳統在主機上裝軟體防火牆最大的差異。

Cloud Armor 的核心功能：WAF 與 DDoS 防護

Cloud Armor 主要提供兩層防護。

WAF（Web Application Firewall，網頁應用程式防火牆）：針對應用程式層的攻擊，例如 SQL Injection、XSS、CSRF（Cross-Site Request Forgery，跨站請求偽造）、路徑遍歷（Path Traversal，進入不開放的路徑）等。

你可以用 Google 預建的規則集（Rules Set），也可以自己寫條件規則。

DDoS 防護：針對大流量的攻擊，Google 的基礎設施本身就有 L3/L4 層的 DDoS 緩解能力，Cloud Armor 在此基礎上再加上 L7 層的防護，例如針對 HTTP Flood 的速率限制（Rate Limiting）。

兩種防護都不需要你另外架設任何伺服器，全部透過設定「安全政策」和「規則」來完成。

Cloud Armor Standard 和 Managed Protection Plus 的差異

Cloud Armor 分成兩個版本，初學者只需要了解基礎版就夠用。

Standard（標準版）：

• 免費啟用，依照請求數與規則數計費
• 支援自訂規則、IP 封鎖、地理位置封鎖
• 支援 WAF 預建規則集（但要另外付費啟用每條規則）
• 適合絕大多數的 GCP 初學者和中小型專案

Managed Protection Plus（進階版）：

• 月費制，約 3,000 美元/月起，一次要訂閱一年。
• 包含自適應防護（Adaptive Protection）的完整功能
• 提供 DDoS 攻擊時的應急支援（Google 工程師介入，需搭配 Premium Support）
• 提供詳細的攻擊分析報告
• 適合有大規模 DDoS 風險的企業級應用

這篇文章的操作說明只涵蓋 Standard 版本。

Cloud Armor 和傳統防火牆的不同之處

很多人第一次接觸 GCP Cloud Armor 時會問：「GCP 不是已經有 VPC Firewall 了嗎？為什麼還需要 Cloud Armor？」

答案在於防護層次不同。

VPC Firewall 在 L3/L4 層運作，它看的是 IP 位址、Port、Protocol。

它可以說「拒絕所有來自這個 IP 的 TCP 連線」，但它看不懂 HTTP 請求的內容。

GCP Cloud Armor 在 L7 層運作，它可以看到 HTTP Header、URL 路徑、Request Body、User-Agent，甚至可以判斷「這個請求的 query string 裡面有 SQL Injection 的特徵」。

兩個服務不是互相取代，而是互補。實務上你會同時使用兩個。

你為什麼需要 Cloud Armor？

沒有 WAF 的 GCP 服務面臨哪些風險

把服務部署到 GCP 並開放公開存取之後，你面對的不只是真實用戶，還有各種自動化攻擊工具。

常見的威脅類型有 6 種：

1. 自動化掃描工具：每天有數以千計的 Bot 在網路上掃描開放的端點，試探常見漏洞
2. SQL Injection 攻擊：試圖透過 URL 參數或表單欄位注入惡意 SQL 語句，讀取或竄改資料庫
3. XSS 攻擊：在回應中插入惡意腳本，影響其他使用者的瀏覽器行為
4. DDoS 攻擊：大量請求同時打進來，讓你的服務因為過載而無法回應
5. 地區性惡意流量：某些地區的 IP 段本身就有大量惡意行為的歷史紀錄
6. 暴力破解：對登入端點反覆嘗試密碼，每分鐘可發送超過 1,000 次請求

如果沒有 WAF，這些攻擊會直接打到你的後端，讓你的 VM 或容器承受無效請求，耗費運算資源，也增加被攻破的風險。

Cloud Armor 能防禦的攻擊類型

GCP Cloud Armor 可以有效防禦的攻擊，按照常見程度排列：

1. IP 層攻擊：封鎖特定 IP 或 IP 段的所有請求
2. 地理位置攻擊：封鎖來自特定國家的流量
3. SQL Injection（SQLi）：使用 OWASP 規則集偵測並封鎖注入攻擊
4. XSS（Cross-Site Scripting）：偵測 request 中的腳本注入特徵
5. HTTP Flood：透過速率限制，對單一 IP 的請求次數設上限
6. 路徑遍歷（Path Traversal）：試圖存取 ../../../etc/passwd 等路徑
7. 掃描工具偵測：根據 User-Agent 特徵封鎖常見的掃描工具

什麼規模的專案適合導入 Cloud Armor

只要你的 GCP 服務有開放公開的 HTTP/HTTPS 端點，就應該考慮 GCP Cloud Armor。

以下 4 種情況特別建議導入：

1. 有處理用戶輸入的表單或 API（SQL Injection、XSS 風險高）
2. 服務對外有 SLA 要求，不能接受因 DDoS 導致的停機
3. 有合規需求（例如 PCI DSS），要求必須有 WAF
4. 服務已經上線，Log 中已經出現大量可疑請求

即使是個人學習專案，Standard 版本的費用相對低，拿來練習設定規則也很合理。

使用 Cloud Armor 之前：你必須知道的前提條件

GCP Cloud Armor 不是獨立服務，它必須掛在 GCP Load Balancer 上才能運作。

這是最多初學者沒注意到的限制。

Cloud Armor 只能搭配哪些 Load Balancer？

Global External HTTP(S) Load Balancer

這是最常用的搭配，也是 Cloud Armor 支援最完整的 Load Balancer 類型。

如果你的後端是 Cloud Run、GKE、Compute Engine VM，並且使用 Global External HTTP(S) LB 對外服務，Cloud Armor 的所有功能（WAF 規則、地理封鎖、速率限制）都可以使用。

套用位置是 Load Balancer 的後端服務（Backend Service），不是 LB 本身。

SSL Proxy 和 TCP Proxy Load Balancer

這兩種 LB 也支援 Cloud Armor，但只能使用 L4 層的防護功能（IP 封鎖），無法使用 WAF 規則或地理封鎖。

原因是 SSL Proxy 和 TCP Proxy 在 L4 層就把流量轉發出去了，Cloud Armor 沒有機會讀取到 HTTP 層的內容。

不支援的 LB 類型：Internal LB 和 Regional LB 的限制

以下 Load Balancer 不支援 GCP Cloud Armor：

• Internal HTTP(S) Load Balancer：只面對內部 VPC 流量，Cloud Armor 的邊緣防護機制在此無法運作
• Regional External HTTP(S) Load Balancer：Cloud Armor 目前只支援 Global 版本
• Network Load Balancer（TCP/UDP NLB）：這是 Pass-through 型 LB，流量直接到後端，無法插入 Cloud Armor

如果你現在用的是 Internal LB 或 Regional LB，要使用 Cloud Armor 就必須先換成 Global External HTTP(S) LB，這可能需要調整你的架構。

需要的 GCP 權限與 IAM 角色

設定 Cloud Armor 需要以下 IAM 角色之一：

• compute.securityAdmin：可以建立、修改、刪除安全政策
• compute.admin：包含上面的所有權限，加上管理 LB 的能力
• roles/owner 或 roles/editor：專案層級的完整權限（不建議在正式環境使用）

如果只需要查看安全政策但不需要修改，可以給：

• compute.securityPolicyUser：只能查看政策，無法修改

Cloud Armor 的計費方式

Cloud Armor Standard 版的計費方式：

實際費用計算範例：

1 個安全政策 + 5 條規則（含 2 條 WAF 規則）+ 每月 1 億次請求：

• 政策：$5
• 規則：$5（5條 × $1）
• WAF 規則：$2（2條 × $1）
• 請求數：$75（100百萬 × $0.75）
• 合計約 $87 美元/月

實際費用視流量規模而定，可以在 Google Cloud Pricing Calculator 試算。

GCP Cloud Armor 功能完整介紹

安全政策（Security Policy）是什麼？

安全政策（Security Policy）是 GCP Cloud Armor 的核心容器，用來集中管理所有防禦規則，並套用到指定的 Load Balancer 後端服務上。

一個安全政策可以包含多條規則，然後套用到一個或多個 Load Balancer 的後端服務（Backend Service）上。

把安全政策想成「一份守門規則書」：裡面寫了哪些人可以進、哪些人要擋在外面、哪些人要特別審查。

Load Balancer 把這份規則書交給門口的保全（Google 的邊緣節點）執行。

一個 GCP 專案可以有最多 200 個安全政策，每個後端服務只能套用 1 個安全政策。

規則（Rule）的組成：優先序、條件與動作

每條規則由 3 個部分組成：

1. 優先序（Priority）：數字越小，優先度越高，範圍是 0 到 2147483646。

建議用 1000、2000、3000 這樣有間距的數字，方便之後在中間插入新規則。

2. 條件（Match Condition）：用 CEL（Common Expression Language）語法描述這條規則要符合什麼條件，例如：

• 來源 IP 是否在某個範圍
• 請求的來源國家代碼是否符合
• Request 的內容是否有 SQL Injection 特徵

3. 動作（Action）：當條件成立時，要對這個請求做什麼：

• allow：放行
• deny(403)：拒絕，回傳 403 Forbidden
• deny(404)：拒絕，回傳 404（讓攻擊者不確定原因）
• throttle：速率限制，超過閾值才封鎖
• rate_based_ban：超過速率就暫時封鎖這個 IP

預設規則（Default Rule）的作用

每個安全政策都有一條無法刪除的「預設規則」，Priority 固定為 2147483647（最低優先度）。

預設規則的作用是：當所有其他規則都不符合時，這條規則決定最終結果。

預設規則的動作可以設定為：

• allow（預設值）：沒被其他規則攔截的流量（黑名單模式），全部放行
• deny(403)：沒被特別允許的流量，全部封鎖（白名單模式）

初學者建議使用 allow 作為預設動作（黑名單模式），只封鎖你明確設定要擋的流量，避免誤擋正常用戶。

進階規則語言：CEL 表達式基礎

GCP Cloud Armor 使用 CEL（Common Expression Language，通用表達式語言）來寫規則條件，這是 Google 開發的開源條件判斷語法，專門用來描述篩選邏輯。

常用的 CEL 函數：

條件可以用 &&（AND）、||（OR）、!（NOT）組合。

地理位置封鎖（Geo-blocking）

地理位置封鎖讓你根據來源國家代碼（ISO 3166-1 alpha-2）決定是否放行。

這個功能不需要你維護任何 IP 清單，Google 在邊緣節點自動判斷來源地理位置。

常見使用情境：

• 你的服務只對台灣用戶開放，可以封鎖所有非台灣的流量
• 某個國家最近有大量惡意請求，可以臨時封鎖該地區

封鎖多個國家的 CEL 語法：

origin.region_code == 'RU' || origin.region_code == 'KP' || origin.region_code == 'IR'

注意：地理位置判斷是依照 IP 對應的地理資料庫，VPN 用戶可能顯示錯誤的國家。

IP 白名單與黑名單

IP 封鎖是 GCP Cloud Armor 最基本的功能，適合封鎖已知惡意 IP 或只開放特定辦公室 IP。

每條規則最多可以指定 10 個 IP 或 CIDR 範圍。

超過 10 個 IP 需要封鎖時，有 2 個選擇：

1. 建立多條規則，每條規則放 10 個 IP
2. 使用 Cloud Armor 的「IP Address Group」功能，集中管理大量 IP 清單

黑名單模式（封鎖特定 IP）：

inIpRange(origin.ip, '198.51.100.0/24')

動作設為 deny(403)，其他規則預設 allow。

白名單模式（只開放特定 IP）：

inIpRange(origin.ip, '203.0.113.10/32')

動作設為 allow，預設規則改為 deny(403)。

WAF 預建規則集（OWASP Top 10 防護）

Cloud Armor 提供 Google 維護的 WAF 預建規則集，對應 OWASP Top 10 常見攻擊。

OWASP Top 10 是全球最廣泛引用的網頁應用程式安全風險清單，由非營利組織 OWASP 每幾年更新一次，列出最常被攻擊者利用的 10 種漏洞類型。

不需要自己寫偵測邏輯，只要在條件中呼叫 evaluatePreconfiguredExpr() 就好：

這些規則集由 Google 持續更新，不需要自己維護特徵碼。

靈敏度等級說明：每個預建規則集都有靈敏度等級（Sensitivity Level），從 1 到 4。

• 等級 4：偵測最嚴格，但誤判率也最高
• 等級 1：只抓最明顯的攻擊特徵，誤判率最低

初學者建議從 Level 1 開始，觀察 Log 後再調整。

速率限制（Rate Limiting）功能

速率限制讓你設定「同一個 IP 在一段時間內最多可以發送幾個請求」，超過就觸發節流或封鎖。

兩種模式：

Throttle（節流）：超過速率的請求會收到 429 Too Many Requests，不會被永久封鎖，速率恢復後就能正常請求。

適合防止意外的高流量，例如爬蟲設定太激進。

Rate-based Ban（速率封鎖）：超過速率之後，該 IP 在指定時間內（例如 300 秒）的所有請求都被封鎖，無論後續速率是否降低。

適合防禦故意的 HTTP Flood 攻擊。

自適應防護（Adaptive Protection）簡介

自適應防護（Adaptive Protection）是 Cloud Armor 的 AI 功能，它會分析你的流量基準，當偵測到異常流量模式時，自動生成防禦規則建議，讓你一鍵套用。

Standard 版本有基本的自適應防護功能，只能提供警告；Managed Protection Plus 版本的功能更完整，還提供即時攻擊警報和 Google 工程師介入支援，支援的前提是有購買 Premium Support 技術支援方案。

對初學者來說，自適應防護是很好的輔助工具，但不要完全依賴它——建議的規則還是需要你自己審核才能套用。

GCP Cloud Armor 基礎版操作步驟

GCP Cloud Armor 的設定流程共 5 個步驟：確認 LB 類型、建立安全政策、新增規則、套用到後端服務、測試生效。

Step 1：確認你的 Load Balancer 類型

在開始之前，先確認你的 Load Balancer 是否支援 GCP Cloud Armor。

1. 前往 Google Cloud Console → Network Services → Load Balancing
2. 點進你的 Load Balancer，查看類型欄位
3. 確認類型是 Global External HTTP(S) Load Balancer 或 Classic HTTP(S) Load Balancer

如果你還沒有 Load Balancer，需要先建立一個 Global External HTTP(S) LB，再把你的後端服務（Cloud Run、GKE、VM 等）掛上去，才能繼續後面的步驟。

Step 2：在 Google Cloud Console 建立安全政策

1. 前往 Network Security → Cloud Armor
2. 點擊「+ Create Policy」
3. 填入以下資訊：
   • Name：自訂政策名稱，例如 my-armor-policy（只能小寫英文和連字號）
   • Description（選填）：說明這個政策的用途
   • Default rule action 預設規則：選擇 Allow（黑名單模式，符合的先擋，都不符合就允許，推薦初學者）
4. 點擊「Create Policy」

這時候安全政策已經建立，但還沒有套用到任何 Load Balancer，也沒有任何自訂規則（只有預設的 allow 規則）。

Step 3：新增第一條防禦規則

在政策頁面中，點擊「Add Rule」，依序填入：

1. Description：填入規則說明，例如「封鎖惡意 IP 段」
2. Mode：選擇「Basic mode」（適合初學者）或「Advanced mode」（可以寫 CEL 表達式）
3. Match：填入條件，例如 IP 範圍 198.51.100.0/24
4. Action：選擇 Deny 並選擇回應碼（403 或 404）
5. Priority：填入優先序數字，例如 1000
6. 點擊「Add」

規則建立後會在 60 秒內生效，不需要重新部署 Load Balancer。

Step 4：將安全政策套用到後端服務

安全政策不是套用在 Load Balancer 本身，而是套用在 Load Balancer 的**後端服務（Backend Service）**上。

從 Cloud Armor 頁面套用：

1. 前往 Network Security → Cloud Armor → 點進你剛建立的政策
2. 點擊「Apply to targets」
3. 點擊「Add target」
4. 選擇你的 Load Balancer 和對應的 Backend Service
5. 點擊「Add」確認

從 Load Balancer 頁面套用（二擇一）：

1. 前往 Load Balancing → 點進你的 LB
2. 點擊「Edit」
3. 在 Backend Configuration 中，點進你的後端服務
4. 在「Cloud Armor policy」欄位選擇你剛建立的政策
5. 儲存

Step 5：測試規則是否生效

用 curl 測試封鎖效果

假設你建立了一條封鎖特定 IP 的規則，可以從該 IP 的機器用 curl 測試：

curl -v https://your-service-domain.com/

如果規則生效，你會看到：

< HTTP/2 403
< content-type: text/html; charset=UTF-8

要測試封鎖特定 User-Agent 或路徑，可以加上對應參數：

# 測試封鎖特定 User-Agent
curl -v -A "sqlmap/1.0" https://your-service-domain.com/

# 測試封鎖特定路徑
curl -v https://your-service-domain.com/admin/config

在 Cloud Logging 確認攔截紀錄

Cloud Armor 的攔截紀錄會自動寫入 Cloud Logging，查詢方式：

1. 前往 Logging → Log Explorer
2. 在查詢框填入：

resource.type="http_load_balancer"
jsonPayload.enforcedSecurityPolicy.outcome="DENY"

3. 點擊「Run Query」

你會看到每筆被攔截的請求，包含來源 IP、請求路徑、觸發的規則名稱，以及 Cloud Armor 做出的動作。

Cloud Armor 防禦規則範例

以下 5 個範例都是實務中最常用的規則設定，建議新增時使用 Advanced mode（進階模式），直接貼入 CEL 表達式。

範例一：封鎖特定 IP 位址或 IP 段

情境：你的 Log 中發現 198.51.100.42 這個 IP 持續發送惡意請求。

規則設定：

• Priority：1000
• 條件（CEL）：

inIpRange(origin.ip, '198.51.100.42/32')

• 動作：deny(403)

同時封鎖多個 IP 段：

inIpRange(origin.ip, '198.51.100.0/24') || inIpRange(origin.ip, '203.0.113.128/25')

單條規則最多支援 10 個 IP 範圍。超過 10 個時，建立多條規則，或使用「IP Address Groups」功能集中管理。

範例二：封鎖特定國家的流量（地理位置封鎖）

情境：你的服務只面向台灣用戶，想封鎖來自特定高風險國家的流量。

規則設定：

• Priority：2000
• 條件（CEL）：

origin.region_code == 'RU' || origin.region_code == 'KP'

• 動作：deny(403)

如果服務只開放特定國家，反向設定更有效率（白名單模式）：

!(origin.region_code == 'TW' || origin.region_code == 'HK' || origin.region_code == 'SG')

動作：deny(403)

這個寫法的意思是「不是台灣、香港、新加坡的流量，全部拒絕」。

國家代碼使用 ISO 3166-1 alpha-2 標準：台灣是 TW，中國是 CN，美國是 US。

範例三：防禦 SQL Injection 攻擊

情境：你的服務有開放查詢 API，擔心被 SQL Injection 攻擊。

規則設定：

• Priority：3000
• 條件（CEL）：

evaluatePreconfiguredExpr('sqli-stable')

• 動作：deny(403)

這條規則使用 Google 的預建 SQLi 規則集，自動偵測 request 中常見的 SQL Injection 特徵，包含：

• URL 參數中的 ' OR 1=1、UNION SELECT 等語句
• 編碼混淆過的注入字串
• Blind SQL Injection 常用的時間延遲語句

如果誤判率太高，可以調整靈敏度到 Level 1：

evaluatePreconfiguredExpr('sqli-stable', {'sensitivity': 1})

範例四：防禦 XSS（跨站腳本攻擊）

情境：你的服務有留言或輸入功能，想防止 XSS 攻擊。

規則設定：

• Priority：3100
• 條件（CEL）：

evaluatePreconfiguredExpr('xss-stable')

• 動作：deny(403)

這條規則偵測的 XSS 特徵包含：

• <script> 標籤的各種變形
• javascript: 協議注入
• onerror=、onload= 等事件處理器注入
• HTML 編碼和 URL 編碼混淆的腳本

想節省計費，可以把 SQLi 和 XSS 合併成 1 條規則：

evaluatePreconfiguredExpr('sqli-stable') || evaluatePreconfiguredExpr('xss-stable')

範例五：針對單一路徑設定速率限制

情境：你的 /api/login 端點常被暴力破解攻擊，想限制每個 IP 每分鐘最多 10 次請求。

規則設定：

• Priority：4000
• 條件（CEL）：

request.path.matches('/api/login')

• 動作：throttle
• 速率設定：
  • 統計週期：60 秒
  • 超過閾值：10 次請求
  • 超過後動作：deny(429)

如果想要更嚴格的封鎖，改用 rate_based_ban 動作，並設定封鎖時間（例如 300 秒）——超過次數後，該 IP 會被封鎖整整 5 分鐘。

這個範例可以應對的情境：

• 自動化密碼爆破工具（每秒幾十次請求）
• API Key 暴力猜測
• OTP 驗證碼爆破

想查詢更完整內容可查看官方文件《設定 Cloud Armor 安全性政策》。

常見問題與錯誤排查

規則設定完但沒有生效，怎麼辦？

按以下順序依序檢查，通常在第 1–3 步就能找到原因：

1. 確認安全政策有套用到後端服務：前往 Cloud Armor → 點進你的政策 → 查看「Targets」分頁，確認你的 Backend Service 在清單中
2. 確認規則的優先序正確：數字小的先執行，確認要生效的規則優先序比「預設 allow 規則」小
3. 確認條件語法沒有錯誤：CEL 語法錯誤會讓規則直接無效，在 Cloud Console 的規則編輯頁面用「Validate」功能檢查
4. 等待傳播時間：Cloud Armor 規則通常在 60 秒內生效，最多可能需要 5 分鐘才能完全傳播到所有邊緣節點
5. 確認測試來源 IP：在自己的電腦測試時，確認你的 IP 確實在規則的封鎖範圍內

安全政策套用後合法流量被擋，如何排查？

合法流量被誤擋是 WAF 最常見的問題，特別是啟用預建規則集後。

排查步驟：

1. 前往 Cloud Logging，查詢被擋的請求：

resource.type="http_load_balancer"
jsonPayload.enforcedSecurityPolicy.outcome="DENY"

2. 查看 jsonPayload.enforcedSecurityPolicy.name 欄位，確認是哪條規則觸發
3. 查看原始請求的 path、headers、body，判斷是否為正常請求
4. 如果是 WAF 預建規則集誤判，可以選擇以下 3 種方式處理：
   • 降低靈敏度等級（Sensitivity Level）
   • 在誤判的規則前面加一條優先序更高的 allow 規則，放行特定 IP 或路徑
   • 改用「Preview Mode」先觀察，不實際封鎖

Preview Mode（預覽模式）：規則動作設定為 preview，Cloud Armor 會記錄所有符合條件的請求到 Log，但不實際封鎖。

上線新規則前，建議先開 Preview Mode 觀察 1–3 天，確認沒有異常再正式封鎖。

在 Cloud Logging 中找到 Cloud Armor 攔截紀錄

Cloud Armor 的完整 Log 欄位說明：

查詢所有 GCP Cloud Armor 相關紀錄（含放行和攔截）：

resource.type="http_load_balancer"
jsonPayload.enforcedSecurityPolicy.name!=""

建議把這個查詢存成「已儲存的查詢」，方便日後快速查看。

結語：Cloud Armor 值得學嗎？

值得，而且應該在服務上線前就設定好，而不是等到被攻擊才補。

GCP Cloud Armor 的入門門檻不高，Standard 版本費用合理，3 個步驟就能讓你的服務多一層 WAF 保護：建立安全政策、加規則、套用到 Backend Service。

從最基本的 IP 封鎖和地理封鎖開始，再慢慢加入 WAF 預建規則集，觀察 Log，調整靈敏度。

不需要一次把所有功能都打開，循序漸進才不會誤擋正常流量。

如果你的服務已經有 Global External HTTP(S) Load Balancer，今天就可以花 15 分鐘把基礎的 Cloud Armor 設定好。

相關細節可以參考 Cloud Armor 說明文件。

如果想了解其他 GCP 的資安防禦功能，可以參考《雲端的資訊安全防禦縱深，常用 GCP 資安服務介紹》。

常見問題（FAQ）

Q1：Cloud Armor 可以防禦 L3/L4 層的 DDoS 攻擊嗎？

A：GCP Cloud Armor 本身專注在 L7 層（應用程式層）的防護，L3/L4 層的 DDoS 防禦由 Google 底層基礎設施自動提供，不需要額外設定。大流量的 UDP Flood 或 SYN Flood，Google 網路邊緣就會自動緩解。如果你需要 L7 層的 HTTP Flood 防護，才需要在 Cloud Armor 設定速率限制規則。

Q2：Cloud Armor 可以保護 Cloud Run 服務嗎？

A：可以，但 Cloud Run 必須先搭配 Global External HTTP(S) Load Balancer 對外服務，才能套用 GCP Cloud Armor 安全政策。設定方式是建立 Serverless NEG（Network Endpoint Group），把 Cloud Run 掛到 LB 的後端服務，再套用安全政策。直接用 Cloud Run 的 .run.app 網址，無法使用 Cloud Armor。

Q3：Cloud Armor 的規則修改後多久生效？

A：在 Google Cloud Console 儲存後，新規則或修改後的規則最快 60 秒內生效，最慢約 5 分鐘完全傳播到所有 Google 邊緣節點。如果測試時還沒看到封鎖效果，等 5 分鐘後再試，不要急著以為設定有問題。

Q4：同一個 GCP 專案可以建立幾個安全政策？

A：預設上限是每個 GCP 專案 200 個安全政策，每個政策最多 200 條規則。一般使用不太會碰到這個限制。如果有需要，可以申請提高配額。

Q5：安全政策可以套用到多個 Load Balancer 嗎？

A：一個安全政策可以套用到多個後端服務（Backend Service），這些後端服務可以屬於不同的 Load Balancer。但反過來，一個後端服務在同一時間只能套用 1 個安全政策。

Q6：使用 WAF 預建規則集會不會有很多誤判？

A：剛啟用時確實可能有誤判，特別是靈敏度較高的等級。建議先用「Preview Mode」觀察 1–3 天的 Log，確認沒有異常後再正式開啟封鎖。靈敏度從 Level 1 開始，視需要再調高。

Q7：Cloud Armor 可以封鎖特定的 User-Agent 嗎？

A：可以。用 CEL 表達式判斷 request.headers['user-agent'] 欄位，例如封鎖 sqlmap 工具：request.headers['user-agent'].matches('.*sqlmap.*')。不過攻擊者可以輕易偽造 User-Agent，這個方法只適合封鎖懶惰的攻擊工具，不能作為主要防禦手段。

Q8：Cloud Armor 有辦法只保護特定路徑，不影響其他路徑嗎？

A：可以。在規則條件中加入 request.path 的判斷，例如 request.path.matches('/api/.*') 只對 API 路徑套用規則，其他路徑不受影響。這樣可以針對敏感端點設定嚴格規則，同時不影響靜態資源的存取速度。

Q9：Cloud Armor 和 reCAPTCHA 可以結合使用嗎？

A：可以。Cloud Armor 支援整合 reCAPTCHA Enterprise，當偵測到可疑流量時，可以觸發 CAPTCHA 挑戰，而不是直接封鎖。這個功能適合面向一般用戶的服務，因為直接封鎖可能誤傷真實用戶，先給 CAPTCHA 挑戰更友善。

Q10：如果我換掉 Load Balancer，之前設定的 Cloud Armor 安全政策會消失嗎？

A：GCP Cloud Armor 安全政策本身不會消失，因為它是獨立的 GCP 資源。但套用關係會斷掉，因為原本的 Backend Service 被刪除了。換 LB 後，你需要重新把安全政策套用到新 LB 的後端服務上，政策內的規則設定全部保留，不需要重新設定。

The post GCP Cloud Armor 完整教學：功能介紹、使用條件與防禦規則設定 first appeared on 東東 GCP 教學 - GCP 實戰講師.

嚴謹的說法：技術棧就是一個系統或產品，為了完成特定目標所採用的整套技術組合——包含程式語言、框架、資料庫、伺服器、雲端服務與開發工具，這些技術彼此配合、協同運作，缺一不可。

技術棧的精準定義：不只是「工具清單」

很多人第一次聽到「技術棧」這個詞，直覺會把它想成「公司用哪些軟體」，但這樣理解其實是不夠精準的。

技術棧的重點不只是「用了哪些技術」，更在於「這些技術如何互相搭配、一起運作」。

打個比方，一間餐廳的廚房裡有刀、砧板、瓦斯爐、炒鍋，這些工具本身沒什麼了不起，但當它們被廚師按照正確順序組合起來，才能端出一道完整的菜。

技術棧就是這樣——它是一套「會互相配合的工具組合」，而不只是一張工具清單。

為什麼說技術棧是「有機整體」？

「有機整體」這個說法聽起來很抽象，讓我們用一個具體的例子來說明。

假設你要開發一個電商網站，你選擇了：

• 前端：React（讓使用者看到漂亮的購物介面）
• 後端：Node.js（處理訂單邏輯、金流計算）
• 資料庫：PostgreSQL（儲存商品資料、用戶資料）
• 部署：Docker + Google Cloud Platform（讓整個系統能穩定上線）

這四層技術並不是各自獨立的，它們環環相扣：React 送出請求給 Node.js，Node.js 查詢 PostgreSQL，最後打包成 Docker 容器部署到 GCP。你換掉任何一個環節，其他環節都可能需要跟著調整。這就是技術棧「有機整體」的意義——牽一髮而動全身。

技術棧的核心概念：彼此協同，缺一不可

更精準地說，技術棧是某項工作或職位所需掌握、並且會互相配合使用的技術集合。

這些技術被組合成一個整體，用來實現特定的商業或技術目的。

有幾個關鍵特徵值得記住：

1. 技術棧不等於單一技術：用了 React 不代表你有一套技術棧，你還需要搭配後端、資料庫等其他層次。
2. 技術棧會隨需求演進：一個新創公司的技術棧，和一家上市企業的技術棧可能截然不同。
3. 技術棧有層次結構：業界習慣把技術棧分為前端、後端、資料庫、基礎架構等幾個主要層次。

技術棧、技術堆疊、全端（Full Stack）：三者到底有什麼差別？

這三個詞是整個技術圈最容易讓人混淆的概念之一，甚至有些工程師工作好幾年了還搞不清楚。讓我們來一次說清楚。

技術棧 vs. 技術堆疊：根本是同一件事嗎？

簡單說：是的，幾乎完全相同。

「技術棧」和「技術堆疊」都是英文 Tech Stack 的中文譯名，只是翻譯方式不同。「技術棧」偏向台灣的說法，「技術堆疊」在兩岸都有人用，但實質意思沒有差異。如果你在面試或技術文件中看到這兩個詞交替出現，不需要過度解讀，它們指的是同一件事。

技術棧 vs. 全端：最常被混淆的地方在哪？

這才是真正容易出錯的地方。技術棧描述的是「技術組成」，全端描述的是「人的能力範圍」，兩者完全不是同一個維度的概念。

舉個具體例子：

• 一個 Web 專案使用 React、Node.js、PostgreSQL、Docker，這是一套技術棧。
• 一位工程師同時能做 React 前端、API 後端、資料庫設計與部署，這位工程師就是全端工程師。

全端工程師不代表他用的技術棧一定涵蓋所有層次，他可能只精通某一套技術棧；而一套技術棧也不一定需要全端工程師，它可以由多位分工明確的工程師共同維護。

H4：一張表格秒懂三者差異

一句話版本：技術棧／技術堆疊是在講「系統用了哪些技術」；全端是在講「人能處理前端與後端的整個開發流程」。前兩者是技術組合，後者是人的能力範圍。

技術棧的 4 大核心層次

業界習慣把技術棧拆成幾個主要層次來討論。理解這些層次，你才能真正看懂職缺描述、技術文件，以及架構設計圖。

前端（Frontend）：使用者看得到的那一層

前端是指所有直接呈現在使用者螢幕上的技術，負責視覺介面、互動邏輯與使用者體驗。常見的前端技術包含：

• 框架與函式庫：React、Vue.js、Angular、Svelte
• 樣式工具：CSS、Tailwind CSS、Sass
• 建置工具：Vite、Webpack、Babel

前端的核心任務是把資料「畫」成使用者能理解和操作的介面。當你點擊一個按鈕、看到一張動態圖表，背後都是前端的工作。

後端（Backend）：負責邏輯運算的幕後英雄

後端是整個技術棧的「大腦」，負責業務邏輯、資料處理、身份驗證、API 設計等核心功能。使用者永遠看不到後端，但沒有後端，整個應用就無法運作。常見的後端技術包含：

• 語言與框架：Node.js（Express）、Python（Django、FastAPI）、Ruby on Rails、Go、Java（Spring Boot）
• API 設計：RESTful API、GraphQL、gRPC
• 身份驗證：JWT、OAuth 2.0

如果前端是餐廳的外場，後端就是廚房——客人看不見廚房在做什麼，但廚房的效率直接決定了餐點品質。

資料庫（Database）：資料的家

資料庫負責儲存和管理所有應用所需的資料，從使用者帳號、商品資訊到交易記錄，全都在這裡。資料庫大致分為兩類：

關聯式資料庫（SQL），適合結構化、有明確關係的資料：

• PostgreSQL
• MySQL
• Microsoft SQL Server

非關聯式資料庫（NoSQL），適合彈性結構或大量非結構化資料：

• MongoDB（文件型）
• Redis（鍵值型，常用於快取）
• Cassandra（寬欄型，適合大規模寫入）

選擇 SQL 還是 NoSQL，取決於你的資料特性和讀寫需求，沒有絕對的對錯。

部署與基礎架構（DevOps / Infrastructure）：讓系統跑起來的關鍵

這一層負責把寫好的程式碼打包、部署到伺服器，並確保系統能穩定、持續地對外服務。這個層次的技術發展最快，也是近年來最受重視的領域之一。

常見技術包含：

• 容器化：Docker（打包應用環境）、Kubernetes（容器編排管理）
• 雲端平台：Google Cloud Platform（GCP）、AWS、Microsoft Azure
• CI/CD 工具：GitHub Actions、GitLab CI、Jenkins
• 監控與日誌：Prometheus、Grafana、Datadog

沒有這一層，你的程式碼永遠只能在自己的電腦上跑。

常見的技術棧組合有哪些？

業界有幾套被廣泛採用的經典技術棧組合，各有各的適用場景和特性。

MEAN Stack：JavaScript 全家桶

MEAN 代表 MongoDB、Express.js、Angular、Node.js，四個層次全部使用 JavaScript 生態系。

這套技術棧最大的優點是前後端使用同一種語言，工程師不需要在 Python 和 JavaScript 之間來回切換，學習曲線相對平緩。適合中小型 Web 應用、新創團隊，或是以 JavaScript 為主的技術團隊。

類似的組合還有 MERN Stack（把 Angular 換成 React），是目前業界更主流的選擇。

LAMP Stack：老牌穩定組合

LAMP 代表 Linux、Apache、MySQL、PHP，是 Web 開發領域的老前輩，已有超過 20 年的歷史。

WordPress、Facebook 早期版本都是用 LAMP 架設的。雖然在現代化架構中，LAMP 被認為相對傳統，但它依然是全球數百萬個網站的底層基礎，特別是中小型網站和 CMS 系統。如果你要接手一個有歷史的專案，很可能就會碰到 LAMP。

JAMstack：現代靜態網站首選

JAMstack 代表 JavaScript、API、Markup，是近年來靜態網站與前端開發領域的主流選擇。

JAMstack 的核心理念是：把網站的前端預先渲染成靜態檔案（HTML/CSS/JS），部署到 CDN，需要動態資料時再透過 API 呼叫後端服務。

這種架構讓網站載入速度極快、安全性高、維護成本低。Vercel、Netlify 的崛起，很大程度上就是因為 JAMstack 的普及。常見的工具組合包含 Next.js + Contentful + Vercel。

現代 SaaS 產品常用的 GCP 技術棧

以 Google Cloud Platform 為核心的技術棧，在企業級 SaaS 產品中越來越常見。一套典型的 GCP 技術棧可能包含：

• 前端：React 或 Next.js
• 後端：Python（FastAPI）或 Node.js，部署在 Cloud Run
• 資料庫：Cloud Spanner（全球分散式）或 Cloud SQL（PostgreSQL）
• 資料分析：BigQuery
• 訊息佇列：Pub/Sub
• CI/CD：Cloud Build + Artifact Registry

這套組合的優點是高度整合、可自動擴展，特別適合需要處理大量資料或高並發請求的產品。Spotify 在遷移至 GCP 之後，就採用了類似的架構來管理其龐大的音樂串流服務。

如何選擇適合你的技術棧？

這是很多工程師和技術主管都曾糾結過的問題。選錯技術棧，輕則延誤產品開發，重則日後遷移成本高到嚇人。以下是 3 個最關鍵的考量因素。

考量因素一：團隊現有的技術能力

這是最常被忽略、但其實最重要的因素。技術棧再先進，如果團隊沒有人熟悉，就是負擔而不是資產。

舉個例子，假設你的團隊有 5 位工程師，其中 4 位精通 Python，只有 1 位略懂 Go。這時候選擇 Python（FastAPI 或 Django）作為後端語言，要比選 Go 理智得多——即使 Go 在效能上有優勢。

重新學習一門語言或框架，平均需要 3 到 6 個月才能達到生產力水準。這段時間的機會成本不容忽視。

考量因素二：社群資源與生態系統成熟度

一個技術的好壞，不只看它本身的能力，還要看它的生態系統——有沒有豐富的第三方套件？遇到問題時能不能在 Stack Overflow 或 GitHub 找到答案？招募市場上有沒有足夠的人才？

以 React 為例，它的生態系統包含數以千計的 npm 套件、完善的官方文件、數百萬的開發者社群。這讓你在遇到問題時，幾乎不可能找不到解法。

相對地，一些較新或小眾的框架，雖然技術上可能很出色，但生態系統不成熟意味著你可能需要自己解決很多問題，這對小團隊來說是很大的風險。

考量因素三：產品規模與擴充需求

你的產品預計有多少使用者？每秒需要處理多少請求？這些數字直接影響技術棧的選擇。

• MVP 或早期新創：選擇開發速度快、社群資源豐富的技術棧，例如 Ruby on Rails 或 Next.js，讓你快速驗證商業模式。
• 成熟產品或企業級應用：考量水平擴充能力、服務拆分（微服務架構）、資料一致性等需求，這時候 Kubernetes、Cloud Run、Cloud Spanner 等技術就變得重要。

不要在 MVP 階段就用 Kubernetes，那是過度設計；但也不要等到 100 萬使用者的時候才開始思考擴充性，那時候遷移的代價會讓你後悔莫及。

技術棧與職缺的關係：為什麼工程師一定要搞清楚？

對工程師來說，理解技術棧不只是技術知識，更是求職和職涯規劃的核心能力。

看懂職缺描述中的技術棧要求

打開任何一份工程師職缺，你幾乎都會看到類似這樣的敘述：

「本職位需熟悉 React、Node.js、PostgreSQL，有 Docker 或 Kubernetes 使用經驗者優先。」

這就是一個完整技術棧的描述——前端（React）、後端（Node.js）、資料庫（PostgreSQL）、部署（Docker/K8s）四個層次都列了出來。

當你看到這樣的職缺，不要只看你會的部分，要整體評估這套技術棧的合理性。如果你精通其中 3 個層次，剩下 1 個只要短期學習就能上手，這份職缺很可能適合你。

值得注意的是，很多公司寫的技術棧要求是「理想條件」，而不是「硬性門檻」。如果你對其中的核心技術掌握得很好，其他的有基礎理解，主動在履歷和面試中說明你的學習計畫，往往比硬湊技能清單更有說服力。

全端工程師需要掌握整個技術棧嗎？

不一定，但理解整個技術棧的架構是必要的。

全端工程師的核心價值在於「能獨立完成一個功能的完整開發流程」，從 UI 設計、API 串接、資料庫查詢到部署上線。但這不代表每個層次都要精通——你可以在前端和後端都有紮實能力，對部署有基本掌握，這樣就足以擔任全端工程師。

真正的全端能力，是能在不同層次之間溝通和協作，理解每個層次的限制和可能性，而不是在每個層次都達到專家級別。後者幾乎是不可能的任務，也沒有必要。

技術棧的演進：從單一架構到微服務

技術棧不是靜止不動的，它會隨著產品成長和技術趨勢持續演進。理解這個演進過程，能幫助你做出更有遠見的技術決策。

傳統單體架構的技術棧長什麼樣子？

在 2010 年代以前，絕大多數 Web 應用都採用單體架構（Monolithic Architecture）——整個應用被打包成一個部署單元，前端、後端、資料庫存取邏輯全部寫在一起。

一個典型的單體架構技術棧可能是：

• 語言：Java
• 框架：Spring MVC
• 資料庫：Oracle Database
• 伺服器：Apache Tomcat
• 部署：手動部署到單一實體伺服器

這種架構的優點是開發簡單、部署直覺；缺點是當應用規模變大，每次更新都需要重新部署整個系統，任何一個模組出問題都可能影響整個應用。

微服務架構如何改變技術棧的選擇？

微服務架構（Microservices Architecture）把一個大型應用拆解成多個小型、獨立的服務，每個服務負責一個特定的業務功能，各自部署、各自擴展。

這種架構的出現，根本性地改變了技術棧的選擇邏輯：

服務可以用不同語言寫：負責影像處理的服務可以用 Python，負責即時通訊的服務可以用 Go，負責前端 API 的服務可以用 Node.js。不同服務有不同的技術棧，這完全沒問題。

容器化成為標配：Docker 讓每個服務都能在隔離的環境中運行，Kubernetes 負責協調和管理這些容器。這兩個工具幾乎成了現代微服務架構的標配。

API 閘道與服務網格：服務之間的溝通需要有人統一管理，API Gateway（如 Kong、AWS API Gateway）和 Service Mesh（如 Istio）因此變得不可或缺。

Netflix、Uber、Airbnb 都是採用微服務架構的知名案例。以 Netflix 為例，它的串流服務背後有超過 700 個獨立的微服務，每個服務有自己的技術棧、自己的部署週期、自己的擴展策略。

不過，微服務架構並不是萬能藥。它引入了分散式系統的複雜性——服務間的網路延遲、資料一致性、分散式追蹤，這些都是單體架構不需要面對的問題。對小型團隊或早期產品來說，微服務往往是過度設計，單體架構反而更務實。

業界有一句話說得很好：「先建立單體，等你真的遇到單體架構撐不住的問題，再考慮拆分成微服務。」

常見問題解答（FAQ）

Q1：技術棧跟技術架構是同一件事嗎？

不完全相同。技術棧著重於「用了哪些具體技術和工具」，技術架構則偏向描述「這些技術和系統元件之間如何組織和溝通」。技術架構圖通常會包含技術棧的資訊，但還會加上流量走向、服務邊界、資料流等更宏觀的設計決策。

Q2：一個公司可以同時有多套技術棧嗎？

可以，而且很常見。大型公司的不同產品線、不同團隊，往往會有各自獨立的技術棧。例如行銷網站可能用 JAMstack，核心業務系統用 Java + PostgreSQL，資料分析平台用 Python + BigQuery。只要各套技術棧能完成各自的目標，多套並存完全沒問題。

Q3：沒有技術背景的 PM 或創業者需要懂技術棧嗎？

需要有基本理解，但不需要深入到工程師的層次。能看懂技術棧的組成，理解每個層次的大致職責，能幫助你在討論產品技術決策時做出更有依據的判斷，也能和工程師溝通得更順暢。

Q4：前端工程師需要了解整個技術棧嗎？

理解整體技術棧會讓前端工程師更有價值。當你知道後端 API 是怎麼設計的、資料庫的查詢有哪些限制，你在設計前端資料流和 API 串接時，就能做出更合理的決策，也更容易和後端工程師協作。

Q5：技術棧選定之後，可以中途更換嗎？

可以，但成本很高，需要謹慎評估。局部更換（例如把 MySQL 換成 PostgreSQL）相對容易；全面替換（例如把整個後端從 PHP 換成 Go）則需要大量的重寫工作和測試驗證。通常建議採用漸進式遷移，而非一次性大規模替換。

Q6：開源技術和商業技術在技術棧選擇上有什麼考量？

開源技術的優點是無授權費用、社群活躍、透明度高；商業技術（如 Oracle Database、Salesforce）的優點是有官方支援、SLA 保障、通常整合企業級功能。技術棧的選擇要考慮長期的授權成本、廠商綁定風險、以及技術支援需求。

Q7：學習新技術棧，最有效的方式是什麼？

最有效的方式是實作一個完整的小型專案，而不只是讀文件或看教學影片。挑一個你感興趣的題目，從設定環境開始，把這套技術棧的每一層都實際用過一遍。遇到問題時查文件和 Stack Overflow，這樣學到的東西會比純粹看教材扎實很多。

Q8：雲端原生（Cloud Native）技術棧是什麼意思？

雲端原生技術棧是指專為在雲端環境中運行而設計的技術組合，核心特徵包含：容器化（Docker）、容器編排（Kubernetes）、微服務架構、宣告式 API，以及持續交付流程。這類技術棧設計上就考慮了彈性擴展、高可用性和自動恢復能力。

Q9：技術棧的選擇會影響資安嗎？

會有直接影響。不同的技術棧有不同的安全特性和已知漏洞。例如，某個版本的框架可能有已知的 SQL Injection 風險，某個資料庫的預設配置可能存在安全漏洞。選擇有活躍安全更新的技術、定期更新版本、遵循各技術的安全最佳實踐，是維持技術棧安全性的基本要求。

Q10：Serverless 架構算是一種技術棧嗎？

Serverless 是一種部署與執行模型，而不是完整的技術棧。你仍然需要選擇前端框架、程式語言、資料庫，只是把執行邏輯的部分交給雲端平台（如 AWS Lambda、Google Cloud Functions）管理，不需要自己維護伺服器。所以 Serverless 可以是技術棧中「部署與基礎架構」這個層次的選擇之一。

結論：技術棧是技術組合，全端是人的能力，兩者別再搞混了。 選擇技術棧時，先看團隊能力、再看產品規模、最後看生態系統成熟度，按這個順序想清楚，大多數情況下都能做出合理的決策。

The post 技術棧是什麼？一文搞懂 Tech Stack 的定義、組成與實際應用 first appeared on 東東 GCP 教學 - GCP 實戰講師.

• On-Demand：每掃描 1 TB 收費約 $7.19 美元，不查詢不收費
• Editions：2023 年新架構，分 Standard、Enterprise、Enterprise Plus，支援自動擴縮
• Flat-rate 已經沒有再提供，請以 Editions 為主。

官方說明參考這份文件，以下逐一拆解。

1. BigQuery 計費的核心單位：Slot 是什麼？

Slot 是 BigQuery 的虛擬 CPU 單位，代表查詢執行時可用的運算能力。BigQuery 執行查詢時，會自動把工作分散到多個 Slot 並行處理，Slot 越多查詢越快。

Slot 中文叫運算單元，在大陸叫”槽”。

根據 Google 以前的公開文件 1 槽 (Slot) = 0.5個 vCPU和 0.5GB 的記憶體。

但後來可能由於硬體效能提升，後來隱藏了這個數據。

Slot 不夠用時會發生什麼事？

On-Demand 模式下，BigQuery 提供每個專案共享的 Slot 資源池。當同一專案內有多個大型查詢同時執行時，會出現排隊（Queuing）的情況，導致執行時間延長。

Flat Rate 或 Editions 模式下，你買多少 Slot 就用多少，不會自動借用額外資源。

2. 隨需計費（On-Demand Pricing）深度解析

查詢費用的計算方式

• 計費單位：每掃描 1 TB 收費約 $7.19 美元（台灣區域 asia-east1）
• 最小計費單位：10 MB，就算你的查詢只掃描 1 MB的資料，系統仍以 10 MB 計算
• 計費基礎：查詢實際讀取的欄位資料量，不是整張表的大小
• 要注意，如果你的表格有 100,000 資料，即使你查詢使用 Whare 或 Limit 語法，只撈出 10 筆資料，它還是讀取 100,000 筆資料，除非你有做分區表（後面詳述） 。
• 每個月前面 1 TB 屬於免費額度，超過 1 TB 的資料量才開始計費。
• 可參考 GCP 價格計算機的數據：

使用 Dry Run 預估費用

執行查詢前，可用 Dry Run 模式預估掃描量，完全不收費。

操作方式：

在 BigQuery 主控台，點選「More → Query settings → Dry Run」；或在 CLI 使用 --dry_run 參數，系統會直接告訴你這次查詢預計掃描多少 Bytes。

另外，BigQuery 主控台的 SQL 編輯器右上角，每次寫完查詢都會顯示「This query will process X GB」。執行前先看這個數字，是控制費用的第一道關卡。

3. BigQuery Editions：新版計費方案全解析

以前 BigQuery 提供 Flat Rate，有別於 On-Demand 像計程車跳錶，每掃描一點資料收一點錢；

Flat Rate 像月租車，費用固定，查詢不另外計費。

2023 年，Google 推出 Editions 架構，重新定義 BigQuery 的計費方式。

Standard、Enterprise 與 Enterprise Plus 比較

Editions 和舊版 Flat Rate 最大的差異

舊版 Flat Rate：Slot 數量固定，資源無法自動調整。

如果你買了 100 個 Slots (運算單元)，那這 100 個單位就是專屬於你的，即便你的工程師下班了、資料庫閒置在那裡，你還是要付這 100 個單位的完整費用。

Editions：引入 Autoscaler，查詢量高峰時自動增加 Slot，閒置時自動縮減，不再需要猜測最高需求來決定購買數量。

正因為計費邏輯從「買斷固定數量」變成了「按實際彈性用量付費」，所以你在設定 Reservations (預留項目) 時，會發現 Google 不再給你一個「固定 100 Slots 的總價」。

系統現在只會讓你設定一個 Max Reservoir Size (預留項目大小上限)，這就像是幫你的信用卡設一個「單筆消費限額」，防止自動擴充得太過火導致帳單爆炸。

既然實際支出是根據每分每秒的波動累積起來的，那份試算表列出的 25%、50%、75% Utilization (使用率)，其實是在幫你估計：如果你的業務平均負載在這些水位，你月底大概會收到多少錢的帳單。

之所以沒有列出 100% 的費用，是因為在 Autoscaling (自動擴充) 的機制下，除非你的查詢量大到 24 小時都把這 100 個 Slots 佔滿，否則你幾乎不會付到 100% 的錢。

這也是為什麼你看到 Baseline (基準運算單元) 的選項會被設為 0 或較低的數值；Baseline 代表「無論如何我都要保有的最低戰力」，如果你的 Baseline 設得越低，系統在沒事做的時候就能縮得越小，省下更多費用。

你可能會問， On-Demand 的都直接去使用 Enterprise (企業版) 的 自動擴充 (Autoscaling) 功能就好了，反正沒有用就沒費用，有用還比較便宜，對嗎？

BigQuery 隱藏的「計費邏輯」

BigQuery Edition 並不一定比原本的 On-demand (按需求計費) 便宜，因為計費單位的根本不同：

在 On-demand (按需求計費) 的模式下，Google 是看你的 SQL 指令「掃描了多少資料量」來收錢。

BigQuery Edition ，計費的標竿就完全改變了，系統改為計算你「使用了多少運算力（Slots）以及用了多久（時間）」。就像搬家「按出動的人力和時間算錢」一樣。

哪一種比較划算，完全取決於你的行李（資料）長什麼樣子

首先要考慮你原本 On-Deman 的每月費用是否超過 2,000 美元，這種用量在台灣通常是大企業才要考慮。

如果你的查詢語法寫得不夠有效率，導致系統需要動用大量 Slots 埋頭苦幹很久，那麼在 Enterprise (企業版) 下產生的費用，反而有可能會超過原本的 On-demand (按需求計費)。

如果你的工作負載（Workload）是屬於那種「掃描資料量極大，但運算過程很簡單」的類型，Enterprise (企業版) 可能會顯得非常划算；反之，如果你的資料量很小，但 SQL 邏輯複雜到讓系統算到滿頭大汗，那 On-demand (按需求計費) 反而可能是你的省錢好朋友。

Commitment 承諾方案的折扣

既然叫做「承諾」，就是不管你有沒有用 Slots，你每個月都要支付固定的費用。

這是和上述 BigQuery Editions 最大的不同。

資源型承諾 (Resourced-Based CUD)：折扣最深但相對固定

從上方表格最右側兩欄看到，你會發現 Resource CUDs 的價格較低，因為你給 Google 的承諾非常死，讓他們能非常精確地預估硬體採購和機房調度，所以他們給出的折扣也最慷慨，3 年期的價格甚至能讓你省下將近 40% 的費用。

然而，高折扣的代價就是「專款專用」。當你簽下 Resource CUDs 時，通常需要鎖定特定的 Slots (運算單元) 數量以及特定的 Region (區域)。

這對於已經進入穩定營運期、且每天運算量都像心電圖一樣平穩的老牌公司來說是首選，因為他們很清楚自己每小時就是要燒掉這麼多 Slots，直接選這個方案最省錢。

支出型承諾 (Spent Based)：靈活但折扣較淺

表格左側數過來第二、三欄就是支出型承諾，2026 年才正式上線，例如「我保證接下來一年，每小時一定會在這裡消費 100 元」。

不論你的 Slots (運算單元) 是在台灣還是在日本執行，或者你今天用的是 Enterprise (企業版) 還是 Enterprise Plus (企業加強版)，這份承諾都能幫你折抵支出。因為它給了你極大的轉身空間，所以 Google 給你的折扣就相對比較小，大約是在 10% 到 20% 之間。

這種適合那些業務還在變動、或者數據分散在多個 Regions (區域) 的團隊。

如果你今天還在測試哪一種 BigQuery Edition (版本) 最適合你，或者你擔心未來半年公司會把機房從台灣搬到其他國家，那麼鎖定這種以「美金金額」為單位的 BigQuery CUD，就能確保你的折扣不會因為換了環境就失效。

它就像一張通用的禮券，雖然面額折扣沒那麼多，但走到哪都能用，這就是它存在的最大價值。

4. 儲存費用（Storage Costs）完整說明

Active Storage vs. Long-term Storage

Long-term Storage 的降級是自動發生的，不需要手動操作。

降低儲存成本的策略

• 超過一年的歷史資料匯出到 Google Cloud Storage（GCS），費率比 BigQuery 低
• 使用 Table Expiration 功能，設定資料過期自動刪除
• 對大型表格採用分區設計，只保留必要分區在 BigQuery，其餘歸檔

5. 免費額度（Free Tier）

每個月的免費額度：

• 查詢：前 1 TB 掃描量免費
• 儲存：前 10 GB 免費
• 資料匯入：Batch Load 完全免費（這點常被忽略）

PS. 這個免費額度是完全不用註冊 300 美金試用的情況下，也可以直接使用的，可參考 BigQuery 免費沙箱。

6. 其他潛在費用

資料串流（Streaming Insert）費用

使用 Streaming Insert 把即時資料寫入 BigQuery，按寫入資料量額外計費。

原本只有 Steaming Inserts 這個方法，後來又提供 BigQuery Storage Write API，更為划算。

如果不需要即時性，改用 Batch Load 可完全省掉這筆費用。

BigQuery ML 計費

你會看到 BigQuery ML 兩類 Model 價差極大，為什麼？

• 線性回歸、邏輯回歸、K-means、PCA、時間序列等內建疊代模型：$312.50/TiB（台灣約 $359，依匯率與區域調整）。
• AutoML Tables、DNN、boosted tree、隨機森林等外部模型：僅 $6.25/TiB（台灣約 $7），因前處理用標準查詢費率，訓練轉 Vertex AI 但折算低。

差異原因

內建疊代模型需多次掃描資料（預設 50 次迭代），計算密集，故單 TiB 處理位元組計費高（有效乘以迭代次數）。

外部模型多依賴 Vertex AI，因為這類模型被稱為 External Models（外部模型）或 Vertex AI 整合模型。

這報價其實只是一個「過路費」或是「代工準備費」。

BigQuery 只負責把數據整理好（這個過程稱為 Preprocessing 預處理），一旦數據準備好了，它就會把這些資料打包，送到隔壁棟專門做 AI 的工廠——Vertex AI 去進行真正的訓練。

而 Vertex AI 的計費方式通常不是看資料量（TB），而是看它動用了多少台強大的機器、工作了幾個小時（這個單位叫做 Node-hour 節點小時），這才是真正昂貴的地方。

BigQuery BI Engine 費用

按 GB 小時計費，約 $0.0478 美元/GB/小時。BI 儀表板查詢頻繁時，這筆費用會快速累積。

7. 5 個實用的省錢技巧

7.1 避免 SELECT * 全表掃描

BigQuery 按掃描的欄位資料量計費。SELECT * 會讀取所有欄位，即使你只用其中幾個，費用照算。

一張有 100 個欄位的表格，只選取需要的 5 個欄位，查詢費用可降到原本的 5% 左右。

7.2 善用分區 (分割)（Partitioning）與叢集（Clustering）

分區：把大型表格按時間或其他欄位切分。查詢加上分區欄位的篩選條件，BigQuery 只掃描對應分區。

叢集：在分區之內，進一步按特定欄位排序資料。

搭配使用分區和叢集，查詢費用可降低 50% 以上。

7.3 設定查詢上限與預算警示

在 BigQuery 設定每個用戶或每個專案的每日查詢費用上限（Cost Controls），超過門檻查詢會被自動拒絕。

搭配 Google Cloud Billing 的 Budget Alerts，費用達到設定百分比時自動發送通知。

7.4 善用 Materialized Views

有複雜查詢需要反覆執行（例如每天計算一次彙總報表），改用 Materialized Views（實體化視圖）。BigQuery 預先計算並儲存結果，後續查詢直接讀取，省去重複掃描的費用。底層資料更新時，Materialized Views 也會自動更新。

7.5 定期評估是否切換 Editions

月費持續增長，超過 2,000 美元時，用 BigQuery Slot Recommender 分析歷史查詢記錄，評估購買固定 Slot 是否更划算。

8. 如何監控與管理費用

用 Google Cloud Console 查看帳單

Billing 頁面可按專案、服務、時間段篩選費用，找出費用來源。

設定預算與費用警示

在 Cloud Billing 的「Budgets & alerts」設定預算上限，達到 50%、90%、100% 時自動發送通知。這是避免帳單超出預期的基本防線，每個 BigQuery 使用者都應該設定。

常見問題（FAQ）

Q1. Slot 買了沒用完，會退費嗎？

BigQuery Editions 的承諾費用固定收費，不論實際使用多少 Slot，費用照算。

Q2. SELECT * 真的會讓費用變很高嗎？

是的。BigQuery 依照掃描的欄位資料量計費，SELECT * 讀取所有欄位，就算只用少數欄位費用不變。改成只選必要欄位，有機會省下 80% 以上的查詢費用。

Q3. 如何查看每個查詢花了多少錢？

透過 INFORMATION_SCHEMA.JOBS_BY_PROJECT 查詢歷史記錄，欄位 total_bytes_billed 乘以當前費率即可估算費用。也可搭配 Cloud Billing Export，把費用明細匯出到 BigQuery 做深入分析。

Q4. BigQuery 資料匯入需要付費嗎？

Batch Load（批次匯入）免費。Streaming Insert（串流寫入）按寫入資料量額外收費。

Q5. 如何預防帳單突然暴增？

三管齊下：設定每個用戶的查詢費用上限（Cost Controls）、在 Cloud Billing 設定 Budget Alerts、定期審視使用量報告。

The post BigQuery 計費方式完整介紹：費用結構、自動擴充與省錢技巧全攻略 first appeared on 東東 GCP 教學 - GCP 實戰講師.

一、為什麼 Spotify 要把機房搬到 GCP？

1.1 自建機房的核心痛點：容量規劃跟不上成長速度

Spotify 用戶從幾百萬成長到幾億，自建機房出現兩個致命問題：

問題一：容量規劃太慢。 流量爆增時，得先訂機器、等到貨、安裝、設定，流程少則幾週、多則幾個月。 網路流量不等人。

問題二：工程師時間全被吃掉。 機器壞了要換、系統有漏洞要自己修、軟體版本要自己升級。 做一百次，產品也沒有變更好，只是維持現狀。

2016 年，Spotify 決定把基礎設施維護工作交給 Google，讓自己的工程師去開發新功能。

1.2 遷移的核心挑戰：系統不能停

每一秒都有幾千萬用戶在聽歌。 停機哪怕五分鐘，就是幾千萬人同時看到錯誤畫面。

這個前提，決定了後面所有技術決策的方向。

二、GCP 雲端遷移策略：Lift and Shift vs. Rewrite

2.1 Lift and Shift（直接搬）：核心播放功能

原封不動搬過去，不改任何程式碼、不動任何架構。

適用場景： 一停就出事的核心服務。 任何改動都是風險，先求搬過去，不求完美。

2.2 Rewrite（趁機重寫）：資料分析系統

搬家的同時，把 Hadoop 整個換掉，改用 BigQuery 和 Dataflow。

適用場景： 出問題代價相對可控的內部系統。 反正都要搬了，順手把舊包袱一起處理掉。

2.3 判斷標準只有一個

這個服務如果在遷移中出問題，代價是什麼？

代價極高 → Lift and Shift，把風險降到最低。 代價可以接受 → Rewrite，一步到位。

完整搬遷可參考此文章：《地端主機如何搬上GCP？各種方法和步驟詳解》

三、GKE 容器管理：從自研 Helios 到 Google 全代管

3.1 什麼是 Control Plane？

Spotify 的產品不是一個大程式，而是幾百個小程式組成的。

誰決定哪個程式跑在哪台機器上？ 誰決定流量爆增時要多開幾個副本？ 誰決定這台機器掛了，要把程式搬去哪？

這個負責做決策的角色，就是 Control Plane。

3.2 Helios 的問題：Toil

Spotify 原本有自研的 Control Plane，叫做 Helios。 功能沒問題，但維護非常累。

每次 Linux 有安全漏洞，Spotify 要自己分析、自己開發修補、自己測試、自己部署。 每次版本升級，要自己測所有相容性。 出了問題，要自己找原因、自己修。

這種「重複做、做了系統也沒有變更好」的維運工作，叫做 Toil。 Toil 是工程師效率最大的殺手。

3.3 換用 GKE：CPU 使用率從 10% 提升到 20-25%

Google 接管 Control Plane 後，安全更新、版本升級全部自動處理。

但 GKE 帶來的不只是省力，還有意外的效能提升：CPU 使用率從約 10% 提升到 20-25%。

這來自 Bin Packing（裝箱最佳化）。

以前每個服務獨佔一台機器，大部分時間閒置。 GKE 把多個服務智慧塞進同一台機器，讓每台機器都跑得飽。 同樣的工作量，需要的機器更少，費用自然降了。

3.4 GKE 計費方式：選錯差很多

資源型計費： 按程式實際佔用多少資源收費。適合一般 Web 服務。

節點型計費： 按你開了幾台機器收費。適合需要指定特定硬體（例如 GPU）的情況。

Spotify 需要用 GPU 跑 AI 推理，選的是節點型計費。 使用情境不同，兩種計費方式的費用差距可能非常顯著。導入前一定要先評估清楚。

四、三層資料儲存架構：不同資料用不同工具

4.1 Cloud Spanner：播放清單與帳號的全球一致性

負責的資料： 播放清單、帳號資料。

核心需求：全球一致性。

你在台北更新播放清單，加了一首歌。 你在紐約的朋友馬上開 Spotify，看到的應該是最新版本。

這個特性叫做 External Consistency（外部一致性）。 Spanner 是少數能提供這個保證的資料庫。

背後技術：TrueTime

Spanner 在全球所有資料中心安裝原子鐘，確保所有機器的時間誤差不超過 7 毫秒。 靠這個保證，才能準確判斷全球資料的先後順序。

代價： Spanner 的回應速度比一般資料庫慢 4 到 10 倍。 資料不需要全球即時同步的話，用 Spanner 只是白花錢。

4.2 Cloud Bigtable：播放紀錄與 Wrapped 年度回顧

負責的資料： 播放紀錄、歌曲播放次數。

核心需求： Append-heavy（大量新增）的場景。

用戶每播一首歌，就新增一筆紀錄。 幾乎不需要修改或刪除舊紀錄。

這些播放紀錄累積起來，就是每年 Spotify Wrapped 的原料。

設計細節：Key 要先 Hash

直接用用戶 ID 當 Key 會出問題。 熱門用戶的資料會集中在少數幾台機器，那幾台機器撐不住，效能就下降。

Spotify 的解法：先把用戶 ID 打亂（Hash）再當 Key，讓資料均勻分散。

這個細節官方文件裡有寫，很多人跳過，等到系統出問題才回頭翻，改架構的代價很高。

4.3 Cloud Storage + CDN：音訊檔案全球傳輸

負責的資料： 音訊檔案、封面圖片。

音訊檔案不是直接從 Cloud Storage 傳給用戶，中間還有一層 Cloud CDN。

CDN 把熱門歌曲的音訊檔案預先放到離用戶最近的節點。 台北的用戶聽歌，資料從台灣本地節點傳來，不用繞到美國，延遲短、速度快。

沒有 CDN 這層，全球幾億用戶的請求全打到同一個地方，跨洲頻寬費用就會讓帳單失控。

五、BigQuery：資料查詢從幾小時縮為幾分鐘

5.1 從 Hadoop 到 BigQuery

Hadoop 有兩個明顯缺點：

速度慢： 複雜查詢需要幾小時，有時幾天。

維運人力高： 需要專職工程師每天照顧，調整機器、處理卡住的任務、管理版本升級。

換成 BigQuery 之後：

查詢速度： 同複雜度的查詢，從幾小時縮短到幾分鐘。 維運人力： BigQuery 是全代管服務，基礎設施的維護、擴容、備份、升級，Google 全部處理。

5.2 BigQuery 定價：按量計費 vs. 固定容量

按量計費（預設）： 每 TB 約 6.25 美元。適合資料量小的公司。

固定容量計費： 預先購買運算容量，費用可預測。適合資料量大、使用量穩定的公司。

Spotify 這種規模早就改成固定容量計費了。

如果你的 BigQuery 帳單一直在漲，研究一下固定容量選項。 有時候一個計費方式的調整，就能讓帳單砍半。

了解更多 BigQuery 可參考：《BigQuery 是什麼？功能、組成元件、特色和優勢完整介紹》

六、Pub/Sub + Dataflow：事件驅動架構的兩個設計眉角

6.1 At-least-once Delivery：同一則訊息可能送兩次

用戶播一首歌，會觸發一連串反應： 計費系統扣版稅、推薦系統更新喜好模型、播放紀錄系統記錄這次播放。

負責傳遞這些通知的是 Pub/Sub。

Pub/Sub 的特性：At-least-once Delivery（至少送達一次）。

它保證訊息一定送到，但在網路不穩定、接收方沒及時確認的情況下，同一則訊息可能送兩次甚至更多次。

了解 Pub/Sub 更多可參考《Cloud Pub/Sub 教學：比 RabbitMQ 好用，無限擴充的訊息佇列服務》

6.2 冪等性（Idempotency）：計費系統的必要設計

訊息可能重複，計費系統就必須有 冪等性。

「用戶播放 A 歌曲」的通知，就算送來三次，系統只能扣一次版稅、記錄一次播放。

實作方式有兩種：

一、每個事件附加唯一 ID（Event ID），收到訊息前先確認這個 ID 有沒有處理過。 二、把操作設計成「就算重複執行，結果也不變」的形式。

任何依賴事件驅動架構的系統，冪等性不是選配，是必須的。

6.3 Dataflow：推薦演算法的資料來源

Dataflow 把即時的播放記錄和用戶歷史行為合併，做計算和轉換，把結果餵給推薦演算法。

Dataflow 處理的是 串流資料（Streaming Data），也就是即時、持續湧入的資料流。 這讓推薦系統能快速響應用戶的行為，你剛聽完一首歌，推薦結果很快就會反映。

七、VPC 網路架構：一個初期沒注意的限制，代價極高

7.1 VPC Peering 不支援 Transitive Routing

Spotify 的每個工程團隊有獨立的 GCP 專案，用 VPC Peering 讓不同團隊的服務互相通訊。

VPC Peering 有一個關鍵限制：不支援 Transitive Routing（轉傳路由）。

A 網路和 B 網路打通了、B 網路和 C 網路打通了。 但 A 網路的服務，不能透過 B 網路去存取 C 網路。 A 和 C 之間必須再建立一個獨立的 VPC Peering 連線。

服務只有幾個時，影響不大。 服務成長到幾百個、幾千個，需要互相連線的組合數量就會爆炸性增長，管理幾千條 Peering 連線本身就是巨大的維運負擔。

網路架構設計要在初期就考慮擴展性。 等問題出現再來改，代價是初期就設計好的幾十倍。

7.2 Workload Identity：容器的存取權限管理

GKE 的 Workload Identity 讓容器安全存取 GCP 上的其他服務。

每個容器啟動時，GCP 自動發給它一組識別憑證，記錄這個容器有哪些存取權限。

相比傳統做法（把密碼寫在設定檔裡）的優勢： 設定檔傳錯地方、被包進映像檔推上公開倉庫，都可能造成嚴重的安全事故。 Workload Identity 的憑證不存在任何地方，大幅降低外洩風險。

速查表：這篇文章的判斷框架

常見問題 FAQ

Q1：Spotify 的雲端遷移總共花了多少時間？ Spotify 從 2016 年開始將服務逐步遷移到 GCP，到 2023 年時已幾乎完成整個遷移過程，前後歷時約七年。這麼長的時間，主要是因為遷移過程中服務不能中斷，必須以滾動式、漸進式的方式進行。

Q2：什麼是 Lift and Shift？適合哪種情境？ Lift and Shift 是一種雲端遷移策略，指的是將服務原封不動地搬到雲端，不修改任何程式碼或架構。這種方式最適合「停機代價非常高」的核心服務——因為任何改動都是風險，直接搬過去能把遷移風險降到最低。代價是舊有的技術債也會一起帶過去。

Q3：GKE 是什麼？和自己管理 Kubernetes 有什麼差別？ GKE（Google Kubernetes Engine）是 Google 提供的全代管 Kubernetes 服務。和自己管理 Kubernetes 最大的差別在於：安全更新、版本升級、Control Plane 的維護，全部由 Google 負責，使用者只需要專注在自己的應用程式上。這能大幅減少工程師花在維運上的 Toil 時間。

Q4：Cloud Spanner 的外部一致性（External Consistency）和一般資料庫有什麼不同？ 一般的分散式資料庫通常提供的是「最終一致性」（Eventual Consistency）——也就是資料更新後，不同節點的資料可能有短暫的不一致，但最終會同步。Spanner 的外部一致性提供更強的保證：一筆資料寫入之後，全球任何地方的讀取都能立刻看到最新的版本，就像銀行帳戶的操作一樣。

Q5：Bigtable 的 Key 設計為什麼重要？ Bigtable 會把相近的 Key 存放在同幾台機器上。如果直接用連續性的 ID 當 Key（例如遞增的用戶 ID），熱門用戶的資料就會集中在少數機器上，造成「熱點」問題，讓那幾台機器過載、整體效能下降。先對 Key 做 Hash 處理，可以讓資料均勻分散到所有機器，避免熱點。

Q6：什麼是 Toil？工程師為什麼要減少它？ Toil 指的是重複性的、手動的、對系統沒有長期改善效果的維運工作。例如每天手動重啟某個服務、手動處理積壓的任務、手動更新設定檔等。Toil 不只讓工程師感到無聊和挫折，更重要的是它直接佔用了工程師的時間，讓他們沒有精力去做真正有創造力、有長遠價值的工作。

Q7：Pub/Sub 的 At-least-once Delivery 為什麼不設計成 Exactly-once（剛好一次）？ Exactly-once 的保證在分散式系統中實作成本非常高，因為要確保訊息剛好送達一次，需要複雜的協調機制，而這些機制本身也有失敗的可能性。業界的普遍做法是選擇 At-least-once（保證至少送達），然後在應用層實作冪等性來處理重複訊息，這樣能在可靠性和效能之間取得比較好的平衡。

Q8：CDN（內容遞送網路）對音樂串流服務有多重要？ CDN 對 Spotify 這類全球性的串流服務幾乎是不可或缺的。沒有 CDN，台灣用戶播放一首歌的請求可能要繞到美國的伺服器，光是網路延遲就可能讓音樂無法即時播放。CDN 把熱門內容預先放到離用戶最近的節點，不只改善了使用體驗，也大幅降低了跨洲際的頻寬費用。

Q9：VPC Peering 的 Transitive Routing 限制有沒有替代方案？ 有。Google Cloud 提供了 Cloud VPN 和 Cloud Interconnect 作為替代或補充方案，也有 Shared VPC 的架構可以讓多個專案共用同一個網路，減少需要建立 VPC Peering 的數量。另外，使用服務網格（Service Mesh）如 Anthos Service Mesh，也可以在不依賴 VPC Peering 的情況下管理服務間的通訊。

Q10：Spotify 的雲端遷移經驗適用於中小型公司嗎？ 核心原則是適用的，但規模不同，決策的優先序也不同。對中小型公司來說，最重要的啟發可能是：善用雲端的全代管服務（Managed Services）來減少維運負擔，把有限的工程師資源集中在核心產品上；以及在技術選型初期就把擴展性和成本控制考慮進去，避免後期需要痛苦的架構大改。

原始案例參考：https://cloud.google.com/customers/spotify

The post Spotify 成功案例 – 如何將服務搬上 GCP？7 大關鍵技術決策完整解析 first appeared on 東東 GCP 教學 - GCP 實戰講師.

1. 進入 GCP Console → VPC 網路 → 防火牆
2. 點擊「建立防火牆規則」
3. 填寫名稱、選擇方向（Ingress/Egress）、設定動作（Allow/Deny）
4. 指定目標（標籤或服務帳號）、來源 IP 範圍
5. 指定通訊協定與連接埠（如 tcp:80,443），儲存

用 gcloud 一行指令的話：

gcloud compute firewall-rules create default-allow-http-https \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web-server

上面是最快的版本。

如果你是第一次設定、不確定每個欄位是什麼意思、或是設完還是連不上，往下看——下面會逐一拆解每個元件的意思，以及常見踩雷的地方。

一、什麼是 GCP 防火牆規則？

1.1 GCP 防火牆的基本概念

簡單來說，GCP 防火牆規則就像是你家大門的保全系統。你可以決定哪些人能進門、哪些人不行；哪些流量可以進來、哪些要擋在門外。

在 Google Cloud 的架構裡，防火牆規則是定義在 VPC（Virtual Private Cloud）網路層級的規則。這些規則可以控制進出你的 VM（虛擬機器）或其他 GCP 資源的網路流量。

每一條防火牆規則會指定：

1. 哪個 VPC 網路適用這條規則
2. 流量的方向（進來還是出去）
3. 要允許還是拒絕這個流量
4. 套用這條規則的目標（哪些 VM）
5. 流量的來源或目的地
6. 通訊協定（TCP、UDP、ICMP 等）和連接埠

你可以把它想像成一個超精密的過濾器，讓你對流量做非常細緻的控制。

1.2 GCP 防火牆與傳統防火牆有什麼不同？

很多人剛接觸 GCP 的時候，會用「傳統防火牆機器」的思維來理解它，結果常常卡住。讓我們來說說幾個關鍵差異。

傳統防火牆通常是部署在網路邊界的實體或虛擬設備，所有進出的流量都要「過」這個點。而 GCP 的防火牆規則是分散式的，它運作在 Google 的全球基礎架構上，不存在單一的防火牆設備。這代表規則的套用是直接在 VM 層級發生的，不是在網路邊界。

另一個重要差異是：GCP 防火牆規則是有狀態（Stateful）的。這表示如果你允許一個連線進來，回應這個連線的封包就會自動被允許出去，你不需要另外設一條 Egress 規則來放行回應流量。對大多數應用場景來說，這大幅簡化了規則的設計。

1.3 GCP 防火牆規則在 VPC 網路中的角色

在 GCP 的 VPC 架構中，防火牆規則扮演著核心的安全角色。每個 VPC 網路都可以有自己的防火牆規則，而這些規則會套用在這個 VPC 內的所有資源上。

值得注意的是，GCP 的防火牆規則是全域資源，不是區域性的。這意味著你在台灣建立一個規則，它可以同時保護你在美國、歐洲的 VM，非常方便。

二、GCP 防火牆規則的核心元件解析

要設定好防火牆規則，你必須先搞懂每個元件的意思。這就像在說一個語言，你要先認識它的語法，才能說出有意義的句子。

2.1 優先順序（Priority）是什麼？如何影響規則？

優先順序是一個介於 0 到 65535 之間的整數，數字越小，優先順序越高。當多條規則同時符合同一個流量時，優先順序最高（數字最小）的規則會被套用，其他規則會被忽略。

舉個例子：

• 規則 A：優先順序 1000，允許來自任何來源的 TCP 80 流量
• 規則 B：優先順序 500，拒絕來自 192.168.1.0/24 的所有流量

如果有一個來自 192.168.1.5 的 TCP 80 請求進來，會套用哪條規則？答案是規則 B，因為它的優先順序（500）比規則 A（1000）更高（數字更小）。

如果你沒有指定優先順序，GCP 預設會使用 1000。

2.2 方向（Direction）：Ingress vs. Egress

防火牆規則的方向決定了它管的是哪種流量：

Ingress（入站）

從外部進入你的 VM 的流量，或是在 VPC 內部，別台 VM 進入你 VM 的流量。例如，使用者瀏覽你網站的請求，就是 Ingress。

Egress（出站）

從你的 VM 送往外部的流量。例如，你的 VM 去抓第三方 API 的資料，就是 Egress。

大多數情況下，我們主要管 Ingress，但在某些高安全性場景下，Egress 的管控同樣重要，而我們很容易忽略這種方向的設定。

通常機器中毒或被駭客入侵，有可能只防別人來存取，卻沒有擋自己去入侵別人。

2.3 動作（Action）：Allow vs. Deny

這個很直觀：

• Allow（允許）：讓符合規則條件的流量通過
• Deny（拒絕）：阻擋符合規則條件的流量，且不傳送任何回應

當流量被 Deny 時，發送方收不到任何回應，這可以避免讓對方知道你的服務存在。

因為傳統的防火牆有一種 Reject 動作，對方知道你存在但不能存取，GCP 防火牆則取消這種功能。

2.4 目標（Target）：套用規則的對象

目標決定了這條規則要套用到哪些資源上。GCP 提供三種指定方式：

• 所有 VM：規則套用到 VPC 內的所有 VM
• 指定網路標籤（Tags）：只套用到有特定標籤的 VM
• 指定服務帳戶（Service Account）：只套用到使用特定服務帳戶的 VM

2.4.1 使用網路標記（Tags）指定目標

網路標記是一個字串，你可以把它貼到 VM 上，然後在防火牆規則裡指定這個網路標記作為目標，這樣可以一次套用規則到多台機器，而非一台一台設定。

例如，你給所有 Web 伺服器貼上 web 標記，再建立一條允許 TCP 80/443 流量套用到 web 的規則，這樣就只有這些 VM 會受到影響。

因為你的專案可能有數十台機器，但只是有 5 台是 Web Server 可以完全對外，這個方法就不用套用到全部的機器上。

標籤的缺點是：任何有適當 IAM 權限的人都可以新增或移除 VM 的標籤，如果管理不當，可能會造成安全漏洞。

2.4.2 使用服務帳戶（Service Account）指定目標

使用服務帳戶來指定目標比標籤更安全，因為修改 VM 的服務帳戶需要更高的 IAM 權限，不容易被誤操作。這個方式特別適合需要高安全性的環境。

尤其是你的主機之間有許多程式要互相存取，而程式在 GCP 環境中都必須帶著 Service Account 以供識別，就很適合這種設定方式。

2.5 來源與目的地（Source / Destination）設定

• 對於 Ingress 規則：你需要指定「來源」，可以是 IP 位址範圍、來源標籤或來源服務帳戶。
• 對於 Egress 規則：你需要指定「目的地」，通常是 IP 位址範圍。

常用的 IP 範圍表示法：

• 0.0.0.0/0：代表所有 IPv4 位址（要小心使用！通常只有 Web Server 才會做這種設定）
• 10.0.0.0/8：代表 10.x.x.x 的私有網路
• 192.168.1.5/32：代表單一 IP 位址

如果一台機器碰到兩條相同優先順序、相同通訊協定和 Port 的規則，則拒絕的規則優先於允許的。

三、設定 GCP 防火牆規則之前，你需要知道的事

3.1 預設防火牆規則有哪些？

當你建立一個新的 VPC 網路（使用「自動模式」）時，GCP 會自動幫你建立四條預設防火牆規則：

你會發現這四條規則的優先順序都是 65534，這是接近最低的優先順序，目的是讓你之後新增的規則可以覆蓋它們。

當然如果用不到也可以刪除。

3.2 隱含規則（Implied Rules）的運作原理

除了上面的預設規則，GCP 還有兩條看不見但永遠存在的隱含規則，你無法刪除或修改它們：

1. 隱含 Ingress Deny 規則（優先順序 65535）：拒絕所有進入的流量
2. 隱含 Egress Allow 規則（優先順序 65535）：允許所有對外的流量

這兩條規則是 GCP 安全設計的基礎——預設情況下，進來的流量全部拒絕，出去的流量全部允許。你設定的規則，就是在這個基礎上「開口」或「關口」。

要注意，因為你無法修改它們，你就無法開啟記錄（Log），如果你想記錄這兩條規則，就必須手動新增規則再開啟記錄。

3.3 如何確認目前的防火牆狀態？

在開始設定之前，建議先看一下目前的狀態，避免重複或衝突。你可以透過 GCP Console 查看：

進入 VPC 網路 → 防火牆，就可以看到目前所有規則的清單，包括名稱、方向、優先順序、動作、目標和來源等資訊。

四、如何在 GCP Console 設定防火牆規則？（圖文步驟）

好了，理論說夠了，我們直接來看怎麼操作！

也可以查接查看 YouTube 示範影片。

4.1 進入防火牆規則設定頁面

1. 登入 GCP Console
2. 在左側選單找到 「VPC 網路」
3. 點擊子選單中的 「防火牆」
4. 你會看到目前所有的防火牆規則清單

4.2 建立新的防火牆規則（逐步說明）

點擊頁面上方的 「建立防火牆規則」 按鈕，開始設定。

4.2.1 填寫規則名稱、說明和是否啟用記錄

• 名稱：必須是英文小寫、數字和連字號組成，例如 allow-http-web-servers。
• 建議用有意義的名稱，讓未來維護時一眼就能看懂這條規則的用途。
• 如果你有多個 VPC，建議增加前綴，例如 default-allow-http-web-servers，其中 default 就是 VPC 的名字。
• 說明（選填）：可以寫更詳細的說明，例如「允許來自任何 IP 的 HTTP 80 流量，只套用到 web-server 標籤的 VM」。

關於記錄功能，平常不會打開，但如果想要做故障排除，例如想知道某個來源 IP 的主機，到底有沒有把流量送過來，可以對 Ingress 的規則啟用記錄；如果想知道你的某台主機，到底有沒有發出流量給對方，可以對 Egress 的規則啟用記錄。

詳細操作說明可以參考這個影片：

4.2.2 設定 VPC 網路、優先順序與方向

• 網路：選擇這條規則要套用到哪個 VPC 網路。
• 優先順序：輸入一個 0 到 65535 的數字，數字越小優先順序越高。建議從 1000 開始，留有上下調整的空間。
• 流量方向：選擇 「Ingress（輸入）」 或 「Egress（輸出）」。
• 如果相符，請執行下列操作：選擇 「允許」 或 「拒絕」。

4.2.3 設定動作與目標

在 「目標」 欄位，選擇規則要套用的範圍：

• 網路中的所有執行個體：套用到 VPC 內的所有 VM（慎用！）
• 指定的目標標籤：輸入你要套用的標籤，例如 web
• 指定的服務帳戶：輸入服務帳戶的 email

4.2.4 設定來源 IP 範圍、通訊協定與連接埠

來源 IP 範圍：

輸入允許的 IP 範圍，例如 0.0.0.0/0 表示允許所有 IP。如果要限制特定範圍，輸入像 203.0.113.0/24。單一 IP 的範例像 203.0.113.18/32。

通訊協定和連接埠：

可以選擇「全部允許」，或指定特定的通訊協定（TCP、UDP）和連接埠號，例如 tcp:80,443。

如果是要設定 Ping 的話，則是勾選「其他」，然後輸入 icmp。

4.3 儲存並驗證規則是否生效

設定完成後，點擊 「建立」 按鈕，規則通常會在幾秒鐘內生效。你可以透過以下方式驗證：

• 回到防火牆規則清單，確認新規則有出現
• 嘗試對你的 VM 進行你預期允許的連線，確認成功
• 嘗試進行你預期被拒絕的連線，確認失敗

五、使用 gcloud CLI 設定 GCP 防火牆規則

如果你是工程師，或是需要用程式自動化管理防火牆規則，gcloud CLI 是你的好朋友。它不只快，而且可以輕鬆整合進 CI/CD 流程。

5.1 安裝與設定 gcloud 工具

如果還沒安裝，可以從 Google Cloud SDK 下載安裝。安裝完後，執行以下指令完成初始化：

gcloud init

按照提示選擇你的帳號和預設專案，設定好之後就可以開始使用了。

5.2 常用防火牆指令整理

以下是最常用的幾個 gcloud 防火牆指令：

# 列出所有防火牆規則
gcloud compute firewall-rules list

# 查看特定規則的詳細資訊
gcloud compute firewall-rules describe RULE_NAME

# 建立防火牆規則
gcloud compute firewall-rules create RULE_NAME \
  --network=NETWORK_NAME \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web

# 刪除防火牆規則
gcloud compute firewall-rules delete RULE_NAME

# 更新防火牆規則
gcloud compute firewall-rules update RULE_NAME \
  --priority=500

5.3 實戰範例：允許 HTTP/HTTPS 流量

假設你想讓 web-server 標籤的 VM 接受所有來源的 HTTP（80 埠）和 HTTPS（443 埠）流量：

gcloud compute firewall-rules create default-allow-http-https \
  --network=default \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web \
  --description="允許來自任何 IP 的 HTTP 和 HTTPS 流量"

執行完後，只要你的 VM 有 web 這個標籤，它就可以接收 80 和 443 埠的流量了。

你也可以點開這一條防火牆規則，畫面滑到最下方，確認這條規則套用到哪些主機上。

5.4 實戰範例：封鎖特定 IP 來源

如果你發現有個 IP 203.0.113.50 一直在嘗試暴力破解你的系統，你可以建立一條高優先順序的 Deny 規則來封鎖它：

gcloud compute firewall-rules create block-malicious-ip \
  --network=default \
  --direction=INGRESS \
  --priority=100 \
  --action=DENY \
  --rules=all \
  --source-ranges=203.0.113.50/32 \
  --description="封鎖惡意 IP 203.0.113.50 的所有流量"

注意優先順序設為 100，遠高於其他規則，確保這條封鎖規則一定會被先套用。

六、GCP 防火牆規則的進階設定技巧

掌握了基礎，我們來看看一些讓你的防火牆設計更精準、更安全的進階技巧。

6.1 使用服務帳戶取代網路標籤的優勢

前面提到，標籤雖然方便，但安全性不如服務帳戶。在對安全要求高的環境中，你應該優先考慮使用服務帳戶來指定防火牆目標。

原因很簡單：更改 VM 的服務帳戶需要 compute.instances.setServiceAccount 這個 IAM 權限，而這個權限通常只有系統管理員才有。相比之下，給 VM 加標籤的門檻低很多。

以 gcloud 指令為例，使用服務帳戶作為目標：

gcloud compute firewall-rules create allow-internal-db \
  --network=default \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-service-accounts=web-sa@my-project.iam.gserviceaccount.com \
  --target-service-accounts=db-sa@my-project.iam.gserviceaccount.com

這條規則的意思是：只允許使用 web-sa 服務帳戶的 VM，連線到使用 db-sa 服務帳戶的 VM 的 5432 埠（PostgreSQL）。

6.2 多層防火牆規則的優先順序設計策略

當你的環境複雜，有很多條規則時，建議採用分層設計，讓規則的邏輯更清晰：

• 優先順序 100-199：緊急封鎖規則（封鎖特定惡意 IP 或攻擊來源）
• 優先順序 500-599：高安全性白名單規則（允許特定管理 IP 的 SSH 存取）
• 優先順序 1000-1999：一般服務規則（允許 HTTP/HTTPS）
• 優先順序 5000-5999：寬鬆的後備規則

這樣的設計讓你在緊急情況下只需要在 100-199 範圍增加一條規則，就可以凌駕所有其他規則，不用修改現有設定。

6.3 Egress 規則：控制對外流量的方法

許多人只注重 Ingress，但 Egress 管控在某些場景下同樣重要。例如：

• 防止 VM 被入侵後對外發動攻擊
• 確保敏感資料不會被傳送到未授權的外部服務
• 符合某些法規要求（如 GDPR）

要限制 VM 只能連到特定的外部服務，你可以先建立一條「拒絕所有 Egress」的規則，再建立允許特定目的地的 Egress 規則：

# 拒絕所有對外流量（優先順序較低，數字較大）
gcloud compute firewall-rules create deny-all-egress \
  --network=default \
  --direction=EGRESS \
  --priority=65000 \
  --action=DENY \
  --rules=all \
  --destination-ranges=0.0.0.0/0

# 只允許連到 Google API（優先順序較高，數字較小）
gcloud compute firewall-rules create allow-google-apis \
  --network=default \
  --direction=EGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:443 \
  --destination-ranges=199.36.153.4/30

6.4 如何限制 SSH 與 RDP 存取來源？

預設的 default-allow-ssh 規則允許來自任何 IP 的 SSH 連線，這對生產環境來說是很大的風險。你應該立即修改這條規則，限制只有你的辦公室或跳板機 IP 可以 SSH 進來：

# 先刪除或停用預設的 SSH 規則
gcloud compute firewall-rules update default-allow-ssh \
  --source-ranges=YOUR_OFFICE_IP/32

如果你使用 GCP 的 IAP（Identity-Aware Proxy）來進行 SSH 連線（強烈推薦！），來源 IP 範圍應設為 35.235.240.0/20：

gcloud compute firewall-rules create allow-ssh-via-iap \
  --network=default \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --description="只允許透過 IAP 的 SSH 連線"

七、GCP 防火牆規則常見錯誤與排除方法

設定完規則之後還是有問題嗎？別擔心，這些常見錯誤我們來一一說明。

7.1 規則設定後仍然無法連線怎麼辦？

遇到這種情況，請按照以下清單依序檢查：

第一步：確認規則存在且已生效

gcloud compute firewall-rules describe allow-http-https

確認規則的所有參數（方向、動作、通訊協定、連接埠、目標）都正確。

第二步：確認 VM 有正確的標籤或服務帳戶

gcloud compute instances describe VM_NAME \
  --zone=ZONE \
  --format='get(tags.items)'

確認 VM 上貼的標籤和規則裡設定的目標標籤一致。

也可以在主控台上確認兩邊設定。

第三步：確認應用程式本身有在正確的埠上監聽

防火牆放行了，但如果你的 Nginx 沒有啟動，或者在 8080 埠而不是 80 埠，一樣連不上。SSH 進 VM 後執行：

sudo netstat -tlnp | grep LISTEN

第四步：確認沒有更高優先順序的 Deny 規則擋住了流量

7.2 優先順序衝突導致規則失效

這是最常見的問題之一。當你有一條 Allow 規則和一條 Deny 規則都符合同一個流量時，優先順序較高（數字較小）的那條才會生效。

如果你建立了一條 Allow 規則，但流量還是被擋，很可能是有另一條 Deny 規則的優先順序更高。你需要去防火牆清單裡，按優先順序排序，仔細檢查每一條可能符合這個流量的規則。

7.3 如何使用防火牆記錄（Firewall Logs）診斷問題？

防火牆記錄是排查問題的神兵利器。它可以記錄下每一條規則「命中」的流量，讓你清楚看到到底是哪條規則在處理你的流量。

啟用防火牆記錄的方式：

gcloud compute firewall-rules update RULE_NAME \
  --enable-logging

啟用後，你可以在 Cloud Logging 裡查看記錄，搜尋關鍵字 resource.type="gce_logName=”projects/[project-id]/logs/compute.googleapis.com%2Ffirewall”firewall_rule"，就可以看到所有防火牆的命中記錄，包括流量的來源、目的地、連接埠，以及是被哪條規則允許或拒絕的。

你也可以直接在某一條防火牆的頁面上點擊「打開記錄」，就會只看得到這條規則的記錄，不需要背下搜尋語法，操作起來更方便。。

八、GCP 防火牆規則的最佳實踐建議

設定防火牆規則沒有所謂的「完美」方法，但有一些最佳實踐是被業界廣泛認可的，我們強烈建議你遵循。

8.1 最小權限原則（Principle of Least Privilege）

這是資安界最核心的原則：只允許必要的流量，拒絕其他一切。

在實作上，這意味著：

• 不要使用 0.0.0.0/0 開放所有 IP，除非真的必要（例如公開的 HTTP 服務）
• 不要開放不需要的連接埠
• 不要用「所有 VM」作為目標，盡量用標籤或服務帳戶精確指定
• 前面的規則設定完成，最後面就設定一條拒絕所有來源的規則。
• 定期審視規則，刪除不再使用的規則

8.2 避免使用 0.0.0.0/0 開放所有來源

我們知道有時候設定 0.0.0.0/0 很方便，但這等於是把你的服務完全暴露在網路上，任何人都可以嘗試連線。特別是 SSH（22 埠）和 RDP（3389 埠），如果開放給 0.0.0.0/0，你的 VM 每天都會被全球各地的掃描工具嘗試暴力破解。你可以看到我的一台主機，隨時有人想要 SSH 登入進來的記錄：

建議做法：

• SSH 和 RDP：使用 IAP 或限制特定 IP 來源
• 資料庫連接埠（如 3306、5432）：絕對不要開放給 0.0.0.0/0
• 應用程式的內部 API：只允許同 VPC 或特定服務的存取

8.3 定期稽核防火牆規則

防火牆規則會隨著時間累積，慢慢出現很多「遺留規則」——當初某個專案用完就沒刪，或是某個同事設了但沒留下說明文件。這些規則可能帶來安全風險，也讓維護變得複雜。

建議至少每季進行一次防火牆規則稽核：

1. 列出所有規則，確認每條規則的用途
2. 刪除或停用不再使用的規則
3. 確認所有規則的來源範圍是否還合適
4. 確認防火牆記錄是否有異常命中

你也可以使用 GCP Security Command Center 或第三方工具來自動化稽核流程，讓安全管理更有效率。

九、結論

GCP 防火牆規則看起來複雜，但只要掌握核心元件——優先順序、方向、動作、目標和來源——你就有能力設計出既安全又彈性的網路架構。

我們從基礎概念出發，學習了防火牆規則的各個元件，再到透過 Console 和 gcloud CLI 實際操作，最後討論了進階技巧和最佳實踐。這套知識讓你不只是「能用」GCP 防火牆，而是「用得好」。

記住最重要的原則：最小權限。不確定要不要開放某個流量時，先選擇拒絕，等確認需求後再開放。這樣的保守態度，才是雲端安全的正確心態。

防火牆設定是一個持續演進的過程，隨著你的服務架構調整，規則也需要跟著調整。養成定期稽核的習慣，並善用防火牆記錄來監控異常流量，你的 GCP 環境就能在安全與可用性之間達到最佳平衡。

常見問題解答（FAQ）

1. GCP 防火牆規則最多可以設定幾條？

每個 VPC 網路最多可以設定 200 條防火牆規則。如果你的環境非常複雜，需要更多規則，可以聯絡 GCP 支援申請提高配額。不過通常 200 條對大多數環境來說已經足夠，如果超過這個數量，建議檢視是否可以合併或簡化規則。

2. 防火牆規則的優先順序數字越小代表越高優先？

是的，完全正確。優先順序是一個介於 0 到 65535 的整數，數字越小，優先順序越高。當多條規則同時符合同一個流量時，優先順序最高（數字最小）的規則會被套用。如果優先順序相同，則 Deny 規則優先於 Allow 規則。

3. GCP 預設的防火牆規則可以刪除嗎？

可以的，四條預設規則（allow-internal、allow-ssh、allow-rdp、allow-icmp）都可以刪除。但要小心，刪除這些規則可能會導致你無法 SSH 進 VM。建議在刪除之前，先確認你有其他方式可以管理 VM（例如 Cloud Console 的序列主控台）。至於 GCP 的兩條隱含規則（最低優先順序的 Deny Ingress 和 Allow Egress），這兩條是無法刪除或修改的。

4. 如何確認防火牆規則是否正確套用到 VM？

你可以在 VM 的詳細資訊頁面查看「網路介面」區塊，點擊「防火牆規則詳情」就可以看到套用到這台 VM 的所有防火牆規則，包括每條規則的方向、優先順序和動作。另外，也可以啟用防火牆記錄，透過 Cloud Logging 查看實際的流量命中記錄，這是最直接的驗證方式。

5. Ingress 和 Egress 規則的差別是什麼？

Ingress 規則管控的是「從外部進入你的 VM」的流量，例如使用者連線到你的網站。Egress 規則管控的是「從你的 VM 送往外部」的流量，例如你的 VM 去呼叫外部 API。GCP 的防火牆是有狀態的，允許一個 Ingress 連線後，這個連線的回應封包會自動被允許出去，不需要另外設 Egress 規則。

6. GCP 防火牆支援 IPv6 嗎？

是的，GCP 防火牆支援 IPv6。如果你的 VPC 網路有啟用 IPv6，你可以在防火牆規則的來源或目的地範圍裡指定 IPv6 的 CIDR 範圍（例如 ::/0 代表所有 IPv6 位址）。需要注意的是，IPv4 和 IPv6 的規則需要分開設定，一條規則無法同時套用兩者。

7. 使用服務帳戶設定防火牆目標有什麼好處？

使用服務帳戶作為防火牆目標比使用標籤更安全，原因在於：修改 VM 的服務帳戶需要較高的 IAM 權限（compute.instances.setServiceAccount），不容易被誤操作或惡意修改。標籤則相對容易被有 compute.instances.setLabels 權限的人任意添加，存在一定的安全風險。在高安全性環境，優先選擇服務帳戶作為目標。

8. 防火牆規則可以套用到多個 VPC 嗎？

不行，一條防火牆規則只能套用到單一 VPC 網路。如果你有多個 VPC 需要相同的規則，你需要在每個 VPC 裡分別建立規則。如果你使用的是共用 VPC（Shared VPC），你可以在宿主 VPC 裡建立規則，這樣所有連接到這個共用 VPC 的服務專案都會套用這條規則。

9. 如何透過 Terraform 管理 GCP 防火牆規則？

Terraform 是管理 GCP 防火牆規則的最佳工具之一，因為它可以讓你用程式碼（Infrastructure as Code）定義規則，版本控制和稽核都更容易。使用 google_compute_firewall 資源即可：

resource "google_compute_firewall" "allow_http" {
  name    = "allow-http"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["80", "443"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["web-server"]
}

10. 開啟防火牆記錄會增加費用嗎？

是的，開啟防火牆記錄會產生額外費用，費用是依據記錄的資料量計算（以 Cloud Logging 的計費方式收費，超出免費額度後才收費）。在流量大的環境裡，記錄費用可能不小。建議做法是：只在特定需要診斷的規則上開啟記錄，完成診斷後再關閉；或使用記錄過濾條件（Log filtering）只記錄特定類型的流量，以控制費用。

GCP 防火牆規則只是眾多資安服務的其中一種，如果你想了解更多，可以查看《雲端的資訊安全防禦縱深，常用資安服務介紹》。

The post GCP 防火牆規則如何設定？5 步驟完整攻略與實戰技巧 first appeared on 東東 GCP 教學 - GCP 實戰講師.

🔷 什麼是 BigQuery 企業資料倉儲？

傳統的地端資料倉儲（On-premises Data Warehouse）需要企業自行採購硬體、規劃容量、安排停機維護。相比之下，BigQuery 提供的是「隨需擴展、按量計費、零維護成本」的雲端分析環境，讓數據分析師可以把時間花在洞察分析，而不是等待基礎設施就緒。

🔷 Home Depot 為什麼要導入 BigQuery？

地端資料倉儲的三大痛點

Home Depot 擁有超過 2,200 間門市、70 萬種商品品項，龐大的業務規模讓傳統資料倉儲不堪負荷。導入 BigQuery 之前，他們面臨以下困境：

1. 擴容困難、停機成本極高 每次需要增加地端儲存容量，都要經歷六個月的規劃期與長達三天的服務中斷。即便如此，容量不到一年又告警示。這對 24 小時不間斷的零售業來說，是難以接受的風險。

2. 數據規模持續爆炸性成長 隨著電商、門市 POS、供應鏈、網站點擊流（Clickstream）等新數據來源加入，分析師需要的數據量遠超地端系統的上限，查詢複雜度也不斷提升。

3. 團隊協作效率低落 不同業務部門的分析工作常常互相搶奪有限的運算資源，導致報表延遲、決策速度下降。

🔷 Home Depot 是怎麼導入 BigQuery 的？

企業導入 BigQuery 的核心流程

雖然每間企業的情況不同，但 Home Depot 的案例揭示了一條可複製的遷移路徑：

步驟 1：評估現有資料倉儲瓶頸 確認地端系統的容量上限、查詢效能瓶頸，以及哪些業務場景（供應鏈、財務、客訂等）是最高優先級的遷移目標。

步驟 2：設計多專案的 IAM 權限架構 利用 BigQuery 的 Identity and Access Management（IAM），建立多個 Google Cloud Project，讓不同業務部門各自管理數據，防止跨部門誤存取或資料外洩。

步驟 3：將地端資料遷移至 BigQuery Home Depot 原本的地端資料倉儲容量為 450 TB，完整遷移至 BigQuery 後，現在的資料規模已超過 15 PB——足足是原來的 33 倍以上。

步驟 4：採用 Flat-rate 月費方案，控制預算可預測性 BigQuery 提供按查詢量計費與固定月費（Flat-rate）兩種計費模式。Home Depot 選擇固定月費，讓各部門可以依需求預算容量，未使用的資源也可供全企業共享，避免月底帳單暴增的驚喜。

步驟 5：擴展進階分析能力 遷移完成後，分析師開始啟用 Datalab（Python Notebook 環境）、BigQuery ML（直接在倉儲中訓練機器學習模型）和 AutoML，大幅提升預測分析能力，而無需額外搬移大型數據集。

🔷 BigQuery 導入後的實際效能數據

以下是 Home Depot 遷移至 BigQuery 後，各業務場景的效能提升對比：

🔷 BigQuery 對企業的三大核心優勢

① 無縫擴容，零停機

地端系統需要三天停機才能完成擴容，BigQuery 擴容只需一週（未來甚至可達當日完成），且全程無服務中斷。

② 標準 SQL，快速上手

BigQuery 支援標準 SQL 語法，企業內部的資料分析師不需要重新學習專有查詢語言，大幅降低遷移的人力學習成本。

③ IAM 隔離，企業安全合規

透過多 Project + IAM 的架構，不同業務單位的數據得以嚴格隔離，既能共享運算資源，又能確保敏感數據不被跨部門誤存取——這對金融、零售、醫療等高合規需求產業尤為重要。

🔷 哪些企業適合導入 BigQuery？

並非所有企業都需要立刻遷移到 BigQuery，以下幾個特徵可以幫助你判斷：

適合導入 BigQuery 的情境：

• 每月數據查詢量持續增長，地端系統頻繁出現效能瓶頸
• 有多個部門需要各自分析數據，但又需要共享運算資源
• 希望將 ML 模型訓練與數據倉儲整合，減少數據搬移成本
• 需要對 TB 至 PB 級數據進行即時（或近即時）分析

暫時不適合的情境：

• 數據規模仍在 TB 以下，且查詢頻率低
• 企業有嚴格的資料主權法規，無法將數據存放於境外雲端
• 預算有限，且目前系統的效能尚在可接受範圍

結論

對正在評估雲端資料倉儲的企業而言，BigQuery 最值得關注的不只是效能數字，而是它讓分析師能把時間花在「發現洞察」而非「等待查詢」——這才是數據驅動組織真正需要的能力。

❓ 常見問題 FAQ

Q1：BigQuery 和傳統資料庫有什麼不同？ BigQuery 是專為大規模分析查詢設計的 OLAP（線上分析處理）系統，而傳統資料庫（如 MySQL、PostgreSQL）是為交易型操作（OLTP）設計的。BigQuery 不適合高頻率的單筆資料寫入或更新，但面對跨數億筆資料的聚合查詢，其速度遠超傳統關聯式資料庫。

Q2：BigQuery 的費用怎麼計算？ BigQuery 提供兩種計費模式：按查詢量計費（每 TB 掃描資料約 5 美元）與固定月費（Flat-rate，依 Slot 數量預付）。小型企業通常從按量計費開始，數據量大或查詢頻繁的企業則更適合固定月費以控制成本可預測性。

Q3：將地端資料倉儲遷移到 BigQuery 需要多久？ 遷移時間取決於數據量、資料清理複雜度與組織的技術能力。一般中大型企業的完整遷移週期約為 3 至 12 個月，建議採用「分批遷移、驗證後切換」的策略，降低業務中斷風險。

Q4：BigQuery 可以跑機器學習嗎？ 可以。BigQuery ML 允許分析師直接在 BigQuery 內使用 SQL 語法訓練迴歸、分類、時間序列等多種 ML 模型，無需將數據匯出至其他平台，大幅降低 ML 導入的門檻與數據搬移成本。

Q5：GCP 的 BigQuery 和 AWS Redshift、Azure Synapse 相比哪個更好？ 三者各有優勢，但 BigQuery 的無伺服器架構讓維運成本最低；Redshift 在 AWS 生態系整合較佳；Synapse 則適合深度整合 Microsoft 工具的企業。選擇時應優先考量企業現有技術棧、資料量規模與合規需求，而非單純比較功能清單。

Q6：如何上傳資料到 BigQuery？

可參考此文章：https://dongdonggcp.com/2025/02/12/how-to-upload-data-to-bigquery/

本文引用來源：https://cloud.google.com/customers/the-home-depot

The post BigQuery 成功案例 – Home Depot (家得寶) 導入 GCP 的案例解析 first appeared on 東東 GCP 教學 - GCP 實戰講師.

雲端架構師（Cloud Architect）是規劃和設定雲端環境 （GCP、AWS、Azure） ，讓系統可以在雲端上順暢地跑起來的人。

也是根據公司要運作程式的需求（例如：想要架設電商網站），提出雲端解決方案（例如：自動擴充搭配負載平衡） 的人。

你可以把雲端架構師想像成「雲端世界的建築師」——一般建築師設計房子，雲端架構師設計的是一棟棟跑在雲端上的數位建築物。

雲端架構師的核心職責

雲端架構師的日常工作，主要包含以下幾個面向：

1. 評估需求：與業務單位溝通，了解系統規模、流量、安全需求
2. 設計架構：規劃雲端網路（Virtual Private Cloud; VPC）、Kubernetes 叢集、資料庫佈署方式
3. 成本管理：透過預算、長期的承諾使用折扣 （Committed Use Discount）、短期的續用折扣（Sustained Use Discount） 等機制降低雲端使用成本
4. 資安規劃：設定 Cloud IAM 權限和角色、防火牆、金鑰管理服務（KMS）設定加密、Security Command Center 監控雲端環境
5. 技術支援：協助開發團隊解決各種雲端疑難雜症
6. 維運監控：建立 Cloud Monitoring、Cloud Logging 警告機制

雲端架構師 vs 一般軟體工程師的差異

很多人會問：「雲端架構師跟工程師哪裡不一樣？」

最簡單的區分方式是：軟體工程師「寫程式解決問題」，雲端架構師「設計環境讓程式可以穩定運行」。工程師關注的是程式的各項功能運作，架構師關注的是基礎設施和整體系統架構。

兩者的互動是：工程師寫好程式，但不知道如何放到雲端上跑，由雲端架構師把環境設定好，然後幫工程師把程式放上去。

在薪資上，架構師普遍高於同年資的開發工程師，這也是為什麼許多工程師選擇往雲端架構師方向發展的主要原因。

2026 年台灣雲端架構師薪水行情

根據台灣 1111 人力銀行、104 人力銀行、CakeResume 及 LinkedIn 等平台的職缺資料，台灣雲端架構師月薪範圍約落在 8 萬到 20 萬新台幣之間，年薪含獎金可達 120 萬到 250 萬元，具備多雲認證者更有談判高薪的籌碼。

以下依照資歷分三個等級說明：

初階雲端架構師薪資（0～3 年雲端經驗）

初階雲端架構師通常來自系統工程師、網路工程師或軟體工程師轉職而來。這個階段的工作以「執行」為主，配合資深架構師的規劃進行實作。

初階薪資提升關鍵： 拿到第一張雲端 Associate 等級認證後，月薪通常可立即提升 5,000 至 15,000 元，對應聘資格影響非常大。

中階雲端架構師薪資（3～8 年雲端經驗）

這個階段的架構師已經能獨立主導專案，開始帶領小團隊，並且有能力與客戶直接溝通技術方案。如果你同時具備兩張以上 Professional 等級認證，薪資談判空間會更大。

資深雲端架構師薪資（8 年以上 / 特殊專長）

資深架構師的薪水往往不只來自技術能力，更來自「業務開發能力」——能不能幫公司拿到大型雲端專案，直接決定你的市場價值。

很多高薪的雲端架構師，其實就是售前（Presales），主要職責就是協助公司推廣雲端產品，拿到雲端開發或建置案，除了能賺取專案的人力費用，客戶每個月使用雲端產生的被動收益，也是公司的主要收入來源。這種能夠幫公司賺錢的雲端架構師，薪水就遠遠超過只是操作內部系統的雲端架構師。

台灣雲端架構師的薪資天花板遠高於一般工程師職位。初階月薪 6～9 萬，中階 9～15 萬，資深可達 15～25 萬，年薪突破 200 萬並非少見。具備 GCP Professional Cloud Architect、AWS Solutions Architect 等 Professional 等級認證，是突破薪資瓶頸最直接有效的方式。

全球雲端架構師薪水比較

如果你有考慮出國工作或遠端接案，以下是各主要市場的薪資對比：

美國、日本、新加坡薪資比較

從這份比較表可以看出，台灣雲端架構師的薪資雖然相對美國偏低，但如果跟台灣其他 IT 職位相比，仍屬於高薪族群。尤其新加坡市場對台灣雲端架構師的需求相當高，是值得關注的出海選項。

像我個人也曾經收到要去新加坡建置大型雲端架構的案子，客戶會願意為此進行大筆投資。

影響雲端架構師薪水的關鍵因素

同樣是雲端架構師，為什麼薪水可以差到兩倍以上？以下是最關鍵的幾個因素：

GCP / AWS / Azure 認證的薪資加乘效果

雲端認證是影響架構師薪資最直接的因素之一，如果你沒有證據證明你在雲端的能力和經驗，持有證照就是唯一客觀的評估標準。持有 GCP Professional Cloud Architect 認證的工程師，平均薪資比未持有認證者高出 20%～40%。若同時持有 GCP + AWS 雙認證，在台灣的求職市場幾乎是「有求必應」的狀態。

主要認證對薪資的影響如下：

GCP 系列認證：

• Associate Cloud Engineer：月薪提升 5,000～15,000 NTD
• Professional Cloud Architect：月薪提升 15,000～30,000 NTD
• Professional Data Engineer / Security Engineer：額外加給 10,000～20,000 NTD

AWS 系列認證：

• AWS Solutions Architect – Associate：月薪提升 8,000～18,000 NTD
• AWS Solutions Architect – Professional：月薪提升 20,000～40,000 NTD

關鍵提醒： 認證只是敲門磚，沒有實戰經驗搭配的認證說服力有限。最理想的狀況是邊工作邊考證，讓認證為你的實戰能力背書。

產業別薪資差異

不同產業對雲端架構師的需求和出價也有明顯差異：

如何成為雲端架構師？轉職路徑完整說明

從非技術背景轉職的真實案例

我自己的經歷就是一個很好的例子。我大學念統計系、研究所念企管，完全沒有資工背景，後來卻成為 GCP 的雲端架構師，現在在 YouTube 和部落格上教別人 GCP。

我的轉職路徑大概是這樣：

1. 2008年：花十萬元自費學習 Windows Server + SQL Server，考取 MCSA、MCDBA、RHCE 證照
2. 2009年：進入系統整合商，實際接觸政府 IT 系統，寫過 C# 和 Java
3. 2013年：透過前主管介紹，進入 Google 合作夥伴公司做 Presales
4. 2014年：GCP 在台灣開始大力推廣，轉型為 GCP 雲端架構師
5. 2023年：跳出來做自媒體「東東 GCP 教學」，分享 GCP 知識

轉職雲端架構師不一定需要資工本科背景。許多成功的雲端架構師來自系統工程師、網路管理員、甚至非技術職位（如 IT Presales、專案經理）。關鍵在於「取得認證 + 累積實戰案例 + 持續學習」這三個同步進行的動作，缺一不可。

接近 40 歲的時候，我也非常擔心機會越來越少。但事實證明，只要在一個特定的技術領域持續深耕，即使非本科也能建立別人難以取代的競爭優勢。

需要哪些技能與證照？

成為雲端架構師需要的技能可以分成「硬技能」和「軟技能」兩大類：

硬技能（技術能力）：

1. 網路基礎：TCP/IP、DNS、VPC、防火牆規則
2. Linux 系統管理：基本指令操作、權限管理、Log 分析
3. 容器技術：Docker、Kubernetes（GKE）
4. IaC（基礎設施即程式碼）：Terraform、Kubernetes YAML 撰寫
5. 資安概念：IAM 設計、加密金鑰管理、Zero Trust 架構
6. 資料庫：Cloud SQL、BigQuery、Spanner 的使用情境
7. 監控：Cloud Monitoring、Cloud Logging、告警設定

軟技能（非技術能力）：

1. 溝通能力：能把技術翻譯給非技術主管聽
2. 問題分析：面對客戶疑難雜症時的邏輯思維
3. 成本意識：設計架構時要同步考量 ROI
4. 文件撰寫：架構圖、技術提案、RFP 回覆

建議取得的認證順序（以 GCP 為例）：

1. 第一步：GCP Associate Cloud Engineer（建立基礎）
2. 第二步：GCP Professional Cloud Architect（主力認證）
3. 第三步：依照工作方向加考 Professional Data Engineer 或 Professional Security Engineer

雲端架構師薪水成長策略

光知道「雲端架構師薪水高」還不夠，你需要一套具體的薪資成長策略：

如何用 GCP 認證快速提升薪資

策略一：先考再談，用證照打開門

很多公司對認證持有者有加薪機制，甚至有證照獎金（有些公司每張證照獎勵 1 萬到 3 萬不等）。拿到認證後，跳槽或內部升遷都有更多籌碼。

策略二：做出可量化的成果

在面試時，「我幫公司把雲端帳單降低 30%」比「我有三年雲端架構師經驗」有力得多。每做完一個專案，一定要記錄下來：做了什麼、節省多少成本、解決什麼問題。

策略三：建立個人品牌

我自己從 2023 年開始做「東東 GCP 教學」，透過 YouTube 頻道、部落格（dongdonggcp.com）、Linked-in、和 Threads 分享 GCP 知識。這不只帶來了額外的收入來源，更讓我在行業內建立了可信度。

對雲端架構師來說，公開展示自己的技術知識，是目前最有效的個人品牌策略之一。

策略四：專精一個垂直領域

與其成為「什麼都懂一點」的泛用型架構師，不如在某個特定領域（如金融雲、醫療雲、AI 基礎設施）成為領域專家。垂直深度往往比水平廣度更能帶來薪資溢價。

雲端架構師要有效提升薪資，最快的方法是：取得 Professional 等級認證（立即增加談判籌碼）、記錄可量化的成果（降低帳單、提升穩定性的具體數字）、以及在特定垂直產業建立深度專業。這三個動作同步進行，年薪提升 30%～50% 是可預期的。

雲端架構師薪水 FAQ 常見問題

Q1：沒有資工背景可以成為雲端架構師嗎？

A： 完全可以。許多優秀的雲端架構師來自非資工背景，包括統計、企管、甚至人文科系。關鍵是你願不願意主動考取認證、累積實戰經驗。台灣確實有很多成功案例，從統計系、商科出身轉職為 GCP 架構師的人並不少見。重要的是要有系統地學習：先從 GCP Associate Cloud Engineer 認證入門，邊學邊做，循序漸進。

Q2：雲端架構師和 DevOps 工程師的薪水哪個比較高？

A： 在台灣市場，雲端架構師的平均薪資略高於 DevOps 工程師，尤其在資深等級差距更明顯。因為 DevOps 工程師雲端架構師月薪區間約 8 萬～20 萬，DevOps 工程師約 7 萬～16 萬。不過兩者界線越來越模糊，很多公司的雲端架構師職位本身就包含 DevOps 工作，具備 CI/CD pipeline 設計能力的架構師，薪資競爭力會更強。

Q3：GCP 認證和 AWS 認證，哪個對薪資幫助更大？

A： 以台灣市場來看，AWS 認證的市場認知度略高，職缺數量也稍多；但 GCP 認證在特定產業（尤其是媒體、廣告科技、AI 應用）有明顯優勢，而且考試難度相對較高，持有者的含金量也相對較高。最理想的狀況是同時持有 GCP Professional Cloud Architect + AWS Solutions Architect，雙認證的組合在談薪水時最有底氣。

Q4：轉職雲端架構師大約需要多久？

A： 有技術基礎（如系統工程師、網路管理員）的人，通常 1～2 年可以完成轉型；從非技術職位（如 IT Presales、PM）轉職則需要 2～3 年。關鍵不是時間長短，而是「是否有機會接觸真實的雲端專案」。即使沒有，也可以透過 Google 官方的 Cloud Skills Boost 平台刷題目、做 Lab，累積實戰感。如果你覺得自學太慢了，可以加入雲端架構師養成班，藉由完整的學習和實作，加快考取證照並成功轉職的速度。

Q5：台灣雲端架構師的未來發展前景如何？

A： 非常樂觀。隨著台灣企業數位轉型加速、AI 應用崛起（Vertex AI、Gemini API 的整合需求），以及半導體產業上雲趨勢持續，雲端架構師的需求預計在未來 5 年內仍持續成長。特別是具備 AI/ML 基礎設施規劃能力的架構師，將成為市場上最搶手的人才之一。

結論：雲端架構師是值得投資的職涯方向

雲端架構師是目前台灣 IT 市場薪資成長最快的職位之一，年薪 120 萬到 250 萬的機會對有認證、有實戰的人來說相當實際。轉職門檻雖然存在，但並非不可跨越——只要系統性學習、取得認證、累積可量化成果，即使是非本科背景，也能在 2～3 年內完成轉型。

我自己從完全不懂 GCP，到成為雲端架構師、再到現在透過「東東 GCP 教學」分享這些知識，走了超過十年。這條路不一定要走那麼久——因為現在的學習資源、認證體系、社群支持都比十年前豐富太多了。

如果你對轉職雲端架構師有興趣，或者已經在雲端領域工作但想要加速薪資成長，歡迎來 dongdonggcp.com 看看我整理的 GCP 實戰教學，或是訂閱「東東 GCP 教學」的 YouTube 頻道，我們一起在雲端世界找到自己的位置。

如果還有什我疑問，也可以加 Line: @754xlakm 直接與我聯絡，透過線上諮詢來了解你的情況，並提供你適合的發展方向。

The post 雲端架構師薪水完整指南：薪資行情、加薪技巧與轉職攻略 first appeared on 東東 GCP 教學 - GCP 實戰講師.