零經驗轉職，從雲端工程師入門最快。

打開 104，搜尋「雲端」或「GCP」，你會看到一堆職稱跳出來：雲端工程師、雲端架構師、SRE、DevOps 工程師、資料工程師⋯⋯

看起來都跟雲端有關，但薪資區間、要會的技能、日常工作內容差距很大，光是月薪區間的起點，架構師就比工程師高 2 萬以上。

這是轉職者最常卡住的第一個問題：「我到底該投哪一個？」

為什麼一定要先搞懂職缺差別？

搞錯職缺，你會浪費半年學錯東西。

想當架構師卻先去學 Python 、想走 SRE 卻只考了 Associate 認證，這兩種情況都是真實發生過的彎路。

5 種角色的技能重疊度不到一半，證照方向也不同。先確定要走哪一條，再開始學，是最省時間的做法。

先用一個比喻，30 秒秒懂 5 種角色

把一個跑在雲端上的系統，想像成「一棟蓋在雲上、24 小時營業的大樓」：

• 雲端架構師（Cloud Architect）＝設計師：決定這棟樓怎麼蓋、幾層、水電怎麼配、消防怎麼做。動手少，但方向錯了全樓要打掉重來。
• 雲端工程師（Cloud Engineer）＝施工與水電師傅：照著設計圖把樓蓋起來、把服務一個一個裝上去、平常的修修補補。
• SRE（網站可靠性工程師）＝大樓的保全兼維修隊：確保這棟樓 24 小時不斷電、不出事，出事能最快修好，還會想辦法用自動化讓自己少值班。
• DevOps 工程師＝生產線的自動化總管：讓「設計→施工→開張」這條線跑得又快又順，蓋新東西不用每次都手工搬磚。
• 資料工程師（Data Engineer）＝專門鋪水管的人：把散在各處的資料，用管線接到一個大水塔（資料倉儲），讓需要用水（分析、AI）的人隨時打開就有。

記住這個比喻，下面每一段就很好懂了。

雲端工程師（Cloud Engineer）：最好的轉職起點

在做什麼？

雲端工程師是負責在雲端平台上實際建置與維運系統的執行角色，用來把架構師畫好的藍圖變成真的跑得起來的服務。

架構師畫好藍圖之後，由雲端工程師到 GCP、AWS、Azure 上把資源建起來。

日常工作包括：開 VM、設定虛擬私有網路（VPC，你在雲上的專屬網段）、部署 Cloud Run、設定權限（IAM）、處理維運和排錯。

一句話：架構師決定「要怎麼蓋」，雲端工程師負責「把它蓋出來、顧好它」。

需要什麼技能？

• 一朵雲的基本操作（建議先專精 GCP 或 AWS 一朵）
• Linux 基本指令、網路基礎（IP、DNS、防火牆）
• 容器基礎（Docker）
• 會看 Log、會排簡單的錯

薪水與適合誰

台灣月薪參考區間約 5～8 萬，同一個職稱在不同公司的落差可達 3 萬。

這是 5 種角色裡入門門檻最低、需求量最大的職缺，適合零經驗和非本科。

先卡進這個位置累積實戰，再往架構師發展，是最務實的路線。

雲端架構師（Cloud Architect）：薪資天花板最高

在做什麼？

雲端架構師是負責規劃整體雲端方案的設計角色，用來在系統動工前決定架構、成本與資安要怎麼配。

他要跟業務單位溝通需求，回答這些問題：系統要不要自動擴充（Autoscaling）？資料庫怎麼配才不會掛？成本怎麼壓？資安怎麼守？

架構師動手寫程式的比例比工程師低，但這不代表「不用懂 code」。

好的架構判斷，正是建立在「知道底層怎麼實作、會踩到什麼坑」之上。

差別在於，架構師的價值在「判斷怎麼設計才不會出事」，而不是「把功能刻出來的速度」。

需要什麼技能？

• 工程師那一整套技能，再往上加
• 整體架構設計能力（網路、運算、資料庫、資安怎麼串在一起）
• 成本意識（CUD／SUD 折扣、預算控制）
• 溝通能力：把技術講給非技術主管聽
• 當你要應徵架構師職缺時，Professional 等級認證是明確的加分條件

薪水與適合誰

台灣月薪參考區間約 6～12 萬以上，資深加上業務開發能力可以更高（詳細分級可看我另一篇《雲端架構師薪水完整指南》）。

適合已經有一些 IT 底子、想往上走、想突破薪資天花板的人。

雲端工程師和架構師的差別，最簡單記法：工程師「把系統做出來、顧好」，架構師「決定整個系統該長什麼樣」。同年資下，架構師的月薪區間起點比工程師高 3 萬以上。

轉職者最務實的路徑是：先當工程師卡位，累積各種架構經驗之後，再升架構師。

SRE 與 DevOps 工程師：高度重疊、常常混用

這兩個職稱在台灣的職缺裡界線非常模糊，有些公司直接混著用。但概念上還是有差別。

DevOps 是一種「文化與做法」

DevOps 原本不是一個職稱，而是一種「把開發（Dev）和維運（Ops）打通」的做法。

目標是讓「寫好程式→測試→上線」這條路自動化、又快又穩，不要每次上線都手忙腳亂。

DevOps 工程師的日常，圍繞在三件事：

1. 建立 CI/CD 流水線（CI/CD 是「持續整合／持續交付」，指程式一改好就自動測試、自動上線的機制）
2. 用 IaC（基礎架構即程式碼，例如 Terraform）把環境設定寫成可重複執行的檔案
3. 把重複的部署工作自動化

SRE 是「用軟體工程的方法做維運」

SRE（Site Reliability Engineering）是 Google 提出的可靠度工程方法，用來以軟體工程的手段確保系統穩定，可以理解成 DevOps 的一種具體實作。

SRE 更強調用數據和工程手段顧穩定：

• SLO／SLI：訂出可量化的可靠度目標，例如「一個月內成功率要達 99.9%」
• Error Budget（錯誤預算）：從 SLO 反推出「這個月還能容忍多少故障時間」，用完就停止上新功能
• Toil（重複勞務）：指可以被自動化卻還在手動做的工作，SRE 的任務之一就是把它消滅

一句話：DevOps 是理念，SRE 是把這套理念工程化落地的做法。

需要什麼技能 & 適合誰

• 兩者都要：熟一朵雲、容器與 Kubernetes（GKE）、CI/CD 工具、監控告警、寫腳本自動化（Python／Shell）
• SRE 職缺對寫程式和數據思維的要求，比 DevOps 更明確
• 台灣月薪參考區間約 7～14 萬
• 適合已經有開發或系統維運經驗、喜歡用自動化消滅重複工作的人；零經驗要先補不少底子

SRE 和 DevOps 差在哪？DevOps 是「理念」，把開發和維運打通、追求自動化交付；SRE 是「其中一種工程化做法」，用 SLO、error budget、削減 toil 來顧穩定。在台灣的職缺裡兩者常混用，看職務說明（JD）比看職稱準。

資料工程師（Data Engineer）：最需要寫程式的工作

在做什麼？

資料工程師是負責建置與維護資料管線的角色，用來把散落各系統的資料收乾淨、送進資料倉儲，讓分析和 AI 隨時有料可用。

他要把資料透過資料管道（Data Pipeline）收集、清理、轉換，送進資料倉儲（像 BigQuery，一個專門存放大量分析用資料的地方）。

在 GCP 上，這個角色天天碰的是 BigQuery、Dataflow、Pub/Sub、Cloud Composer 這些服務。

需要什麼技能？

• 要會寫程式：SQL 是基本，Python 是資料工程師職缺最常列出的語言（這一點跟架構師很不一樣，別搞混）
• 資料庫與資料建模概念
• 資料管道工具（ETL／ELT，指把資料「抽取→轉換→載入」的兩種流程順序）
• 大數據處理（批次 vs 串流），串流資料 (Streaming Data) 指的是「每分每秒持續不斷產生的資料」。

薪水與適合誰

台灣月薪參考區間約 8～16 萬，AI 熱潮下需求持續走高。

適合喜歡跟資料打交道、不排斥寫程式的人。

如果你本來就是後端工程師、或做過數據相關工作，這是很順的轉職方向。

一張表看懂 5 種雲端職缺

⚠️ 薪資皆為市場「參考區間」，實際受公司規模、產業、年資、面試表現影響，不是保證數字。最準的方式是自己上 104 搜尋對應職稱，看你所在地區實際開出來的薪資與職缺量。

重要提醒：這些職稱的界線，在台灣其實很模糊

上面的分法是「理想中的分工」，但台灣的中小型公司沒有分這麼細。

一個人同時做架構設計、資源部署、CI/CD 維護，甚至兼顧資料庫，在中小型團隊是常態。

反過來，當公司規模大到有獨立的 SRE 團隊時，角色會切得很細，SRE 就是 SRE，不碰資料管道。

所以我的建議是：別太糾結職稱，要看「職務說明（JD）」裡實際列的工作內容和技能要求。

職稱只是入口，JD 才是你真正要做的事。

我該從哪一個入門？轉職路徑建議

如果你正在轉職，我會這樣建議：

1. 零經驗／非本科：從雲端工程師入門。入門門檻最低、需求最大，先考一張 Associate 等級認證（如 GCP Associate Cloud Engineer）卡進去，累積實戰。
2. 已有 IT 底子（後端、網管、系統）：可以直接朝雲端架構師或 SRE／DevOps 準備，考 Professional 等級認證。
3. 做過資料、喜歡寫程式：資料工程師會是很順的方向。

不管走哪一條，共同的起手式都是這三步：

1. 選定一朵雲（建議先專精 GCP 或 AWS）
2. 考一張對應等級的證照
3. 想辦法碰到真實專案 （你可以叫 AI 出題目，也能教你手把手實作專案）

這三件事同步做，比漫無目的地自學快得多。

到底該考哪一張 GCP 證照？非 IT 背景建議先考 Associate 拿手感，有 IT 背景可以直接攻 Professional。（這部分我另有專文詳談。）

雲端職缺 FAQ 常見問題

Q1：完全沒經驗，我該投哪一個雲端職缺？

A： 投雲端工程師（Cloud Engineer）。這是 5 種雲端職缺裡入門門檻最低、需求量最大的職缺，適合零經驗和非本科。先考一張 Associate 等級認證卡進去，邊做邊學，再往架構師或 SRE／DevOps 發展。

Q2：SRE 和 DevOps 到底差在哪？

A： DevOps 是一種「把開發和維運打通、追求自動化交付」的理念與做法；SRE 則是 Google 提出的具體實作，用 SLO、Error Budget、削減 Toil 這些工程手段來落實它。在台灣的職缺裡兩者經常混用，看職務說明比看職稱準。

Q3：資料工程師需要很會寫程式嗎？

A： 需要。資料工程師是這 5 個角色裡最需要寫程式的，SQL 是基本，Python 是職缺中最常出現的語言要求。這一點和雲端架構師剛好相反（架構師寫 code 較少、重在設計判斷），常被搞混，轉職前要想清楚自己喜不喜歡寫程式。

Q4：這幾個職缺，哪個薪水最高？

A： 以台灣市場的天花板來看，資料工程師最高，其次資深 SRE 與雲端架構師。但同一個職稱在不同公司可以差兩倍以上，認證、實戰成果和產業別對薪資的影響比職稱本身更大。

Q5：這些職缺都要會 Kubernetes 嗎？

A： 不一定，但會是加分。SRE、DevOps 幾乎一定要碰 Kubernetes（在 GCP 上就是 GKE）；雲端工程師和架構師要懂概念、知道何時該用，不見得天天操作；資料工程師相對碰得少。想走 SRE／DevOps，Kubernetes 是必補的一塊。

Q6：非資訊科系、學歷普通，投雲端職缺會被刷掉嗎？

A： 雲端職缺看的是「你能不能操作」，不是科系。104 上的雲端工程師職缺，多數把證照和專案經驗列在必要條件，學歷欄常是「不拘」。與其糾結學歷，不如把一個能展示的實作專案做出來，面試時能講清楚你怎麼建、遇到什麼錯、怎麼解，比科系有用。

Q7：沒有證照可以直接應徵雲端工程師嗎？

A： 可以，但會辛苦很多。證照的功能是幫你通過履歷篩選這一關，尤其在你沒有相關工作經驗時，它是唯一能證明你懂的東西。如果你已經有 3 年以上系統或後端經驗，實戰成果可以取代證照；零經驗的話，證照是最短的敲門磚。

Q8：雲端職缺會不會被 AI 取代？

A： 短期內不會，但工作內容會變。AI 已經能生成 Terraform 設定檔和排錯建議，取代的是「手動打指令」這一層，也就是 SRE 口中的 toil。留下來的是判斷力：架構怎麼設計、成本怎麼取捨、出事時怎麼決策。越往架構和設計端走，越不容易被取代。

Q9：應該先學 GCP 還是 AWS？

A： 先選一朵學到會，比兩朵都學一半有用。AWS 在台灣的職缺數量較多，GCP 在資料分析和 Kubernetes 領域強勢、證照考試對非本科相對友善。兩者的核心概念（VM、網路、IAM、容器）有七成相通，學會一朵之後跳到另一朵，通常 1～2 個月能上手。

Q10：從傳統 IT（網管、MIS）轉雲端，要補什麼？

A： 補三塊：容器（Docker 與 Kubernetes）、自動化腳本（Python 或 Shell）、雲端平台的權限與網路模型（IAM、VPC）。網管和 MIS 的網路與系統底子在雲端仍然通用，這是你的優勢，缺的多半是「把手動流程變成程式碼」這個習慣。

結論：先搞懂差別，再選對入門的位置

雲端職缺拆開來就是 5 種角色：工程師蓋、架構師設計、SRE 顧穩定、DevOps 顧交付、資料工程師鋪資料水管。

對想轉職的人來說，最務實的路線是：從雲端工程師入門卡位，再依興趣和底子往架構師、SRE／DevOps 或資料工程師發展。

別被職稱嚇到，也別被職稱綁死——看清楚 JD、選定一朵雲、考一張證照、碰到真實專案，方向就會越來越清楚。

如果你看完還是不確定自己適合哪一條路，我做了一份免費的評估工具，花 3 分鐘就能幫你抓出方向：

👉 你適合轉職 GCP 雲端架構師嗎？3 分鐘職涯評估

想更有系統地從零開始，也可以看看我的 雲端架構師養成班，或直接加 Line: @754xlakm 跟我聊聊你的背景，我幫你看適合先從哪個職缺、哪張證照下手。

The post 雲端職缺大解析：雲端工程師、架構師、SRE、DevOps、資料工程師差在哪？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

它比虛擬機輕量、啟動快，是現代雲端開發的核心基礎。

只要你理解它的概念，Docker、Kubernetes 這些詞就不會再讓你頭痛。

容器技術的定義

一種「把應用程式和它需要的所有東西打包在一起」的技術，確保程式在任何環境都能穩定執行。

這個「所有東西」包含：

1. 程式碼本身
2. 執行環境 (不同程式需要的環境都不一樣)
3. 相依套件 (像是函式庫 Library 或模組，沒有裝就不能順利跑起來，像 python 要處理資料就要再裝 pandas)
4. 容器設定檔 (Dockerfile)

打包完之後，這個容器可以在任何支援容器的機器上執行。

不管你的作業系統是 Ubuntu、CentOS 還是 Windows Server，甚至在你的 Mac 電腦，只要先裝好 Docker，同一個容器都可以順利跑起來。

容器和「貨櫃」的關係：生活化比喻

容器的英文是 Container，這個字本來就是「貨櫃」的意思。

以前船運貨物，每次都要重新裝箱、綁繩、確認尺寸，而每艘船、每個港口規格不同，搬運過程很容易出錯。

貨櫃標準化之後，不管是船運、火車還是卡車，同一個貨櫃直接搬上去就能走，裡面的東西不需要重新整理。

容器技術做的事情一模一樣：把你的應用程式裝進一個標準化的「盒子」，這個盒子搬到哪裡都能直接執行。

容器技術解決了什麼問題？

在它出現之前，工程師最常遇到這個情境：

開發環境裝的是 Python 3.8，測試環境是 Python 3.6，上線環境是 Python 3.11。

程式在開發機跑得好好的，一到正式環境就報錯，花兩天找問題，最後發現程式根本沒寫錯，而是套件版本不對。

容器從根本解決這個問題：開發、測試、上線用的是同一個容器映像檔，環境完全一致，不會出現版本差異。

容器技術的運作原理

容器是怎麼隔離環境的？

容器使用 Linux 核心內建的兩個機制來做隔離：

1. Namespace：讓每個容器有自己的「視角」，容器 A 看不到容器 B 的處理程序、網路介面、檔案系統。
2. Cgroups（Control Groups）：限制每個容器能用多少 CPU、記憶體、磁碟 I/O，避免一個容器把整台機器的資源吃光。

這兩個機制讓多個容器可以同時在同一台機器上執行，彼此不干擾，也不互搶資源。

如果你是初學者來，不需要記住 Namespace 和 Cgroups 的細節。

只要記住一件事：容器的隔離是靠作業系統核心直接支援的，不是靠模擬出另一台電腦。這就是容器比虛擬機輕量的根本原因。

為什麼容器可以這麼輕量？

虛擬機要模擬一整台電腦，包含硬體層、作業系統、核心。

光是一個虛擬機就要佔用 10–20 GB 的空間，啟動需要 30 秒到幾分鐘，所以開機才這麼慢。

容器不模擬硬體，也不需要自己的作業系統核心，直接借用宿主機（Host）的 Linux 核心。

一個容器映像檔大約只有 100–200 MB，啟動時間在 1–3 秒以內。

這個差異在大規模部署時非常明顯：一台實體機器可能只能跑 10–20 個虛擬機，但可以輕鬆跑超過 100 個容器。

容器映像檔（Image）是什麼？

容器映像檔（Image）是容器的「範本」，是一個唯讀的打包檔案，裡面包含程式碼和所有執行環境，用來啟動容器實例。

「實例」這個名詞有點難解釋，你可以理解爲一臺虛擬的小電腦，隨時可以產生出來或刪除掉。

你可以把 Image 想成「食譜」，容器是「用這份食譜做出來的菜」。

同一份食譜可以做出很多份菜，同一個 Image 可以啟動很多個容器實例，彼此獨立、互不影響。

你也可以把 Image 想成遊戲光碟片，那容器就是光碟片開始轉，裡面的遊戲檔被讀出來執行的樣子。

Image 採用分層結構：

1. 底層是作業系統基礎（例如 Ubuntu slim）
2. 上面一層是語言環境（例如 Node.js 18）
3. 最上面才是你的應用程式

如果你第一次打包映像檔，它會先上網下載作業系統環境的相關檔案；然後第二層再下載你的程式語言所需要的環境檔案，以及一些相依性的套件。

由於它每一層都可以快取 (暫存在你電腦裡面)，如果你的程式碼有改，更新容器只需要重新打包有變動的那層，不用再下載作業系統跟程式語言環境，效率很高。

容器 vs 虛擬機：哪裡不一樣？

容器（Container）和虛擬機（Virtual Machine，VM）都是用來隔離執行環境的技術，但架構完全不同：

容器共用宿主機的 OS 核心，虛擬機則模擬出一整台獨立的電腦。這個差異直接決定了兩者在速度、體積和資源消耗上的巨大差距。

架構差異一次看懂

啟動速度與資源佔用的比較

容器啟動快，不是因為硬體更好，而是架構不同。

虛擬機每次啟動的流程：

1. 初始化虛擬硬體
2. 載入 BIOS
3. 啟動 OS 核心
4. 載入系統服務
5. 才能執行你的程式

容器啟動的流程：

1. 在宿主機核心上建立隔離空間
2. 載入映像檔
3. 執行程式

跳過了模擬硬體和啟動 OS 這兩個最耗時的步驟，所以快。

在資源佔用方面：一台 8 GB RAM 的伺服器，跑虛擬機時每個 VM 至少需要 1–2 GB RAM 給 OS 本身；

跑容器時 OS 的 RAM 消耗幾乎為零，幾乎所有記憶體都給應用程式用。

什麼情況該用容器？什麼情況該用虛擬機？

適合容器的情況：

1. 微服務架構，需要大量部署小型服務
2. CI/CD 流程，需要快速啟動、測試、銷毀環境
3. 開發環境一致性，多人協作的專案
4. 雲端部署，需要彈性擴充和縮減的應用程式

適合虛擬機的情況：

1. 需要完整 OS 隔離（例如執行不信任的第三方程式）
2. Windows 應用程式（容器對 Windows 的支援較複雜）
3. 需要模擬不同作業系統進行相容性測試
4. 對安全隔離要求極高的金融或醫療系統

兩者不是非此即彼的關係。

實際生產環境中，常見做法是：虛擬機作為底層基礎設施，容器在虛擬機上運行。

Docker 容器：最主流的容器工具

Docker 是什麼？和容器的關係

容器技術這個概念在 Docker 之前就存在，但當時提供容器技術的廠商非常多，而且操作複雜、工具不統一，只有少數工程師會用。

Docker 是目前最主流的容器工具，由 Docker Inc. 於 2013 年發布。

它讓開發者可以用簡單的指令打包、分發、執行容器，大幅降低容器技術的使用門檻。

並且提供統一的指令介面、映像檔格式，以及 Docker Hub 這個映像檔共享平台。

所以 Docker 幾乎一統江湖，成為容器技術的獨佔廠商。

容器技術是概念，Docker 則是最受歡迎的容器廠商。

現在說「用容器部署」，90% 的情況都是在用 Docker 或基於 Docker 格式的工具。

Docker Hub：映像檔從哪裡來？

Docker Hub 是 Docker 官方的映像檔倉庫（Repository），可以把它想成「容器的 App Store」。

想跑一個 MySQL 資料庫？不需要自己安裝，一行指令就能從 Docker Hub 下載官方的 MySQL 映像檔，直接啟動。

Docker Hub 上有超過 1,000 萬個映像檔，包含：

• 各種語言的執行環境（Python、Node.js、Go）
• 資料庫（MySQL、PostgreSQL、Redis）
• Web 伺服器（Nginx、Apache）

你也可以把自己打包好的映像檔推上去，私有或公開都支援。

用 Docker 跑第一個容器：3 個步驟

假設你已經安裝好 Docker，跑第一個 Docker 容器只需要：

1. 開啟終端機，輸入 docker pull nginx，從 Docker Hub 下載 Nginx 的映像檔
2. 輸入 docker run -d -p 8080:80 nginx，啟動容器並把 8080 port 對應到容器內的 80 port
3. 開啟瀏覽器，前往 http://localhost:8080，看到 Nginx 歡迎頁面就代表成功

從下載到執行，整個過程在 30 秒內完成。你不需要安裝、設定 Nginx，只要這三步就有一個完整運行的 Web 伺服器。這就是 Docker 容器改變開發流程的地方。

Kubernetes 容器編排：容器多了之後怎麼管？

為什麼需要 Kubernetes？

3–5 個容器，Docker 指令就夠用。300 個容器分散在 20 台伺服器上，Docker 指令完全不夠用。你需要解決：

• 某個容器掛掉，要怎麼自動重啟？
• 流量暴增，要怎麼自動增加容器數量？
• 新版本要怎麼在不停機的情況下更新？
• 20 台伺服器的資源要怎麼統一分配？

這些問題就是「容器編排」要解決的事。

Kubernetes（簡稱 K8s）是目前最主流的容器編排平台，由 Google 於 2014 年開源，現在由 CNCF（雲端原生運算基金會）維護，是大規模容器化應用的業界標準。

Kubernetes 和 Docker 的分工

Docker 負責：建立和執行單個容器。

Kubernetes 負責：管理大量容器的生命週期，包含排程、擴縮、自我修復、網路和儲存配置。

兩者是互補關係，不是競爭關係。在大多數生產環境中，Kubernetes 會呼叫容器執行時（Container Runtime）來實際啟動和停止容器，Docker 就是最常見的容器執行時之一。

容器編排解決的三個核心問題

Kubernetes 解決了容器規模化之後最常見的三個痛點：

1. 自我修復（Self-healing）：容器掛掉，Kubernetes 在幾秒內自動重新啟動，不需要人工介入
2. 水平擴展（Horizontal Scaling）：CPU 使用率超過 80% 時，Kubernetes 自動新增容器副本；流量下降後自動縮減，節省成本
3. 滾動更新（Rolling Update）：新版本部署時，Kubernetes 逐步替換舊容器，零停機時間，出問題可以一鍵回滾到上一版

容器技術的實際應用場景

開發環境一致性：再也不會「我電腦上可以跑」

這是最直接、最普遍的應用場景。

10 人的開發團隊，每個人的電腦環境都不一樣：Windows、macOS、不同版本的 Linux，不同版本的 Node.js、Python、資料庫。

用容器技術，把開發環境定義在一個 docker-compose.yml 檔案中。新成員加入團隊，執行一個指令就能啟動和資深工程師完全相同的開發環境，從加入到開始寫程式只需要 15 分鐘，而不是過去光設定環境就要花一整天的「環境設定地獄」。

微服務架構與容器化應用

微服務架構是把一個大型應用程式拆成很多個小型、獨立的服務，每個服務負責一個功能，可以獨立開發、部署、擴展。容器化應用是微服務架構的最佳搭配：每個微服務打包成一個容器，可以用不同的程式語言撰寫、獨立部署、獨立擴展。

舉個例子：一個電商平台有訂單服務、庫存服務、推薦系統、金流服務各自獨立。促銷期間推薦系統需要大量 CPU，你可以只針對推薦系統的容器擴展，不需要把整個平台都擴展，省下大量成本。

CI/CD 流程中的容器角色

CI/CD（持續整合 / 持續交付）是現代軟體開發的標準流程：工程師提交程式碼後，自動執行測試、打包、部署，不需要人工介入。

容器在 CI/CD 流程中扮演關鍵角色：

1. 測試環境用容器啟動，每次測試都在乾淨的環境中執行，不受之前測試殘留的狀態影響
2. 打包成容器映像檔，確保開發、測試、正式環境用完全相同的產物
3. 部署時直接替換容器，速度快、可回滾，比傳統部署方式風險低很多

容器技術的限制與常見誤解

容器不是萬能的：三種不適合用容器的情境

它很強，但不是所有情境都適合：

1. 需要 GUI 的桌面應用程式：容器設計上是無頭（Headless）的，跑有圖形介面的軟體需要額外設定
2. 需要直接存取硬體的應用程式：例如需要存取特定 GPU、USB 裝置，容器的隔離層會增加複雜度
3. 狀態複雜的單體式舊系統（Legacy System）：把有幾十年歷史的大型系統容器化，往往需要大量改寫，成本超過效益

容器技術最適合「雲端原生（Cloud Native）」的應用程式——從設計之初就考慮到分散式部署、無狀態、水平擴展的架構。

容器安全性：常見疑慮與對應做法

容器的隔離比虛擬機弱——這是事實，但不代表容器不安全。

常見的安全疑慮和對應做法：

1. 容器逃逸（Container Escape）：攻擊者從容器內部突破隔離，存取宿主機。
   對應方式：不以 root 身分執行容器、定期更新容器映像檔、使用 Seccomp 和 AppArmor 限制系統呼叫
2. 映像檔安全性：從 Docker Hub 下載的映像檔可能包含漏洞或惡意程式。
   對應方式：只使用官方映像檔或自建基礎映像、在 CI/CD 流程中加入映像檔掃描（例如 Trivy、Snyk）
3. 密鑰管理：不要把密碼、API Key 直接寫進映像檔。
   對應方式：使用 Kubernetes Secret 或 HashiCorp Vault 管理敏感資訊

容器安全是可以管理的問題，只要遵守基本的安全實踐，風險完全在可接受的範圍內。

學容器的建議路徑

從 Docker 開始還是從概念開始？

建議先從概念開始，再動手。

很多人第一步就打開終端機跑 Docker 指令，結果遇到錯誤不知道為什麼，也不知道自己在做什麼，很快就放棄。

理解「容器是什麼、解決什麼問題、和虛擬機有什麼差別」之後，再開始動手，每一個指令都有清楚的脈絡，遇到問題也更容易判斷方向。

推薦的學習順序與資源

從零開始學容器技術，建議依這個順序：

1. 理解概念：搞清楚容器 vs 虛擬機、Image vs 容器的關係（本文就是起點）
2. 安裝 Docker Desktop：官網提供 Windows 和 macOS 的圖形化安裝包，10 分鐘內完成
3. 跑第一個容器：用 docker run hello-world 確認環境正常，再跑 Nginx 或 Python 應用程式
4. 學習 Dockerfile：學會自己撰寫 Dockerfile，把自己的應用程式打包成映像檔
5. 學習 Docker Compose：用 YAML 檔案定義多容器環境，例如「應用程式 + 資料庫」的組合
6. 入門 Kubernetes：理解 Docker 之後再學 K8s，不要跳過 Docker 直接學 K8s

每個階段大約需要 1–2 週，有實作練習的情況下，2–3 個月可以達到在工作中使用容器技術的基本水準。

結語：容器技術值得學嗎？

值得，而且越早學越好。

容器技術已經不是「進階技能」，而是現代後端工程師和 DevOps 工程師的基本配備。

人才需求中出現 Docker、Kubernetes 的頻率，在過去五年內增加了超過三倍。

從理解容器的概念開始，裝好 Docker，跑幾個練習專案，這樣就夠了。Kubernetes 和進階的容器編排，等你對容器有基本掌握之後再學，不會太晚。

容器技術的學習曲線在前兩週最陡，一旦度過那段，後面會越來越順。

常見問題（FAQ）

Q1：容器技術是什麼？用一句話說明。
A：容器技術是一種把應用程式和它的執行環境打包在一起的技術，確保程式在任何機器上都能穩定執行，不受底層作業系統差異影響。
它比虛擬機輕量、啟動更快，是現代雲端部署的核心基礎。
尤其是它在開發、測試、上線環境完全一致，是容器技術解決的最核心問題。

Q2：一個容器可以同時跑多個應用程式嗎？
A：技術上可以，但不建議。容器的設計哲學是「一個容器、一個程序」，這樣才能充分發揮容器的輕量性和獨立性。
如果你需要跑多個應用程式，應該用多個容器，再用 Docker Compose 或 Kubernetes 讓它們協同工作。

Q3：容器和 Serverless 有什麼關係？
A：Serverless（如 AWS Lambda、GCP Cloud Functions）是更高階的抽象，你不需要管理伺服器或容器，只要上傳函數程式碼就好。
但實際上，很多 Serverless 平台的底層就是用容器技術來隔離和執行函數，只是這個細節被平台隱藏起來了。
最有名的就是 Cloud Run，它可以直接讓你的容器跑起來。

Q4：Docker 和 Podman 有什麼差別？
A：Podman 是 Red Hat 推出的容器工具，最大差別是不需要常駐的 Daemon（背景服務），以及預設不需要 root 權限執行，安全性稍高。
指令格式和 Docker 幾乎完全相同，可以直接替換使用。
對初學者來說，先學 Docker 就好，兩者概念完全通用。Podman 知名度低很多。

Q5：容器映像檔更新了，跑起來的容器會自動更新嗎？
A：不會。已經在跑的容器使用的是啟動時的映像檔版本，不會自動套用新映像檔。
你需要停止舊容器、拉取新映像檔、再啟動新容器。
這也是為什麼 Kubernetes 的滾動更新（Rolling Update）功能很重要，它可以幫你自動完成這個過程，而且不停機。

Q6：容器的資料存放在哪裡？容器刪掉資料會不見嗎？
A：預設情況下，容器內部產生的資料在容器刪除後就消失了。這是容器「無狀態」設計的一部分。如果你需要持久保存資料（例如資料庫的資料），要使用 Volume（磁碟掛載），把資料存在宿主機的指定路徑，容器刪除後資料仍然存在。

Q7：學容器技術需要先學 Linux 嗎？
A：不需要精通，但需要基本熟悉。你需要能看懂基本的 Linux 指令（ls、cd、cat、chmod）、了解檔案系統結構，以及知道什麼是 Port 和環境變數。
如果這些概念對你完全陌生，建議先花 1–2 週補一下 Linux 基礎，之後學容器技術會順很多。

Q8：免費使用 Docker 有限制嗎？
A：Docker Desktop（桌面版）對個人使用和小型公司（員工數少於 250 人、年營收低於 1,000 萬美元）免費。超過這個規模需要付費訂閱。
Docker Engine（命令列版本，在 Linux 伺服器上使用）則是完全免費且開源的。Docker Hub 免費帳號有 Image 下載次數限制，付費帳號則無限制。

Q9：GCP、AWS、Azure 上的容器服務有什麼差別？
A：三大雲端平台都提供託管的 Kubernetes 服務：GCP 是 GKE（Google Kubernetes Engine）、AWS 是 EKS（Elastic Kubernetes Service）、Azure 是 AKS（Azure Kubernetes Service）。
三者核心功能相似，差異在於和各自雲端生態系的整合程度。GKE 因為 Kubernetes 本身就是 Google 開發的，整合度和功能被認為是最成熟的。

Q10：公司說要「容器化」現有的系統，這有多難？
A：難度差異很大，取決於現有系統的架構。
如果是相對現代的應用程式（有明確的相依套件清單、設定可以用環境變數注入），架構清晰的應用程式， 1–3 週就能完成基礎版本。
如果是有幾十年歷史的大型單體式系統，深度依賴特定硬體或作業系統功能，容器化可能需要數個月甚至不值得做。
建議先評估系統架構，再決定是否容器化以及容器化的範圍，有可能需要大幅的更動甚至重寫程式碼。

The post 容器 (Container) 技術是什麼？從零開始看懂 Docker 與容器化應用 first appeared on 東東 GCP 教學 - GCP 實戰講師.

這篇文章從「你的系統規模」出發，帶你判斷 Kubernetes 是什麼、解決什麼問題，以及你現在是否真的需要學它。

Kubernetes 是什麼？一句話先說清楚

Kubernetes 是一套容器編排（Container Orchestration）系統，讓你可以用一套統一的方式，管理跑在不同機器上的幾十甚至幾百個容器，包含自動部署、自動重啟、自動擴展、流量路由，全部都能自動化處理。

容器編排的意思是：當你的應用程式被打包成容器之後，你需要有人負責「指揮」這些容器在什麼機器上跑、出問題時怎麼處理、流量大的時候要不要多開幾個。

Kubernetes 就是扮演這個「指揮家」的角色。

K8s 這個縮寫怎麼來的

你在技術文章裡看到「K8s」，指的就是 Kubernetes。

縮寫的由來很簡單：Kubernetes 這個字在 K 和 s 之間剛好有 8 個字母（ubernete），所以工程師直接縮寫成 K8s。

這個命名方式在技術圈很常見，例如 i18n 代表 internationalization（i 和 n 之間有 18 個字母）。

往後你在搜尋資料、看文件的時候，K8s 和 Kubernetes 指的完全是同一件事，可以互換使用。

Kubernetes 和 Docker 的差別：不是競爭，是合作

這是新手最常搞混的一個問題。

Docker 是用來「建立和執行單一容器」的工具。你用 Dockerfile 定義應用程式環境，用 docker run 把容器跑起來，就這樣。

PS. 容器 (Container) 是一種技術，而在這個技術上出現非常多「廠商」，Docker 是巿佔率最高的一家，因為巿佔率太高了，所以大家很容易把 Docker 等同於 Container。

Kubernetes 則是用來「管理一大群容器」的平台。它自己不負責建立容器，而是依賴 Docker（或其他容器執行環境）把容器跑起來，然後在上面做調度、監控、擴展。

換句話說：Docker 是廚師，負責做出一道菜；Kubernetes 是餐廳的排班系統，負責決定今天要幾個廚師上班、哪個廚師負責哪個爐台、某個廚師請假時要怎麼補位。

兩者分工不同，實際上是一起搭配運作的。

沒有 Kubernetes 之前，工程師怎麼管容器？

單一容器的時代：在虛擬機上跑

當你的應用程式只有一個服務，例如一個 API 或一個網站，你根本不需要 Kubernetes，你可以直接在原有的虛擬機器上跑。

因為環境很單純，容器就像一個更小的虛擬器，可以直接 SSH 連進去做各種管理工作。

而在 GCP 上，Cloud Run 就能幫你把單一容器跑起來，自動處理 HTTPS、自動擴展、用多少付多少，設定時間不超過 10 分鐘。

這個階段引入 Kubernetes 反而是過度工程，徒增複雜度。很多團隊在這個階段就已經運作得很好，完全不需要 K8s。

系統變複雜之後，手動管理的三個痛點

當系統從 1 個服務成長到 5 個、10 個服務之後，手動管理容器會出現三個具體問題：

1. 故障處理靠人工：某個容器因為記憶體不足崩潰，你必須自己登入伺服器、手動重啟。如果是凌晨三點發生，就要凌晨三點爬起來。
2. 流量暴增應變慢：當某個服務突然湧入大量流量，你要手動判斷要多開幾個容器實例、在哪台機器上開、開完之後流量要怎麼導過去，每一步都是手動作業。
3. 服務間通訊難維護：A 服務要找 B 服務，B 服務的 IP 在容器重啟後會改變，你要手動更新設定檔。這個問題在服務數量超過 5 個之後會變得非常頻繁。

這三個痛點，就是 Kubernetes 出現要解決的核心問題。

Kubernetes 解決了什麼問題？

自動重啟：容器掛掉不用半夜爬起來

Kubernetes 持續監控每一個容器的健康狀態。

當某個容器因為程式錯誤、記憶體溢出或其他原因停止回應時，Kubernetes 會在 30 秒內自動偵測到異常，並在同一台或另一台節點上重新啟動一個新的容器來替代它。

整個過程不需要人工介入。對使用者來說，服務中斷的時間可以壓縮到幾秒鐘以內，而不是「等工程師醒來處理」的幾十分鐘。

自動擴展：流量暴增時不用手動加機器

Kubernetes 的 Horizontal Pod Autoscaler（水平自動擴展，簡稱 HPA）是一套根據指標自動調整容器執行數量的機制，可以根據 CPU 使用率或自定義指標，自動增加或減少容器的執行數量。

例如你設定「當 CPU 使用率超過 70% 時，自動增加容器數量」，Kubernetes 就會在流量高峰時自動擴展，在流量退去後自動縮減。

這個功能讓你不需要在流量高峰前手動預估資源、提前擴容，也不用擔心流量退潮後忘記縮容浪費費用。

服務發現：多個服務之間怎麼找到彼此

在傳統部署方式下，服務 A 要連線到服務 B，需要知道服務 B 的 IP 位址。

但容器每次重啟後 IP 都會改變，這讓服務間的連線設定變成一場惡夢。

Kubernetes 用「Service」物件解決了這個問題。每個服務都有一個固定的 DNS 名稱，例如 user-service.default.svc.cluster.local，不管後面的容器 IP 怎麼變，這個 DNS 名稱永遠有效。

服務 A 只要用這個名稱呼叫服務 B，Kubernetes 自動幫你把請求導到正確的容器上。

你需要 Kubernetes 嗎？用系統規模來判斷

情境一：單一服務、流量穩定 → 不需要

如果你的系統只有 1 到 3 個獨立服務，彼此之間沒有複雜的依賴關係，流量也相對穩定，引入 Kubernetes 只會讓你多花時間在維護基礎設施，而不是開發功能。

這個階段最適合的工具是 Cloud Run（GCP）、App Engine，或者是最單純的 Compute Engine VM。

設定快、成本低、出問題好追蹤。

情境二：多個服務互相依賴 → 開始考慮

當你的系統開始出現微服務架構，例如前端、後端 API、資料處理服務、通知服務各自獨立部署，服務之間的相依關係會讓你管理越來越繁雜。

手動管理的痛點開始產生：服務上線順序要協調、某個服務掛掉其他服務跟著受影響、部署新版本要小心翼翼，因為牽一髮而動全身。

這是開始評估要不要用 Kubernetes 的時機。

情境三：需要高可用、自動擴展 → 強烈建議

如果你的系統有以下任何一個需求，Kubernetes 幾乎是必選項：

1. 服務不能中斷超過 1 分鐘（高可用需求）
2. 流量有明顯的尖峰與離峰（需要彈性擴縮）
3. 需要零停機時間的滾動更新部署
4. 有超過 10 個以上的微服務需要統一管理

判斷要不要導入 K8s 的 3 個問題

在決定要不要導入 Kubernetes 之前，先問自己這 3 個問題：

1. 我的系統有幾個獨立部署的服務？ 少於 5 個，先考慮更簡單的方案。
2. 我的團隊有沒有人願意負責維護 K8s 叢集？ 沒有專人維護，建議直接選 GKE Autopilot 或其他代管服務。
3. 我現在的痛點是什麼？ 如果痛點不是「容器管理太複雜」，Kubernetes 不是解答。

Kubernetes 的核心概念：看懂這 5 個詞就夠了

學 Kubernetes 不需要一次搞懂所有東西。

以下 5 個核心物件是你一定會碰到的，先建立基本印象就夠了。

Pod：容器的最小包裝單位

Pod 是 Kubernetes 中最小的部署單位，一個 Pod 裡面通常包含 1 個容器，但在特殊情況下也可以包含 2 到 3 個緊密相關的容器，它們共享同一個網路和儲存空間。

你可以把 Pod 想成是一個「容器的宿舍」——裡面住的是你的應用程式容器，宿舍本身負責提供網路連線和磁碟空間。

Pod 的生命週期很短，隨時可能被建立或銷毀，所以不要把重要資料直接存在 Pod 裡面。

Node：跑 Pod 的工作機器

Node 是 Kubernetes 叢集裡的工作節點，也就是實際跑 Pod 的機器。

Node 可以是實體伺服器，也可以是雲端上的虛擬機器（在 GKE 上就是 Compute Engine VM）。

一個 Kubernetes 叢集裡會有多個 Node，Kubernetes 的調度器會自動決定每個 Pod 要跑在哪個 Node 上，確保資源使用均衡。

Deployment：告訴 K8s「我要幾個副本」

Deployment 是 Kubernetes 中用來管理應用程式副本數量與更新策略的物件，你告訴它「我要這個應用程式跑幾份」，它就負責維持這個狀態。

例如你設定 replicas: 3，Kubernetes 就會確保永遠有 3 個相同的 Pod 在運行。如果其中一個 Pod 掛掉，Deployment 會立刻建立新的 Pod 來補位，讓總數維持在 3 個。

當你要更新應用程式版本時，Deployment 也會協調滾動更新的過程，讓新舊版本交替上線，不中斷服務。

Service：讓其他人找得到你的 Pod

因為 Pod 的 IP 會隨著重啟而改變，Kubernetes 用 Service 物件提供一個穩定的網路端點。

Service 就像是 Pod 群組的「固定門牌」，不管後面的 Pod 怎麼換，外部呼叫方只要記住這個門牌（DNS 名稱），就永遠能找到正確的 Pod。

Service 同時也做負載平衡，當有 3 個 Pod 在跑同一個服務時，Service 會把流量平均分配給這 3 個 Pod。

Ingress：對外開放的統一入口

Ingress 是 Kubernetes 叢集對外的流量入口物件，負責把外部的 HTTP 和 HTTPS 請求，根據 URL 路徑或網域名稱，路由到叢集內正確的 Service。

舉例來說，當使用者訪問 api.example.com/users 時，Ingress 把請求導向 user-service；訪問 api.example.com/orders 時，導向 order-service。

這樣你只需要一個對外 IP，就能管理多個內部服務的流量入口。

自己架 Kubernetes vs 用雲端代管服務

自己架的成本：光設定環境就要幾天

自己在虛擬機器上架設 Kubernetes（俗稱 self-hosted K8s）需要處理以下步驟：

1. 安裝並設定 Control Plane（Master Node）
2. 設定 Worker Node 並讓它們加入叢集
3. 設定網路插件（CNI Plugin）讓 Pod 之間可以通訊
4. 設定儲存方案（Storage Class）
5. 設定監控、日誌收集、備份機制

從零開始，一個有經驗的工程師要花 2 到 5 天才能把環境架好，更別說後續的版本升級和安全性維護。

這些時間成本，對大多數團隊來說都不划算。

GKE、EKS、AKS 的差別在哪裡

三大雲端平台都有提供代管 Kubernetes 服務：

1. GKE（Google Kubernetes Engine）：Google Cloud 的代管 K8s。因為 Kubernetes 本身就是 Google 開源的，GKE 在相容性和新功能支援上往往最快。
2. EKS（Amazon Elastic Kubernetes Service）：AWS 的代管 K8s，與 AWS 其他服務（IAM、VPC、ALB）整合最深。
3. AKS（Azure Kubernetes Service）：Microsoft Azure 的代管 K8s，與 Azure DevOps 和 Active Directory 整合完善。

三者核心功能差異不大，選擇的關鍵通常是「你已經在用哪家雲」，而不是 K8s 功能本身的差異。

在 GCP 上為什麼推薦 GKE

GKE 有兩個對初學者特別友善的優點。

第一，GKE Autopilot 模式讓你完全不需要管理 Node。你只要定義要跑什麼應用程式，Google 自動幫你配置和維護底層節點，費用也只針對你實際使用的 Pod 資源計算，沒有部署應用程式的時候不收 Node 的費用。

第二，GKE 是 Kubernetes 的發源地，新功能和安全性修補的支援速度在三大雲中最快，官方文件和社群資源也最豐富。

如果你的雲端環境已經在 GCP 上，GKE 是進入 Kubernetes 世界成本最低的起點。

Kubernetes 值不值得學？給不同背景的人的建議

後端工程師：了解概念就夠，不一定要會操作

如果你是後端工程師，工作內容以開發功能為主，你需要的是「看得懂 K8s 設定檔、能和 DevOps 溝通」的程度，不一定需要自己架叢集或寫 YAML 設定。

重點是理解 Pod、Deployment、Service 這幾個核心物件的用途，知道你的程式碼被打包成容器之後，在 K8s 上是怎麼跑起來的。

這個程度大概需要 2 到 3 天的學習時間就能建立起來。

DevOps / 雲端架構師：必學，沒有例外

如果你的職涯目標是 DevOps 工程師或雲端架構師，Kubernetes 是 2024 年之後幾乎所有大型企業的標配基礎設施，不會 K8s 等於少了一張重要的入場券。

你需要學到的程度包含：

1. 能夠自己建立和管理叢集
2. 寫 Kubernetes YAML 設定檔
3. 設定 CI/CD 流水線整合 K8s 部署
4. 處理常見的故障排查

想考 GCP 證照的人：考前要懂的 K8s 核心考點

GCP 的 Associate Cloud Engineer 和 Professional Cloud Architect 兩張證照，都會考到 GKE 和 Kubernetes 相關知識。

考試中高頻出現的考點包含：

1. GKE Standard 和 Autopilot 模式的差異與適用情境
2. Deployment、Service、Ingress 物件的用途
3. kubectl 常用指令（get、apply、delete）
4. GKE 和 Cloud Run 的選擇判斷題

考前不需要實際操作建叢集，但要能看懂題目描述的情境，並判斷哪個 K8s 物件或哪種 GKE 設定最合適。

結語：搞懂 Kubernetes 是什麼之後，下一步去哪？

Kubernetes 是管理容器化系統的標準平台，但它不是每個人都需要的工具。

系統服務數量少於 5 個，先用 Cloud Run。服務開始互相依賴、需要高可用，再評估 GKE。你在 GCP 上，GKE Autopilot 是成本和複雜度最平衡的起點。

搞懂概念之後，下一步建議直接動手：在 GKE 上建立你的第一個 Cluster，部署一個真實的容器應用程式——這篇文章有完整的手把手操作流程，從建 Cluster 到部署 Ingress 全部都有截圖說明。

如果想看實際操作影片，可以參考 YouTube 上的 GKE 教學手把手實作。

常見問題（FAQ）

Q1：Kubernetes 和 Docker Compose 有什麼不同？
A：Docker Compose 是在單台機器上同時啟動多個容器的工具，適合本機開發或小型部署。Kubernetes 是設計給跨多台機器、需要高可用和自動擴展的生產環境使用的容器編排平台。當你的應用程式需要跑在超過 1 台機器上，Docker Compose 就不夠用了，這時候才是 Kubernetes 的用武之地。

Q2：Kubernetes 學起來難嗎？需要多久？
A：入門概念（Pod、Deployment、Service）大約需要 1 週時間可以理解並動手操作。能夠獨立管理生產環境的 K8s 叢集，需要 3 到 6 個月的實際操作經驗。最快的學習方式是直接在 GKE 上操作真實的叢集，而不是只看文件。

Q3：不用 Kubernetes，能不能用其他方式管理多個容器？
A：可以。常見的替代方案包含 Docker Swarm（較簡單，但功能有限）、HashiCorp Nomad（支援非容器工作負載）、或直接用雲端平台的託管服務（GCP 的 Cloud Run、AWS 的 ECS）。當你的規模不需要 Kubernetes 的全部功能時，這些替代方案的維護成本更低。

Q4：Kubernetes 本身是免費的嗎？費用從哪裡來？
A：Kubernetes 開源軟體本身是免費的。費用來自於執行叢集所需的基礎設施：你需要付費給雲端平台使用的虛擬機器（Node）、儲存空間和網路流量。GKE 在 Autopilot 模式下另外收取叢集管理費，但在 Standard 模式下每個帳號有 1 個免費的區域性叢集。

Q5：Kubernetes 適合個人專案或小型新創嗎？
A：在 95% 的情況下，個人專案和小型新創（團隊少於 5 人、服務數量少於 5 個）使用 Kubernetes 是過度工程。Cloud Run 或類似的 serverless 容器服務，在這個規模下成本更低、維護更簡單。等到服務複雜度真的撐不住了，再遷移到 Kubernetes 也不遲。

Q6：什麼是 Helm？學 Kubernetes 一定要學 Helm 嗎？
A：Helm 是 Kubernetes 的套件管理工具，讓你可以用「Helm Chart」的格式打包和部署應用程式，類似 npm 之於 Node.js。對初學者來說，先學會基本的 kubectl 操作和 YAML 設定之後，再學 Helm 比較合理。Helm 不是必學，但在實際工作環境中使用率極高。

Q7：Kubernetes 和 Service Mesh（如 Istio）是什麼關係？
A：Service Mesh 是建立在 Kubernetes 上的進階網路管理層，提供服務間流量的加密（mTLS）、詳細的流量觀測、流量控制（金絲雀部署）等功能。Istio 是目前最主流的 Service Mesh 實作之一。你需要先學會 Kubernetes，才有辦法理解 Service Mesh 解決的是什麼層次的問題。

Q8：GKE 和 Cloud Run 怎麼選？
A：Cloud Run 最適合無狀態的 HTTP 服務，設定簡單、自動擴展到零、按請求計費。GKE 適合有複雜部署需求、多個相互依賴的服務、或需要自定義網路和儲存設定的情況。判斷關鍵在於：你的應用程式是否有狀態（Stateful），以及你需不需要精細控制 Kubernetes 的部署設定。

Q9：Kubernetes 的 YAML 設定檔看起來很複雜，有沒有簡化的方法？
A：有 3 個方向可以降低 YAML 的複雜度。第一，使用 Helm Chart 把常用設定打包成模板；第二，使用 Kustomize 做環境差異的設定管理（開發環境和生產環境共用同一份基礎設定）；第三，在 GKE 上使用 Google Cloud Console 的圖形介面建立基本物件，再從介面上匯出對應的 YAML 來學習格式。

Q10：Kubernetes 版本更新很快，學了會不會很快過時？
A：Kubernetes 核心概念（Pod、Deployment、Service、Ingress）從 1.0 版本至今幾乎沒有根本性的改變，這些概念不會過時。版本更新主要是功能新增、效能改善和安全性修補，不會讓你原本學的知識失效。建議追蹤每個版本的 Changelog 了解新增功能，但不需要因為版本更新而重新學習基礎。

The post Kubernetes 是什麼？白話解釋 + 判斷你是否真的需要它 first appeared on 東東 GCP 教學 - GCP 實戰講師.

轉職 IT 前，你需要先搞清楚一件事

很多人說「我想轉職 IT」，但還沒想清楚自己想做哪一種 IT。

這不是在挑剔你，而是因為 IT 產業太大了，大到「轉職 IT」這四個字，幾乎沒辦法直接告訴你該學什麼。

「IT」不是一個職業，是一個產業

IT 是 Information Technology 的縮寫，中文是「資訊科技」，指的是所有與電腦、網路、資料處理相關的技術領域。

它不是一個職位，而是涵蓋超過 20 種不同專業的產業。

網路工程師、系統管理員、資料庫管理員、雲端架構師、資安工程師、DevOps 工程師……等，這些都叫 IT，但工作內容差距非常大。

舉個例子：網路工程師每天在設定路由器和防火牆規則；雲端工程師每天在 GCP 或 AWS 上建立基礎設施；資安工程師每天在分析系統漏洞和攻擊日誌。

三個人都叫 IT，但幾乎不會有工作上的交集。

所以，轉職 IT 的第一步不是「學技術」，而是「選方向」。

轉職 IT 最常見的三條路徑

新手最容易上手的 IT 路徑有三條，各有不同的技能要求和薪資天花板。

路徑一：系統管理／IT 維運（SysAdmin / IT Ops）

負責公司內部的電腦、伺服器、帳號、網路設備的日常管理與維護。

這是 IT 新手最容易切入的路徑，因為許多中小企業都需要這類人才，對學歷和程式能力的要求相對較低。

入門建議先取得 Microsoft 相關認證，例如 MSCA (初級)、MCSE (進階) 等等。

薪資範圍（台灣）：月薪 30,000–50,000 元為常見起點，資深後可達 60,000 元以上。

路徑二：網路工程師（Network Engineer）

負責設計、建置、維護企業的網路架構，包含路由器、交換器、防火牆、VPN 等設備。

這條路技術門檻較高，需要紮實的網路知識。

建議以 Cisco CCNA 作為入門認證目標。

薪資範圍（台灣）：月薪 40,000–70,000 元，CCIE 等高階認證持有者可達 10 萬以上。

路徑三：雲端工程師（Cloud Engineer）

負責在 GCP、AWS 或 Azure 等雲端平台上建置和管理基礎設施，是目前市場需求成長最快的 IT 職位之一。

這條路需要先有一定的 IT 基礎知識，再疊加雲端平台的操作能力。

本文後半會詳細說明為什麼這條路值得優先考慮。

薪資範圍（台灣）：月薪 50,000–90,000 元，資深雲端架構師突破 12 萬並不罕見。

轉職 IT 必懂的基礎概念：網路知識

不管你選哪條 IT 路徑，網路知識都是必備的地基。

就像蓋房子一定要先打地基，IT 的所有技術：伺服器、雲端、資安、虛擬化……等等，都建立在網路之上。

跳過網路直接學雲端，就像跳過地基直接蓋牆，遲早會垮。

IP 位址、DNS、HTTP 是什麼？

這三個是網路世界最基礎的概念，新手一定要先搞清楚。

IP 位址是網路上每台裝置的「地址」。就像你家的門牌號碼，IP 位址讓資料知道要送到哪裡。常見格式是 192.168.1.1（IPv4），新版格式是 IPv6（IPv6 到 2026 年都還不常用，很多設備都不支援，聽過就好）。

DNS（Domain Name System）是「網路的電話簿」，負責將人類看得懂的網域名稱（如 google.com）翻譯成機器看得懂的 IP 位址（如 142.250.185.46）。沒有 DNS，你就得背一堆 IP 位址才能上網，而且伺服器的 IP 會一直變來變去，所以才需要 DNS 幫你記。

HTTP（HyperText Transfer Protocol）是瀏覽器和伺服器之間溝通的語言。你點一個連結，瀏覽器用 HTTP 向伺服器說「我要這個頁面」，伺服器用 HTTP 把頁面傳回來。HTTPS 是加密版本 (S 是 Secure 的意思)，現在幾乎所有網站都用 HTTPS。

防火牆和 VPN 的基本概念

防火牆是網路的守門員，根據設定好的規則決定哪些流量可以進來、哪些要擋掉。

企業防火牆可以設定「只允許特定 IP 存取內部系統」，或者「封鎖所有來自某個國家的連線」。

VPN（Virtual Private Network）是「加密的網路隧道」，雖然我們的封包大部分已經是用 HTTPS 協定在網路上傳送，但有心的駭客還是會想辦法破解，而 VPN 是讓你的網路流量再加密一次，雖然駭客能夠攔截到我們傳送的封包，但要破解內容的難度更高。

企業常用 VPN 讓遠端工作的員工安全連回公司內網。員工安裝客戶端 VPN 軟體，連到公司的 VPN 伺服器，這叫做 Client to Site VPN 模式。

PS. 而你的手機透過 VPN APP 到其他國家看劇，則是連到國外的 VPN 伺服器，所以也是 Client to Site VPN。

另一種情況是，企業的內部網路要跟雲端環境以安全的方式通訊，也會使用 VPN，是由公司的 VPN 設備跟雲端 VPN 對接，員工不用裝 VPN 軟體，這叫做 Site to Site VPN 模式。

為什麼網路知識是 IT 的地基？

因為現代 IT 基礎設施的每一個元件，都需要透過網路溝通。

伺服器需要網路才能對外提供服務。雲端平台需要網路才能讓使用者存取資源。容器化應用需要網路設定才能互相溝通。資安防護需要分析網路流量才能發現攻擊。

如果你不懂網路，就沒辦法理解系統為什麼連不上、為什麼速度慢、為什麼被攻擊。

這就是為什麼幾乎所有 IT 認證（包含雲端認證）都會考網路基礎知識。

轉職 IT 必懂的基礎概念：作業系統

作業系統（Operating System，OS）是管理電腦硬體資源、讓應用程式可以運行的核心軟體，是 IT 人員每天工作的主戰場。

設定服務、管理帳號、排查問題，全都在作業系統層面進行。

Windows Server vs Linux：新手該學哪個？

這是轉職 IT 新手最常問的問題之一，答案取決於你想走的路徑。

Windows Server 在台灣的中小企業環境非常普遍，尤其是需要和 Microsoft 365、Active Directory 整合的公司。如果你的目標是 SysAdmin 或 IT 維運，Windows Server 是優先學習的選項。

Linux 在伺服器、雲端、開發環境中佔主導地位。根據 W3Techs 的統計，全球超過 61% 的網站伺服器運行在 Linux 上，廣義的 Unix 還高達 91%。如果你的目標是雲端工程師、DevOps 或後端開發，Linux 是必學項目，而 Windows …… 則是 8.3%。

尤其在 Google Cloud Platform (簡稱 GCP) 上，超過 90% 的虛擬機器都是 Linux。

建議新手的策略：先學 Windows Server 建立基礎信心，同時開始接觸 Linux 指令列操作。兩個都懂的人，在職場上的競爭力會高出許多。

指令列操作（CLI）為什麼不能跳過？

CLI（Command Line Interface）就是那個黑色視窗——你用鍵盤打指令來操作電腦，而不是用滑鼠點圖示。

很多新手看到 CLI 就想跳過，覺得「現在不是都有圖形介面了嗎」。

這個想法在 IT 職場行不通，原因有 3 個：

1. 伺服器環境幾乎不安裝圖形介面，因為圖形介面會消耗額外資源。
2. 自動化腳本（Shell Script、PowerShell）需要透過 CLI 執行。
3. 雲端平台的進階操作幾乎都透過 CLI 工具（就是下指令的意思，如 gcloud、aws cli）完成。

建議新手從 Linux 的基礎指令開始：ls、cd、mkdir、chmod、grep、ssh。這些指令學會之後，你會發現很多 IT 操作快很多。

常見作業系統概念：權限、程序、服務

這三個概念在 IT 日常工作中出現頻率極高，新手要先建立基本認識。

權限（Permissions）：決定「誰可以對這個檔案或資源做什麼」。Linux 用 rwx（讀/寫/執行）表示，Windows 用 ACL（存取控制清單）管理。IT 工作中有大量問題是「權限設定錯誤」造成的。

程序（Process）：正在執行中的程式。每個應用程式運行時都是一個程序，IT 人員需要知道如何查看程序狀態、終止異常程序、分析程序資源使用情況。

服務（Service）：在背景持續運行的程序，通常隨系統啟動自動執行。網頁伺服器（Apache、Nginx）、資料庫（MySQL）、DNS 伺服器都是以服務形式運行。IT 人員需要知道如何啟動、停止、重啟服務。

轉職 IT 必懂的基礎概念：虛擬化與容器

虛擬化和容器技術是現代 IT 基礎設施的核心，也是理解雲端技術的關鍵橋樑。

學完網路和作業系統之後，這是轉職 IT 的第三個必懂基礎。

虛擬機器（VM）是什麼？

虛擬機器（Virtual Machine，VM）是用軟體模擬出來的電腦，讓一台實體伺服器能同時運行多個獨立的作業系統環境。

想像你的實體伺服器是一棟大樓，虛擬機器就是大樓裡的一間間獨立套房。每間套房有自己的空間（CPU、記憶體、儲存空間），互不干擾，但共用同一棟大樓的基礎設施（實體硬體）。

透過虛擬化技術，一台實體伺服器可以同時運行 10 台、20 台甚至更多的虛擬機器，大幅提升硬體使用效率。

這也是雲端服務能夠快速提供「一台伺服器」給用戶的技術基礎。

常見的虛擬化平台包含 VMware vSphere、Microsoft Hyper-V，以及雲端平台上的 GCP Compute Engine、AWS EC2。

Docker 和容器技術的基本觀念

容器（Container）是比虛擬機器更輕量的應用程式打包方式，讓應用程式連同它所需的環境一起打包，在任何地方執行結果都一樣。

用同一個大樓比喻：如果虛擬機器是獨立套房（有自己的廚房、浴室），容器就像是共用廚房和浴室的雅房——更省空間，但也能保持一定程度的獨立性。

Docker 是目前最主流的容器平台。

它讓你可以把應用程式和它需要的所有依賴（函式庫、設定、環境）打包成一個「容器映像檔」，在任何支援 Docker 的環境上執行，結果都一樣。

這解決了 IT 工作中最讓人頭痛的問題之一：「在我電腦上可以跑，到伺服器上就壞了。」

PS. 很多人會把 Docker 和 Container 混在一起，簡單的區分方式，Container 是一種技術，而在這個技術上出現非常多「廠商」，Docker 是巿佔率最高的一家，因為巿佔率太高了，所以大家很容易把 Docker 等同於 Container。

虛擬化技術和雲端技術的關係

雲端技術的底層，就是大規模的虛擬化基礎設施。之所以叫大規模，是因為 Amazon、Azure 和 GCP 在全世界蓋了資料中心，也就是「超級無敵大的機房」。

每個資料中心都有數十萬甚至百萬台硬體伺服器在運作，然後分租給全世界的使用者。

當你在 GCP 開一台 Compute Engine 虛擬機，你實際上是在 Google 的實體資料中心裡，分配到一個虛擬化的運算資源。

當你在 AWS 執行一個 Lambda 函數，你的程式碼是在一個高度優化的容器環境中運行。

理解虛擬化和容器的概念，會讓你在學習雲端技術時快很多——因為你已經知道「這些資源在底層是怎麼運作的」。

IT 新手也要懂的開發基礎概念

你不需要變成軟體工程師，但以下幾個開發基礎概念，會讓你在轉職 IT 之後溝通更順暢、解決問題更有效率。

很多人以為 IT 維運和開發完全無關，但現代 IT 環境中，這條界線已經越來越模糊。

寫程式是什麼？IT 一定要會寫 code 嗎？

程式是給電腦看的「操作指令集合」。你寫下一連串指令，電腦按照順序執行，完成你想要的任務。

IT 人員不一定要會寫複雜的應用程式，但以下 3 種程式能力在 IT 工作中非常實用：

1. Shell Script（Bash）：自動化 Linux 系統操作，例如每天自動備份、批次新增帳號。
2. PowerShell：Windows 環境的自動化腳本，SysAdmin 的必備工具。
3. Python 基礎：處理資料、呼叫 API、寫簡單的自動化工具，雲端和 DevOps 工作中非常常用。

建議新手從 Shell Script 或 Python 入門，能寫出「讓電腦幫我做重複工作」的腳本，就達到 IT 工作需要的基本門檻。

網站是怎麼運作的？網頁伺服器的角色

每次你在瀏覽器輸入一個網址，背後發生了以下流程：

1. 瀏覽器透過 DNS 查詢，找到這個網址對應的伺服器 IP。
2. 瀏覽器用 HTTP/HTTPS 向伺服器發送「請給我這個頁面」的請求。
3. 伺服器上的網頁伺服器軟體（如 Nginx 或 Apache）接收請求，找到對應的資源。
4. 網頁伺服器把頁面內容回傳給瀏覽器，瀏覽器顯示出來。

網頁伺服器（Web Server）是負責接收 HTTP 請求、回傳網頁內容的軟體。Nginx 和 Apache 是最常見的兩種，在雲端環境中也經常以容器形式部署。

IT 人員不需要會設計網站，但需要知道如何安裝、設定、管理網頁伺服器，以及如何排查「網站連不上」這類問題。

前端和後端的差別是什麼？

這兩個詞在 IT 工作中非常常見，新手要先建立基本認識。

前端（Frontend）

是使用者直接看到、互動的部分，以 HTML、CSS、JavaScript 為核心技術。網頁的版面、按鈕、動畫、表單都屬於前端範疇。

後端（Backend）

是使用者看不到、但在背景運作的部分，負責處理商業邏輯、資料存取、API 溝通。後端技術包含 Python、Node.js、Java、Go 等程式語言。

IT 維運人員雖然不需要親自開發前後端，但理解這個架構有 2 個實際好處：

1. 當應用程式出問題時，你能判斷「問題是在前端、後端還是基礎設施層」。
2. 和開發團隊溝通時，你能聽懂他們在說什麼，合作效率會高很多。

資料庫是什麼？IT 人員需要懂到什麼程度？

資料庫（Database）是儲存和管理結構化資料的系統，幾乎所有應用程式都依賴它運作。

電商網站的商品資料、使用者帳號、訂單記錄；企業的員工資料、財務數據；社群平台的貼文和互動——這些全都存在資料庫裡。

常見的資料庫分 2 大類：

關聯式資料庫（SQL）：以表格形式儲存資料，資料之間有明確的關聯。代表工具：MySQL、PostgreSQL、Microsoft SQL Server。這類資料庫在企業環境中非常普遍。

非關聯式資料庫（NoSQL）：以更彈性的格式（文件、鍵值、圖形等）儲存資料，適合大量、多樣化的資料。代表工具：MongoDB、Redis、Google Firestore。

IT 人員至少要能讀懂基本的 SQL 查詢（SELECT、WHERE、JOIN），知道如何備份和還原資料庫，以及了解資料庫的基本權限管理。進階的資料庫調效和架構設計，通常是資料庫管理員（DBA）的專責工作。

轉職 IT 的學習路徑建議

有了以上的知識地圖，最重要的問題來了：照什麼順序學？

很多新手的問題不是「不想學」，而是「不知道先學哪個」，結果每個都學一點、每個都沒學完，半年後還是在原地踏步。

以下是一個實際可行的三階段學習路徑。

第一階段：打好地基（0–3 個月）

這個階段的目標只有一個：建立基礎概念，不求深入，求「聽得懂」。

學習內容：

1. 網路基礎：IP、DNS、HTTP、防火牆、路由
2. 作業系統基礎：Windows 基本操作 + Linux 入門指令（推薦：鳥哥的 Linux 私房菜）
3. 虛擬化入門：在自己電腦上安裝 VirtualBox (免費的)，建立一台 Linux 虛擬機練習
4. 開發基礎概念：了解前後端架構、資料庫基本概念（不需要動手寫 code）

這個階段不建議報名付費課程，先用免費資源確認自己有興趣再說。

第二階段：選定方向，取得入門認證（3–6 個月）

這個階段要做 2 件事：選定職涯路徑，以及取得一張能證明基礎能力的認證。

建議的入門認證：

1. Cisco CCNA：網路工程方向的入門認證，考核網路概念、設備操作、故障排查。
2. Google Cloud Digital Leader：雲端方向的非技術入門認證，了解雲端概念和 GCP 服務，難度最低，適合完全沒有雲端背景的新手。(免費學習網站：Google Skills)

取得認證不是目的。它的作用是：給你一個明確的學習目標，以及一個可以放在履歷上的具體成果。

第三階段：上手雲端平台（6 個月後）

完成前兩個階段後，你已經有足夠的基礎知識來學習雲端技術。

這個階段的目標：在 GCP 或 AWS 上動手操作，建立真實的雲端實作經驗。

建議從免費試用帳號開始（GCP 提供 300 美元的免費額度，AWS 提供 12 個月的免費方案），練習建立虛擬機、設定網路、部署簡單的應用程式。

同時，開始準備一張雲端技術認證，例如 Google Cloud Associate Cloud Engineer 或 AWS Solutions Architect Associate。這兩張認證在台灣的雲端工程師職缺中認可度很高。

為什麼現代 IT 轉職者都要學雲端技術？

如果你問現在的 IT 主管「新人最需要補強哪個技能」，超過 6 成的人會回答：雲端。

這不是趨勢，這是現況。

雲端技術已成為 IT 職缺的標準要求

打開 104 或 LinkedIn，搜尋「IT 工程師」或「系統管理員」的職缺，超過 70% 的職缺在「加分條件」或「必備技能」欄位裡，明確寫著 AWS、GCP 或 Azure 的相關經驗。

原因很直接：過去 10 年，企業的 IT 基礎設施從自建機房大規模遷移到雲端。

根據 Gartner 的預測，到 2026 年，全球超過 75% 的企業將採用雲端優先策略。這意味著 IT 人員的日常工作環境，已經從管理實體伺服器，轉變為管理雲端資源。

不懂雲端技術的 IT 人員，正在快速失去競爭力。

GCP、AWS、Azure 三大平台哪個適合新手？

三大平台各有優勢，但對轉職 IT 新手來說，選擇標準只有 2 個：市場需求和學習資源。

AWS（Amazon Web Services）是全球市佔率最高的雲端平台，約佔 33%。職缺數量最多，學習資源最豐富，但服務項目多到讓新手眼花撩亂。

GCP（Google Cloud Platform）是 Google 旗下的雲端平台，市佔率約 11%，在資料工程、機器學習、生成式 AI、Kubernetes 等領域有明顯優勢。介面相對友善，適合有 Google 產品使用習慣的新手。

Azure（Microsoft Azure）市佔率約 22%，在企業環境中非常普遍，尤其是已使用 Microsoft 365 和 Windows Server 的公司。如果你的目標是進入傳統大型企業的 IT 部門，Azure 是很好的選擇。

新手建議：先選一個平台深入學習，不要三個同時學。選定之後，把免費試用額度拿來做實驗，動手操作比看教學影片有效 3 倍。

從 IT 基礎到雲端技術：你已經準備好了

看到這裡，你已經建立了轉職 IT 最重要的知識骨架：

• 網路知識：你知道資料在網路上怎麼流動
• 作業系統：你知道 Linux 和 Windows Server 各自的角色
• 虛擬化與容器：你知道雲端服務的底層邏輯
• 開發基礎：你知道前後端和資料庫在整個系統中的位置

這些知識，正好是學習雲端技術需要的前置條件。

你不需要全部精通，但每個概念都要「聽得懂、說得出來」。

雲端技術不是 IT 的終點，但它是現在最值得投資的方向。從這裡開始，你的轉職 IT 學習路徑會越來越清晰。

常見問題（FAQ）

Q1：轉職 IT 一定要有大學學歷嗎？
A：不需要。台灣中小企業和新創公司更看重實際能力，而非學歷。取得 Google Cloud 等認證，搭配有作品集（Portfolio），可以有效彌補學歷不足，在轉職 IT 面試中取得競爭優勢。

Q2：IT 工作需要會英文嗎？
A：基礎英文閱讀能力是必要的。IT 的技術文件、官方手冊、錯誤訊息幾乎都是英文。不需要流利口說，但能讀懂技術文件的英文閱讀能力是基本門檻。如果完全不懂英文，解決問題的速度會慢很多。

Q3：轉職 IT 需要買什麼設備？
A：入門階段不需要購買昂貴設備。一台能流暢運行虛擬機的電腦（建議 8 GB 記憶體以上）就夠了。雲端平台的免費試用額度可以讓你在不花錢的情況下練習大多數技術。

Q4：IT 工作壓力大嗎？
A：壓力程度因職位而異。系統當機、資安事件、緊急維護確實存在，但不是每天都會發生。建立好的監控和自動化機制，可以大幅降低緊急事件的頻率。

Q5：女生適合轉職 IT 嗎？
A：完全適合。IT 產業的技術工作以能力論英雄，性別不是障礙。台灣的 IT 職場女性比例雖然仍低於男性，但正在逐年成長，特別是在雲端、資料分析、專案管理等方向。

Q6：轉職 IT 之後薪資一定會提升嗎？
A：不保證，但機率很高。根據 104 人力銀行的薪資調查，IT 相關職位的平均薪資高於台灣整體職場平均水準約 20–30%。入門職位薪資可能和目前差不多，但晉升空間和薪資天花板通常更高。

Q7：需要同時學多個雲端平台嗎？
A：不建議同時學多個平台。初期選定 AWS、GCP 或 Azure 其中一個深入學習，取得對應認證後再擴展到其他平台，是轉職 IT 最有效率的雲端學習策略。

Q8：IT 認證有效期限是多久？
A：大多數 IT 認證有 2–3 年的有效期，到期前需要通過繼續教育或重新考試來更新。Google Cloud 和 AWS 的認證有效期為 2–3 年不等。

Q9：可以邊工作邊準備轉職 IT 嗎？
A：可以，而且這是大多數成功轉職者的做法。建議每週至少投入 10–15 小時的學習時間，利用下班後和週末。線上課程和自學資源讓你不需要請假也能系統性學習。

Q10：IT 產業會被 AI 取代嗎？
A：IT 基礎設施管理、雲端架構設計、資安防護等核心工作，在可預見的未來仍然需要人類判斷，尤其是這些工作所需的「軟實力」，包含溝通協調與團隊合作，是 AI 很難取代的。而懂得善用 AI 工具的轉職 IT 人員，生產力和競爭力反而會大幅提升，而非被取代。

The post 轉職 IT 新手必學知識完整指南：從零基礎到雲端技術入門 first appeared on 東東 GCP 教學 - GCP 實戰講師.

路由（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 實戰講師.