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

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

1. 什麼是 GCP Organization Policy？

什麼是 Organization Policy？

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

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

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

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

為什麼 Organization Policy 比 IAM 更重要？

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

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

用比喻來說：

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

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

它是怎麼運作的？

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

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

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

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

inheritFromParent 是什麼？為什麼重要？

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

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

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

具體案例：

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

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

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

List Constraint（清單限制）

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

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

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

Boolean Constraint（布林限制）

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

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

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

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

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

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

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

如何設定？

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

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

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

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

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

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

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

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

怎麼做？

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

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

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

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

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

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

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

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

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

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

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

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

三個 Constraint 快速比較

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

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

CI/CD 場景的最佳實務

在 CI/CD 場景中，建議：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

什麼是 storage.publicAccessPrevention？

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

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

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

什麼是 CMEK？

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

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

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

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

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

正確設定範例：

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

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

什麼時候需要 Resource Location Restriction？

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

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

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

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

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

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

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

排查步驟

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

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

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

compute.skipDefaultNetworkCreation 是什麼？

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

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

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

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

GCP Organization Policy 六大常見陷阱：

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

結論

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

常見問題解答（FAQ）

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

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

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

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

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

bash

gcloud org-policies list --organization=ORGANIZATION_ID

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

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

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

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

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

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

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

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

什麼是 GCP Cloud Armor？

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

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

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

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

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

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

Cloud Armor 主要提供兩層防護。

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

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

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

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

Cloud Armor Standard 和 Managed Protection Plus 的差異

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

Standard（標準版）：

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

Managed Protection Plus（進階版）：

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

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

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

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

答案在於防護層次不同。

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

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

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

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

你為什麼需要 Cloud Armor？

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

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

常見的威脅類型有 6 種：

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

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

Cloud Armor 能防禦的攻擊類型

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

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

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

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

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

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

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

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

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

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

Cloud Armor 只能搭配哪些 Load Balancer？

Global External HTTP(S) Load Balancer

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

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

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

SSL Proxy 和 TCP Proxy Load Balancer

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

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

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

以下 Load Balancer 不支援 GCP Cloud Armor：

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

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

需要的 GCP 權限與 IAM 角色

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

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

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

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

Cloud Armor 的計費方式

Cloud Armor Standard 版的計費方式：

實際費用計算範例：

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

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

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

GCP Cloud Armor 功能完整介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

預設規則（Default Rule）的作用

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

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

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

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

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

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

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

常用的 CEL 函數：

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

地理位置封鎖（Geo-blocking）

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

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

常見使用情境：

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

封鎖多個國家的 CEL 語法：

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

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

IP 白名單與黑名單

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

速率限制（Rate Limiting）功能

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

兩種模式：

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

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

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

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

自適應防護（Adaptive Protection）簡介

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

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

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

GCP Cloud Armor 基礎版操作步驟

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

Step 1：確認你的 Load Balancer 類型

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

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

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

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

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

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

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

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

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

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

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

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

從 Cloud Armor 頁面套用：

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

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

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

Step 5：測試規則是否生效

用 curl 測試封鎖效果

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

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

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

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

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

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

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

在 Cloud Logging 確認攔截紀錄

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

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

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

3. 點擊「Run Query」

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

Cloud Armor 防禦規則範例

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

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

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

規則設定：

• Priority：1000
• 條件（CEL）：

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

• 動作：deny(403)

同時封鎖多個 IP 段：

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

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

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

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

規則設定：

• Priority：2000
• 條件（CEL）：

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

• 動作：deny(403)

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

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

動作：deny(403)

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

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

範例三：防禦 SQL Injection 攻擊

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

規則設定：

• Priority：3000
• 條件（CEL）：

evaluatePreconfiguredExpr('sqli-stable')

• 動作：deny(403)

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

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

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

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

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

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

規則設定：

• Priority：3100
• 條件（CEL）：

evaluatePreconfiguredExpr('xss-stable')

• 動作：deny(403)

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

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

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

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

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

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

規則設定：

• Priority：4000
• 條件（CEL）：

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

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

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

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

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

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

常見問題與錯誤排查

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

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

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

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

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

排查步驟：

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

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

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

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

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

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

Cloud Armor 的完整 Log 欄位說明：

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

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

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

結語：Cloud Armor 值得學嗎？

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

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

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

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

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

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

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

常見問題（FAQ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舉個具體例子：

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

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

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

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

技術棧的 4 大核心層次

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

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

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

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

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

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

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

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

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

資料庫（Database）：資料的家

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

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

• PostgreSQL
• MySQL
• Microsoft SQL Server

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

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

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

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

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

常見技術包含：

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

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

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

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

MEAN Stack：JavaScript 全家桶

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

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

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

LAMP Stack：老牌穩定組合

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

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

JAMstack：現代靜態網站首選

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

常見問題解答（FAQ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

查詢費用的計算方式

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

使用 Dry Run 預估費用

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

操作方式：

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

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

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

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

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

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

Standard、Enterprise 與 Enterprise Plus 比較

Editions 和舊版 Flat Rate 最大的差異

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

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

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

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

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

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

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

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

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

BigQuery 隱藏的「計費邏輯」

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

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

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

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

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

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

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

Commitment 承諾方案的折扣

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

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

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

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

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

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

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

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

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

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

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

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

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

Active Storage vs. Long-term Storage

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

降低儲存成本的策略

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

5. 免費額度（Free Tier）

每個月的免費額度：

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

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

6. 其他潛在費用

資料串流（Streaming Insert）費用

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

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

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

BigQuery ML 計費

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

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

差異原因

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

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

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

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

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

BigQuery BI Engine 費用

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

7. 5 個實用的省錢技巧

7.1 避免 SELECT * 全表掃描

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

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

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

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

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

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

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

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

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

7.4 善用 Materialized Views

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

7.5 定期評估是否切換 Editions

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

8. 如何監控與管理費用

用 Google Cloud Console 查看帳單

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

設定預算與費用警示

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

常見問題（FAQ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 判斷標準只有一個

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

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

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

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

3.1 什麼是 Control Plane？

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

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

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

3.2 Helios 的問題：Toil

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

核心需求：全球一致性。

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

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

背後技術：TrueTime

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

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

4.2 Cloud Bigtable：播放紀錄與 Wrapped 年度回顧

負責的資料： 播放紀錄、歌曲播放次數。

核心需求： Append-heavy（大量新增）的場景。

用戶每播一首歌，就新增一筆紀錄。 幾乎不需要修改或刪除舊紀錄。

這些播放紀錄累積起來，就是每年 Spotify Wrapped 的原料。

設計細節：Key 要先 Hash

直接用用戶 ID 當 Key 會出問題。 熱門用戶的資料會集中在少數幾台機器，那幾台機器撐不住，效能就下降。

Spotify 的解法：先把用戶 ID 打亂（Hash）再當 Key，讓資料均勻分散。

這個細節官方文件裡有寫，很多人跳過，等到系統出問題才回頭翻，改架構的代價很高。

4.3 Cloud Storage + CDN：音訊檔案全球傳輸

負責的資料： 音訊檔案、封面圖片。

音訊檔案不是直接從 Cloud Storage 傳給用戶，中間還有一層 Cloud CDN。

CDN 把熱門歌曲的音訊檔案預先放到離用戶最近的節點。 台北的用戶聽歌，資料從台灣本地節點傳來，不用繞到美國，延遲短、速度快。

沒有 CDN 這層，全球幾億用戶的請求全打到同一個地方，跨洲頻寬費用就會讓帳單失控。

五、BigQuery：資料查詢從幾小時縮為幾分鐘

5.1 從 Hadoop 到 BigQuery

Hadoop 有兩個明顯缺點：

速度慢： 複雜查詢需要幾小時，有時幾天。

維運人力高： 需要專職工程師每天照顧，調整機器、處理卡住的任務、管理版本升級。

換成 BigQuery 之後：

查詢速度： 同複雜度的查詢，從幾小時縮短到幾分鐘。 維運人力： BigQuery 是全代管服務，基礎設施的維護、擴容、備份、升級，Google 全部處理。

5.2 BigQuery 定價：按量計費 vs. 固定容量

按量計費（預設）： 每 TB 約 6.25 美元。適合資料量小的公司。

固定容量計費： 預先購買運算容量，費用可預測。適合資料量大、使用量穩定的公司。

Spotify 這種規模早就改成固定容量計費了。

如果你的 BigQuery 帳單一直在漲，研究一下固定容量選項。 有時候一個計費方式的調整，就能讓帳單砍半。

了解更多 BigQuery 可參考：《BigQuery 是什麼？功能、組成元件、特色和優勢完整介紹》

六、Pub/Sub + Dataflow：事件驅動架構的兩個設計眉角

6.1 At-least-once Delivery：同一則訊息可能送兩次

用戶播一首歌，會觸發一連串反應： 計費系統扣版稅、推薦系統更新喜好模型、播放紀錄系統記錄這次播放。

負責傳遞這些通知的是 Pub/Sub。

Pub/Sub 的特性：At-least-once Delivery（至少送達一次）。

它保證訊息一定送到，但在網路不穩定、接收方沒及時確認的情況下，同一則訊息可能送兩次甚至更多次。

了解 Pub/Sub 更多可參考《Cloud Pub/Sub 教學：比 RabbitMQ 好用，無限擴充的訊息佇列服務》

6.2 冪等性（Idempotency）：計費系統的必要設計

訊息可能重複，計費系統就必須有 冪等性。

「用戶播放 A 歌曲」的通知，就算送來三次，系統只能扣一次版稅、記錄一次播放。

實作方式有兩種：

一、每個事件附加唯一 ID（Event ID），收到訊息前先確認這個 ID 有沒有處理過。 二、把操作設計成「就算重複執行，結果也不變」的形式。

任何依賴事件驅動架構的系統，冪等性不是選配，是必須的。

6.3 Dataflow：推薦演算法的資料來源

Dataflow 把即時的播放記錄和用戶歷史行為合併，做計算和轉換，把結果餵給推薦演算法。

Dataflow 處理的是 串流資料（Streaming Data），也就是即時、持續湧入的資料流。 這讓推薦系統能快速響應用戶的行為，你剛聽完一首歌，推薦結果很快就會反映。

七、VPC 網路架構：一個初期沒注意的限制，代價極高

7.1 VPC Peering 不支援 Transitive Routing

Spotify 的每個工程團隊有獨立的 GCP 專案，用 VPC Peering 讓不同團隊的服務互相通訊。

VPC Peering 有一個關鍵限制：不支援 Transitive Routing（轉傳路由）。

A 網路和 B 網路打通了、B 網路和 C 網路打通了。 但 A 網路的服務，不能透過 B 網路去存取 C 網路。 A 和 C 之間必須再建立一個獨立的 VPC Peering 連線。

服務只有幾個時，影響不大。 服務成長到幾百個、幾千個，需要互相連線的組合數量就會爆炸性增長，管理幾千條 Peering 連線本身就是巨大的維運負擔。

網路架構設計要在初期就考慮擴展性。 等問題出現再來改，代價是初期就設計好的幾十倍。

7.2 Workload Identity：容器的存取權限管理

GKE 的 Workload Identity 讓容器安全存取 GCP 上的其他服務。

每個容器啟動時，GCP 自動發給它一組識別憑證，記錄這個容器有哪些存取權限。

相比傳統做法（把密碼寫在設定檔裡）的優勢： 設定檔傳錯地方、被包進映像檔推上公開倉庫，都可能造成嚴重的安全事故。 Workload Identity 的憑證不存在任何地方，大幅降低外洩風險。

速查表：這篇文章的判斷框架

常見問題 FAQ

Q1：Spotify 的雲端遷移總共花了多少時間？ Spotify 從 2016 年開始將服務逐步遷移到 GCP，到 2023 年時已幾乎完成整個遷移過程，前後歷時約七年。這麼長的時間，主要是因為遷移過程中服務不能中斷，必須以滾動式、漸進式的方式進行。

Q2：什麼是 Lift and Shift？適合哪種情境？ Lift and Shift 是一種雲端遷移策略，指的是將服務原封不動地搬到雲端，不修改任何程式碼或架構。這種方式最適合「停機代價非常高」的核心服務——因為任何改動都是風險，直接搬過去能把遷移風險降到最低。代價是舊有的技術債也會一起帶過去。

Q3：GKE 是什麼？和自己管理 Kubernetes 有什麼差別？ GKE（Google Kubernetes Engine）是 Google 提供的全代管 Kubernetes 服務。和自己管理 Kubernetes 最大的差別在於：安全更新、版本升級、Control Plane 的維護，全部由 Google 負責，使用者只需要專注在自己的應用程式上。這能大幅減少工程師花在維運上的 Toil 時間。

Q4：Cloud Spanner 的外部一致性（External Consistency）和一般資料庫有什麼不同？ 一般的分散式資料庫通常提供的是「最終一致性」（Eventual Consistency）——也就是資料更新後，不同節點的資料可能有短暫的不一致，但最終會同步。Spanner 的外部一致性提供更強的保證：一筆資料寫入之後，全球任何地方的讀取都能立刻看到最新的版本，就像銀行帳戶的操作一樣。

Q5：Bigtable 的 Key 設計為什麼重要？ Bigtable 會把相近的 Key 存放在同幾台機器上。如果直接用連續性的 ID 當 Key（例如遞增的用戶 ID），熱門用戶的資料就會集中在少數機器上，造成「熱點」問題，讓那幾台機器過載、整體效能下降。先對 Key 做 Hash 處理，可以讓資料均勻分散到所有機器，避免熱點。

Q6：什麼是 Toil？工程師為什麼要減少它？ Toil 指的是重複性的、手動的、對系統沒有長期改善效果的維運工作。例如每天手動重啟某個服務、手動處理積壓的任務、手動更新設定檔等。Toil 不只讓工程師感到無聊和挫折，更重要的是它直接佔用了工程師的時間，讓他們沒有精力去做真正有創造力、有長遠價值的工作。

Q7：Pub/Sub 的 At-least-once Delivery 為什麼不設計成 Exactly-once（剛好一次）？ Exactly-once 的保證在分散式系統中實作成本非常高，因為要確保訊息剛好送達一次，需要複雜的協調機制，而這些機制本身也有失敗的可能性。業界的普遍做法是選擇 At-least-once（保證至少送達），然後在應用層實作冪等性來處理重複訊息，這樣能在可靠性和效能之間取得比較好的平衡。

Q8：CDN（內容遞送網路）對音樂串流服務有多重要？ CDN 對 Spotify 這類全球性的串流服務幾乎是不可或缺的。沒有 CDN，台灣用戶播放一首歌的請求可能要繞到美國的伺服器，光是網路延遲就可能讓音樂無法即時播放。CDN 把熱門內容預先放到離用戶最近的節點，不只改善了使用體驗，也大幅降低了跨洲際的頻寬費用。

Q9：VPC Peering 的 Transitive Routing 限制有沒有替代方案？ 有。Google Cloud 提供了 Cloud VPN 和 Cloud Interconnect 作為替代或補充方案，也有 Shared VPC 的架構可以讓多個專案共用同一個網路，減少需要建立 VPC Peering 的數量。另外，使用服務網格（Service Mesh）如 Anthos Service Mesh，也可以在不依賴 VPC Peering 的情況下管理服務間的通訊。

Q10：Spotify 的雲端遷移經驗適用於中小型公司嗎？ 核心原則是適用的，但規模不同，決策的優先序也不同。對中小型公司來說，最重要的啟發可能是：善用雲端的全代管服務（Managed Services）來減少維運負擔，把有限的工程師資源集中在核心產品上；以及在技術選型初期就把擴展性和成本控制考慮進去，避免後期需要痛苦的架構大改。

原始案例參考：https://cloud.google.com/customers/spotify

The post Spotify 成功案例 – 如何將服務搬上 GCP？7 大關鍵技術決策完整解析 first appeared on 東東 GCP 教學 - GCP 實戰講師.

1. 進入 GCP Console → VPC 網路 → 防火牆
2. 點擊「建立防火牆規則」
3. 填寫名稱、選擇方向（Ingress/Egress）、設定動作（Allow/Deny）
4. 指定目標（標籤或服務帳號）、來源 IP 範圍
5. 指定通訊協定與連接埠（如 tcp:80,443），儲存

用 gcloud 一行指令的話：

gcloud compute firewall-rules create default-allow-http-https \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web-server

上面是最快的版本。

如果你是第一次設定、不確定每個欄位是什麼意思、或是設完還是連不上，往下看——下面會逐一拆解每個元件的意思，以及常見踩雷的地方。

一、什麼是 GCP 防火牆規則？

1.1 GCP 防火牆的基本概念

簡單來說，GCP 防火牆規則就像是你家大門的保全系統。你可以決定哪些人能進門、哪些人不行；哪些流量可以進來、哪些要擋在門外。

在 Google Cloud 的架構裡，防火牆規則是定義在 VPC（Virtual Private Cloud）網路層級的規則。這些規則可以控制進出你的 VM（虛擬機器）或其他 GCP 資源的網路流量。

每一條防火牆規則會指定：

1. 哪個 VPC 網路適用這條規則
2. 流量的方向（進來還是出去）
3. 要允許還是拒絕這個流量
4. 套用這條規則的目標（哪些 VM）
5. 流量的來源或目的地
6. 通訊協定（TCP、UDP、ICMP 等）和連接埠

你可以把它想像成一個超精密的過濾器，讓你對流量做非常細緻的控制。

1.2 GCP 防火牆與傳統防火牆有什麼不同？

很多人剛接觸 GCP 的時候，會用「傳統防火牆機器」的思維來理解它，結果常常卡住。讓我們來說說幾個關鍵差異。

傳統防火牆通常是部署在網路邊界的實體或虛擬設備，所有進出的流量都要「過」這個點。而 GCP 的防火牆規則是分散式的，它運作在 Google 的全球基礎架構上，不存在單一的防火牆設備。這代表規則的套用是直接在 VM 層級發生的，不是在網路邊界。

另一個重要差異是：GCP 防火牆規則是有狀態（Stateful）的。這表示如果你允許一個連線進來，回應這個連線的封包就會自動被允許出去，你不需要另外設一條 Egress 規則來放行回應流量。對大多數應用場景來說，這大幅簡化了規則的設計。

1.3 GCP 防火牆規則在 VPC 網路中的角色

在 GCP 的 VPC 架構中，防火牆規則扮演著核心的安全角色。每個 VPC 網路都可以有自己的防火牆規則，而這些規則會套用在這個 VPC 內的所有資源上。

值得注意的是，GCP 的防火牆規則是全域資源，不是區域性的。這意味著你在台灣建立一個規則，它可以同時保護你在美國、歐洲的 VM，非常方便。

二、GCP 防火牆規則的核心元件解析

要設定好防火牆規則，你必須先搞懂每個元件的意思。這就像在說一個語言，你要先認識它的語法，才能說出有意義的句子。

2.1 優先順序（Priority）是什麼？如何影響規則？

優先順序是一個介於 0 到 65535 之間的整數，數字越小，優先順序越高。當多條規則同時符合同一個流量時，優先順序最高（數字最小）的規則會被套用，其他規則會被忽略。

舉個例子：

• 規則 A：優先順序 1000，允許來自任何來源的 TCP 80 流量
• 規則 B：優先順序 500，拒絕來自 192.168.1.0/24 的所有流量

如果有一個來自 192.168.1.5 的 TCP 80 請求進來，會套用哪條規則？答案是規則 B，因為它的優先順序（500）比規則 A（1000）更高（數字更小）。

如果你沒有指定優先順序，GCP 預設會使用 1000。

2.2 方向（Direction）：Ingress vs. Egress

防火牆規則的方向決定了它管的是哪種流量：

Ingress（入站）

從外部進入你的 VM 的流量，或是在 VPC 內部，別台 VM 進入你 VM 的流量。例如，使用者瀏覽你網站的請求，就是 Ingress。

Egress（出站）

從你的 VM 送往外部的流量。例如，你的 VM 去抓第三方 API 的資料，就是 Egress。

大多數情況下，我們主要管 Ingress，但在某些高安全性場景下，Egress 的管控同樣重要，而我們很容易忽略這種方向的設定。

通常機器中毒或被駭客入侵，有可能只防別人來存取，卻沒有擋自己去入侵別人。

2.3 動作（Action）：Allow vs. Deny

這個很直觀：

• Allow（允許）：讓符合規則條件的流量通過
• Deny（拒絕）：阻擋符合規則條件的流量，且不傳送任何回應

當流量被 Deny 時，發送方收不到任何回應，這可以避免讓對方知道你的服務存在。

因為傳統的防火牆有一種 Reject 動作，對方知道你存在但不能存取，GCP 防火牆則取消這種功能。

2.4 目標（Target）：套用規則的對象

目標決定了這條規則要套用到哪些資源上。GCP 提供三種指定方式：

• 所有 VM：規則套用到 VPC 內的所有 VM
• 指定網路標籤（Tags）：只套用到有特定標籤的 VM
• 指定服務帳戶（Service Account）：只套用到使用特定服務帳戶的 VM

2.4.1 使用網路標記（Tags）指定目標

網路標記是一個字串，你可以把它貼到 VM 上，然後在防火牆規則裡指定這個網路標記作為目標，這樣可以一次套用規則到多台機器，而非一台一台設定。

例如，你給所有 Web 伺服器貼上 web 標記，再建立一條允許 TCP 80/443 流量套用到 web 的規則，這樣就只有這些 VM 會受到影響。

因為你的專案可能有數十台機器，但只是有 5 台是 Web Server 可以完全對外，這個方法就不用套用到全部的機器上。

標籤的缺點是：任何有適當 IAM 權限的人都可以新增或移除 VM 的標籤，如果管理不當，可能會造成安全漏洞。

2.4.2 使用服務帳戶（Service Account）指定目標

使用服務帳戶來指定目標比標籤更安全，因為修改 VM 的服務帳戶需要更高的 IAM 權限，不容易被誤操作。這個方式特別適合需要高安全性的環境。

尤其是你的主機之間有許多程式要互相存取，而程式在 GCP 環境中都必須帶著 Service Account 以供識別，就很適合這種設定方式。

2.5 來源與目的地（Source / Destination）設定

• 對於 Ingress 規則：你需要指定「來源」，可以是 IP 位址範圍、來源標籤或來源服務帳戶。
• 對於 Egress 規則：你需要指定「目的地」，通常是 IP 位址範圍。

常用的 IP 範圍表示法：

• 0.0.0.0/0：代表所有 IPv4 位址（要小心使用！通常只有 Web Server 才會做這種設定）
• 10.0.0.0/8：代表 10.x.x.x 的私有網路
• 192.168.1.5/32：代表單一 IP 位址

如果一台機器碰到兩條相同優先順序、相同通訊協定和 Port 的規則，則拒絕的規則優先於允許的。

三、設定 GCP 防火牆規則之前，你需要知道的事

3.1 預設防火牆規則有哪些？

當你建立一個新的 VPC 網路（使用「自動模式」）時，GCP 會自動幫你建立四條預設防火牆規則：

你會發現這四條規則的優先順序都是 65534，這是接近最低的優先順序，目的是讓你之後新增的規則可以覆蓋它們。

當然如果用不到也可以刪除。

3.2 隱含規則（Implied Rules）的運作原理

除了上面的預設規則，GCP 還有兩條看不見但永遠存在的隱含規則，你無法刪除或修改它們：

1. 隱含 Ingress Deny 規則（優先順序 65535）：拒絕所有進入的流量
2. 隱含 Egress Allow 規則（優先順序 65535）：允許所有對外的流量

這兩條規則是 GCP 安全設計的基礎——預設情況下，進來的流量全部拒絕，出去的流量全部允許。你設定的規則，就是在這個基礎上「開口」或「關口」。

要注意，因為你無法修改它們，你就無法開啟記錄（Log），如果你想記錄這兩條規則，就必須手動新增規則再開啟記錄。

3.3 如何確認目前的防火牆狀態？

在開始設定之前，建議先看一下目前的狀態，避免重複或衝突。你可以透過 GCP Console 查看：

進入 VPC 網路 → 防火牆，就可以看到目前所有規則的清單，包括名稱、方向、優先順序、動作、目標和來源等資訊。

四、如何在 GCP Console 設定防火牆規則？（圖文步驟）

好了，理論說夠了，我們直接來看怎麼操作！

也可以查接查看 YouTube 示範影片。

4.1 進入防火牆規則設定頁面

1. 登入 GCP Console
2. 在左側選單找到 「VPC 網路」
3. 點擊子選單中的 「防火牆」
4. 你會看到目前所有的防火牆規則清單

4.2 建立新的防火牆規則（逐步說明）

點擊頁面上方的 「建立防火牆規則」 按鈕，開始設定。

4.2.1 填寫規則名稱、說明和是否啟用記錄

• 名稱：必須是英文小寫、數字和連字號組成，例如 allow-http-web-servers。
• 建議用有意義的名稱，讓未來維護時一眼就能看懂這條規則的用途。
• 如果你有多個 VPC，建議增加前綴，例如 default-allow-http-web-servers，其中 default 就是 VPC 的名字。
• 說明（選填）：可以寫更詳細的說明，例如「允許來自任何 IP 的 HTTP 80 流量，只套用到 web-server 標籤的 VM」。

關於記錄功能，平常不會打開，但如果想要做故障排除，例如想知道某個來源 IP 的主機，到底有沒有把流量送過來，可以對 Ingress 的規則啟用記錄；如果想知道你的某台主機，到底有沒有發出流量給對方，可以對 Egress 的規則啟用記錄。

詳細操作說明可以參考這個影片：

4.2.2 設定 VPC 網路、優先順序與方向

• 網路：選擇這條規則要套用到哪個 VPC 網路。
• 優先順序：輸入一個 0 到 65535 的數字，數字越小優先順序越高。建議從 1000 開始，留有上下調整的空間。
• 流量方向：選擇 「Ingress（輸入）」 或 「Egress（輸出）」。
• 如果相符，請執行下列操作：選擇 「允許」 或 「拒絕」。

4.2.3 設定動作與目標

在 「目標」 欄位，選擇規則要套用的範圍：

• 網路中的所有執行個體：套用到 VPC 內的所有 VM（慎用！）
• 指定的目標標籤：輸入你要套用的標籤，例如 web
• 指定的服務帳戶：輸入服務帳戶的 email

4.2.4 設定來源 IP 範圍、通訊協定與連接埠

來源 IP 範圍：

輸入允許的 IP 範圍，例如 0.0.0.0/0 表示允許所有 IP。如果要限制特定範圍，輸入像 203.0.113.0/24。單一 IP 的範例像 203.0.113.18/32。

通訊協定和連接埠：

可以選擇「全部允許」，或指定特定的通訊協定（TCP、UDP）和連接埠號，例如 tcp:80,443。

如果是要設定 Ping 的話，則是勾選「其他」，然後輸入 icmp。

4.3 儲存並驗證規則是否生效

設定完成後，點擊 「建立」 按鈕，規則通常會在幾秒鐘內生效。你可以透過以下方式驗證：

• 回到防火牆規則清單，確認新規則有出現
• 嘗試對你的 VM 進行你預期允許的連線，確認成功
• 嘗試進行你預期被拒絕的連線，確認失敗

五、使用 gcloud CLI 設定 GCP 防火牆規則

如果你是工程師，或是需要用程式自動化管理防火牆規則，gcloud CLI 是你的好朋友。它不只快，而且可以輕鬆整合進 CI/CD 流程。

5.1 安裝與設定 gcloud 工具

如果還沒安裝，可以從 Google Cloud SDK 下載安裝。安裝完後，執行以下指令完成初始化：

gcloud init

按照提示選擇你的帳號和預設專案，設定好之後就可以開始使用了。

5.2 常用防火牆指令整理

以下是最常用的幾個 gcloud 防火牆指令：

# 列出所有防火牆規則
gcloud compute firewall-rules list

# 查看特定規則的詳細資訊
gcloud compute firewall-rules describe RULE_NAME

# 建立防火牆規則
gcloud compute firewall-rules create RULE_NAME \
  --network=NETWORK_NAME \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web

# 刪除防火牆規則
gcloud compute firewall-rules delete RULE_NAME

# 更新防火牆規則
gcloud compute firewall-rules update RULE_NAME \
  --priority=500

5.3 實戰範例：允許 HTTP/HTTPS 流量

假設你想讓 web-server 標籤的 VM 接受所有來源的 HTTP（80 埠）和 HTTPS（443 埠）流量：

gcloud compute firewall-rules create default-allow-http-https \
  --network=default \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web \
  --description="允許來自任何 IP 的 HTTP 和 HTTPS 流量"

執行完後，只要你的 VM 有 web 這個標籤，它就可以接收 80 和 443 埠的流量了。

你也可以點開這一條防火牆規則，畫面滑到最下方，確認這條規則套用到哪些主機上。

5.4 實戰範例：封鎖特定 IP 來源

如果你發現有個 IP 203.0.113.50 一直在嘗試暴力破解你的系統，你可以建立一條高優先順序的 Deny 規則來封鎖它：

gcloud compute firewall-rules create block-malicious-ip \
  --network=default \
  --direction=INGRESS \
  --priority=100 \
  --action=DENY \
  --rules=all \
  --source-ranges=203.0.113.50/32 \
  --description="封鎖惡意 IP 203.0.113.50 的所有流量"

注意優先順序設為 100，遠高於其他規則，確保這條封鎖規則一定會被先套用。

六、GCP 防火牆規則的進階設定技巧

掌握了基礎，我們來看看一些讓你的防火牆設計更精準、更安全的進階技巧。

6.1 使用服務帳戶取代網路標籤的優勢

前面提到，標籤雖然方便，但安全性不如服務帳戶。在對安全要求高的環境中，你應該優先考慮使用服務帳戶來指定防火牆目標。

原因很簡單：更改 VM 的服務帳戶需要 compute.instances.setServiceAccount 這個 IAM 權限，而這個權限通常只有系統管理員才有。相比之下，給 VM 加標籤的門檻低很多。

以 gcloud 指令為例，使用服務帳戶作為目標：

gcloud compute firewall-rules create allow-internal-db \
  --network=default \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-service-accounts=web-sa@my-project.iam.gserviceaccount.com \
  --target-service-accounts=db-sa@my-project.iam.gserviceaccount.com

這條規則的意思是：只允許使用 web-sa 服務帳戶的 VM，連線到使用 db-sa 服務帳戶的 VM 的 5432 埠（PostgreSQL）。

6.2 多層防火牆規則的優先順序設計策略

當你的環境複雜，有很多條規則時，建議採用分層設計，讓規則的邏輯更清晰：

• 優先順序 100-199：緊急封鎖規則（封鎖特定惡意 IP 或攻擊來源）
• 優先順序 500-599：高安全性白名單規則（允許特定管理 IP 的 SSH 存取）
• 優先順序 1000-1999：一般服務規則（允許 HTTP/HTTPS）
• 優先順序 5000-5999：寬鬆的後備規則

這樣的設計讓你在緊急情況下只需要在 100-199 範圍增加一條規則，就可以凌駕所有其他規則，不用修改現有設定。

6.3 Egress 規則：控制對外流量的方法

許多人只注重 Ingress，但 Egress 管控在某些場景下同樣重要。例如：

• 防止 VM 被入侵後對外發動攻擊
• 確保敏感資料不會被傳送到未授權的外部服務
• 符合某些法規要求（如 GDPR）

要限制 VM 只能連到特定的外部服務，你可以先建立一條「拒絕所有 Egress」的規則，再建立允許特定目的地的 Egress 規則：

# 拒絕所有對外流量（優先順序較低，數字較大）
gcloud compute firewall-rules create deny-all-egress \
  --network=default \
  --direction=EGRESS \
  --priority=65000 \
  --action=DENY \
  --rules=all \
  --destination-ranges=0.0.0.0/0

# 只允許連到 Google API（優先順序較高，數字較小）
gcloud compute firewall-rules create allow-google-apis \
  --network=default \
  --direction=EGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:443 \
  --destination-ranges=199.36.153.4/30

6.4 如何限制 SSH 與 RDP 存取來源？

預設的 default-allow-ssh 規則允許來自任何 IP 的 SSH 連線，這對生產環境來說是很大的風險。你應該立即修改這條規則，限制只有你的辦公室或跳板機 IP 可以 SSH 進來：

# 先刪除或停用預設的 SSH 規則
gcloud compute firewall-rules update default-allow-ssh \
  --source-ranges=YOUR_OFFICE_IP/32

如果你使用 GCP 的 IAP（Identity-Aware Proxy）來進行 SSH 連線（強烈推薦！），來源 IP 範圍應設為 35.235.240.0/20：

gcloud compute firewall-rules create allow-ssh-via-iap \
  --network=default \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --description="只允許透過 IAP 的 SSH 連線"

七、GCP 防火牆規則常見錯誤與排除方法

設定完規則之後還是有問題嗎？別擔心，這些常見錯誤我們來一一說明。

7.1 規則設定後仍然無法連線怎麼辦？

遇到這種情況，請按照以下清單依序檢查：

第一步：確認規則存在且已生效

gcloud compute firewall-rules describe allow-http-https

確認規則的所有參數（方向、動作、通訊協定、連接埠、目標）都正確。

第二步：確認 VM 有正確的標籤或服務帳戶

gcloud compute instances describe VM_NAME \
  --zone=ZONE \
  --format='get(tags.items)'

確認 VM 上貼的標籤和規則裡設定的目標標籤一致。

也可以在主控台上確認兩邊設定。

第三步：確認應用程式本身有在正確的埠上監聽

防火牆放行了，但如果你的 Nginx 沒有啟動，或者在 8080 埠而不是 80 埠，一樣連不上。SSH 進 VM 後執行：

sudo netstat -tlnp | grep LISTEN

第四步：確認沒有更高優先順序的 Deny 規則擋住了流量

7.2 優先順序衝突導致規則失效

這是最常見的問題之一。當你有一條 Allow 規則和一條 Deny 規則都符合同一個流量時，優先順序較高（數字較小）的那條才會生效。

如果你建立了一條 Allow 規則，但流量還是被擋，很可能是有另一條 Deny 規則的優先順序更高。你需要去防火牆清單裡，按優先順序排序，仔細檢查每一條可能符合這個流量的規則。

7.3 如何使用防火牆記錄（Firewall Logs）診斷問題？

防火牆記錄是排查問題的神兵利器。它可以記錄下每一條規則「命中」的流量，讓你清楚看到到底是哪條規則在處理你的流量。

啟用防火牆記錄的方式：

gcloud compute firewall-rules update RULE_NAME \
  --enable-logging

啟用後，你可以在 Cloud Logging 裡查看記錄，搜尋關鍵字 resource.type="gce_logName=”projects/[project-id]/logs/compute.googleapis.com%2Ffirewall”firewall_rule"，就可以看到所有防火牆的命中記錄，包括流量的來源、目的地、連接埠，以及是被哪條規則允許或拒絕的。

你也可以直接在某一條防火牆的頁面上點擊「打開記錄」，就會只看得到這條規則的記錄，不需要背下搜尋語法，操作起來更方便。。

八、GCP 防火牆規則的最佳實踐建議

設定防火牆規則沒有所謂的「完美」方法，但有一些最佳實踐是被業界廣泛認可的，我們強烈建議你遵循。

8.1 最小權限原則（Principle of Least Privilege）

這是資安界最核心的原則：只允許必要的流量，拒絕其他一切。

在實作上，這意味著：

• 不要使用 0.0.0.0/0 開放所有 IP，除非真的必要（例如公開的 HTTP 服務）
• 不要開放不需要的連接埠
• 不要用「所有 VM」作為目標，盡量用標籤或服務帳戶精確指定
• 前面的規則設定完成，最後面就設定一條拒絕所有來源的規則。
• 定期審視規則，刪除不再使用的規則

8.2 避免使用 0.0.0.0/0 開放所有來源

我們知道有時候設定 0.0.0.0/0 很方便，但這等於是把你的服務完全暴露在網路上，任何人都可以嘗試連線。特別是 SSH（22 埠）和 RDP（3389 埠），如果開放給 0.0.0.0/0，你的 VM 每天都會被全球各地的掃描工具嘗試暴力破解。你可以看到我的一台主機，隨時有人想要 SSH 登入進來的記錄：

建議做法：

• SSH 和 RDP：使用 IAP 或限制特定 IP 來源
• 資料庫連接埠（如 3306、5432）：絕對不要開放給 0.0.0.0/0
• 應用程式的內部 API：只允許同 VPC 或特定服務的存取

8.3 定期稽核防火牆規則

防火牆規則會隨著時間累積，慢慢出現很多「遺留規則」——當初某個專案用完就沒刪，或是某個同事設了但沒留下說明文件。這些規則可能帶來安全風險，也讓維護變得複雜。

建議至少每季進行一次防火牆規則稽核：

1. 列出所有規則，確認每條規則的用途
2. 刪除或停用不再使用的規則
3. 確認所有規則的來源範圍是否還合適
4. 確認防火牆記錄是否有異常命中

你也可以使用 GCP Security Command Center 或第三方工具來自動化稽核流程，讓安全管理更有效率。

九、結論

GCP 防火牆規則看起來複雜，但只要掌握核心元件——優先順序、方向、動作、目標和來源——你就有能力設計出既安全又彈性的網路架構。

我們從基礎概念出發，學習了防火牆規則的各個元件，再到透過 Console 和 gcloud CLI 實際操作，最後討論了進階技巧和最佳實踐。這套知識讓你不只是「能用」GCP 防火牆，而是「用得好」。

記住最重要的原則：最小權限。不確定要不要開放某個流量時，先選擇拒絕，等確認需求後再開放。這樣的保守態度，才是雲端安全的正確心態。

防火牆設定是一個持續演進的過程，隨著你的服務架構調整，規則也需要跟著調整。養成定期稽核的習慣，並善用防火牆記錄來監控異常流量，你的 GCP 環境就能在安全與可用性之間達到最佳平衡。

常見問題解答（FAQ）

1. GCP 防火牆規則最多可以設定幾條？

每個 VPC 網路最多可以設定 200 條防火牆規則。如果你的環境非常複雜，需要更多規則，可以聯絡 GCP 支援申請提高配額。不過通常 200 條對大多數環境來說已經足夠，如果超過這個數量，建議檢視是否可以合併或簡化規則。

2. 防火牆規則的優先順序數字越小代表越高優先？

是的，完全正確。優先順序是一個介於 0 到 65535 的整數，數字越小，優先順序越高。當多條規則同時符合同一個流量時，優先順序最高（數字最小）的規則會被套用。如果優先順序相同，則 Deny 規則優先於 Allow 規則。

3. GCP 預設的防火牆規則可以刪除嗎？

可以的，四條預設規則（allow-internal、allow-ssh、allow-rdp、allow-icmp）都可以刪除。但要小心，刪除這些規則可能會導致你無法 SSH 進 VM。建議在刪除之前，先確認你有其他方式可以管理 VM（例如 Cloud Console 的序列主控台）。至於 GCP 的兩條隱含規則（最低優先順序的 Deny Ingress 和 Allow Egress），這兩條是無法刪除或修改的。

4. 如何確認防火牆規則是否正確套用到 VM？

你可以在 VM 的詳細資訊頁面查看「網路介面」區塊，點擊「防火牆規則詳情」就可以看到套用到這台 VM 的所有防火牆規則，包括每條規則的方向、優先順序和動作。另外，也可以啟用防火牆記錄，透過 Cloud Logging 查看實際的流量命中記錄，這是最直接的驗證方式。

5. Ingress 和 Egress 規則的差別是什麼？

Ingress 規則管控的是「從外部進入你的 VM」的流量，例如使用者連線到你的網站。Egress 規則管控的是「從你的 VM 送往外部」的流量，例如你的 VM 去呼叫外部 API。GCP 的防火牆是有狀態的，允許一個 Ingress 連線後，這個連線的回應封包會自動被允許出去，不需要另外設 Egress 規則。

6. GCP 防火牆支援 IPv6 嗎？

是的，GCP 防火牆支援 IPv6。如果你的 VPC 網路有啟用 IPv6，你可以在防火牆規則的來源或目的地範圍裡指定 IPv6 的 CIDR 範圍（例如 ::/0 代表所有 IPv6 位址）。需要注意的是，IPv4 和 IPv6 的規則需要分開設定，一條規則無法同時套用兩者。

7. 使用服務帳戶設定防火牆目標有什麼好處？

使用服務帳戶作為防火牆目標比使用標籤更安全，原因在於：修改 VM 的服務帳戶需要較高的 IAM 權限（compute.instances.setServiceAccount），不容易被誤操作或惡意修改。標籤則相對容易被有 compute.instances.setLabels 權限的人任意添加，存在一定的安全風險。在高安全性環境，優先選擇服務帳戶作為目標。

8. 防火牆規則可以套用到多個 VPC 嗎？

不行，一條防火牆規則只能套用到單一 VPC 網路。如果你有多個 VPC 需要相同的規則，你需要在每個 VPC 裡分別建立規則。如果你使用的是共用 VPC（Shared VPC），你可以在宿主 VPC 裡建立規則，這樣所有連接到這個共用 VPC 的服務專案都會套用這條規則。

9. 如何透過 Terraform 管理 GCP 防火牆規則？

Terraform 是管理 GCP 防火牆規則的最佳工具之一，因為它可以讓你用程式碼（Infrastructure as Code）定義規則，版本控制和稽核都更容易。使用 google_compute_firewall 資源即可：

resource "google_compute_firewall" "allow_http" {
  name    = "allow-http"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["80", "443"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["web-server"]
}

10. 開啟防火牆記錄會增加費用嗎？

是的，開啟防火牆記錄會產生額外費用，費用是依據記錄的資料量計算（以 Cloud Logging 的計費方式收費，超出免費額度後才收費）。在流量大的環境裡，記錄費用可能不小。建議做法是：只在特定需要診斷的規則上開啟記錄，完成診斷後再關閉；或使用記錄過濾條件（Log filtering）只記錄特定類型的流量，以控制費用。

GCP 防火牆規則只是眾多資安服務的其中一種，如果你想了解更多，可以查看《雲端的資訊安全防禦縱深，常用資安服務介紹》。

The post GCP 防火牆規則如何設定？5 步驟完整攻略與實戰技巧 first appeared on 東東 GCP 教學 - GCP 實戰講師.

🔷 什麼是 BigQuery 企業資料倉儲？

傳統的地端資料倉儲（On-premises Data Warehouse）需要企業自行採購硬體、規劃容量、安排停機維護。相比之下，BigQuery 提供的是「隨需擴展、按量計費、零維護成本」的雲端分析環境，讓數據分析師可以把時間花在洞察分析，而不是等待基礎設施就緒。

🔷 Home Depot 為什麼要導入 BigQuery？

地端資料倉儲的三大痛點

Home Depot 擁有超過 2,200 間門市、70 萬種商品品項，龐大的業務規模讓傳統資料倉儲不堪負荷。導入 BigQuery 之前，他們面臨以下困境：

1. 擴容困難、停機成本極高 每次需要增加地端儲存容量，都要經歷六個月的規劃期與長達三天的服務中斷。即便如此，容量不到一年又告警示。這對 24 小時不間斷的零售業來說，是難以接受的風險。

2. 數據規模持續爆炸性成長 隨著電商、門市 POS、供應鏈、網站點擊流（Clickstream）等新數據來源加入，分析師需要的數據量遠超地端系統的上限，查詢複雜度也不斷提升。

3. 團隊協作效率低落 不同業務部門的分析工作常常互相搶奪有限的運算資源，導致報表延遲、決策速度下降。

🔷 Home Depot 是怎麼導入 BigQuery 的？

企業導入 BigQuery 的核心流程

雖然每間企業的情況不同，但 Home Depot 的案例揭示了一條可複製的遷移路徑：

步驟 1：評估現有資料倉儲瓶頸 確認地端系統的容量上限、查詢效能瓶頸，以及哪些業務場景（供應鏈、財務、客訂等）是最高優先級的遷移目標。

步驟 2：設計多專案的 IAM 權限架構 利用 BigQuery 的 Identity and Access Management（IAM），建立多個 Google Cloud Project，讓不同業務部門各自管理數據，防止跨部門誤存取或資料外洩。

步驟 3：將地端資料遷移至 BigQuery Home Depot 原本的地端資料倉儲容量為 450 TB，完整遷移至 BigQuery 後，現在的資料規模已超過 15 PB——足足是原來的 33 倍以上。

步驟 4：採用 Flat-rate 月費方案，控制預算可預測性 BigQuery 提供按查詢量計費與固定月費（Flat-rate）兩種計費模式。Home Depot 選擇固定月費，讓各部門可以依需求預算容量，未使用的資源也可供全企業共享，避免月底帳單暴增的驚喜。

步驟 5：擴展進階分析能力 遷移完成後，分析師開始啟用 Datalab（Python Notebook 環境）、BigQuery ML（直接在倉儲中訓練機器學習模型）和 AutoML，大幅提升預測分析能力，而無需額外搬移大型數據集。

🔷 BigQuery 導入後的實際效能數據

以下是 Home Depot 遷移至 BigQuery 後，各業務場景的效能提升對比：

🔷 BigQuery 對企業的三大核心優勢

① 無縫擴容，零停機

地端系統需要三天停機才能完成擴容，BigQuery 擴容只需一週（未來甚至可達當日完成），且全程無服務中斷。

② 標準 SQL，快速上手

BigQuery 支援標準 SQL 語法，企業內部的資料分析師不需要重新學習專有查詢語言，大幅降低遷移的人力學習成本。

③ IAM 隔離，企業安全合規

透過多 Project + IAM 的架構，不同業務單位的數據得以嚴格隔離，既能共享運算資源，又能確保敏感數據不被跨部門誤存取——這對金融、零售、醫療等高合規需求產業尤為重要。

🔷 哪些企業適合導入 BigQuery？

並非所有企業都需要立刻遷移到 BigQuery，以下幾個特徵可以幫助你判斷：

適合導入 BigQuery 的情境：

• 每月數據查詢量持續增長，地端系統頻繁出現效能瓶頸
• 有多個部門需要各自分析數據，但又需要共享運算資源
• 希望將 ML 模型訓練與數據倉儲整合，減少數據搬移成本
• 需要對 TB 至 PB 級數據進行即時（或近即時）分析

暫時不適合的情境：

• 數據規模仍在 TB 以下，且查詢頻率低
• 企業有嚴格的資料主權法規，無法將數據存放於境外雲端
• 預算有限，且目前系統的效能尚在可接受範圍

結論

對正在評估雲端資料倉儲的企業而言，BigQuery 最值得關注的不只是效能數字，而是它讓分析師能把時間花在「發現洞察」而非「等待查詢」——這才是數據驅動組織真正需要的能力。

❓ 常見問題 FAQ

Q1：BigQuery 和傳統資料庫有什麼不同？ BigQuery 是專為大規模分析查詢設計的 OLAP（線上分析處理）系統，而傳統資料庫（如 MySQL、PostgreSQL）是為交易型操作（OLTP）設計的。BigQuery 不適合高頻率的單筆資料寫入或更新，但面對跨數億筆資料的聚合查詢，其速度遠超傳統關聯式資料庫。

Q2：BigQuery 的費用怎麼計算？ BigQuery 提供兩種計費模式：按查詢量計費（每 TB 掃描資料約 5 美元）與固定月費（Flat-rate，依 Slot 數量預付）。小型企業通常從按量計費開始，數據量大或查詢頻繁的企業則更適合固定月費以控制成本可預測性。

Q3：將地端資料倉儲遷移到 BigQuery 需要多久？ 遷移時間取決於數據量、資料清理複雜度與組織的技術能力。一般中大型企業的完整遷移週期約為 3 至 12 個月，建議採用「分批遷移、驗證後切換」的策略，降低業務中斷風險。

Q4：BigQuery 可以跑機器學習嗎？ 可以。BigQuery ML 允許分析師直接在 BigQuery 內使用 SQL 語法訓練迴歸、分類、時間序列等多種 ML 模型，無需將數據匯出至其他平台，大幅降低 ML 導入的門檻與數據搬移成本。

Q5：GCP 的 BigQuery 和 AWS Redshift、Azure Synapse 相比哪個更好？ 三者各有優勢，但 BigQuery 的無伺服器架構讓維運成本最低；Redshift 在 AWS 生態系整合較佳；Synapse 則適合深度整合 Microsoft 工具的企業。選擇時應優先考量企業現有技術棧、資料量規模與合規需求，而非單純比較功能清單。

Q6：如何上傳資料到 BigQuery？

可參考此文章：https://dongdonggcp.com/2025/02/12/how-to-upload-data-to-bigquery/

本文引用來源：https://cloud.google.com/customers/the-home-depot

The post BigQuery 成功案例 – Home Depot (家得寶) 導入 GCP 的案例解析 first appeared on 東東 GCP 教學 - GCP 實戰講師.

雲端架構師（Cloud Architect）是規劃和設定雲端環境 （GCP、AWS、Azure） ，讓系統可以在雲端上順暢地跑起來的人。

也是根據公司要運作程式的需求（例如：想要架設電商網站），提出雲端解決方案（例如：自動擴充搭配負載平衡） 的人。

你可以把雲端架構師想像成「雲端世界的建築師」——一般建築師設計房子，雲端架構師設計的是一棟棟跑在雲端上的數位建築物。

雲端架構師的核心職責

雲端架構師的日常工作，主要包含以下幾個面向：

1. 評估需求：與業務單位溝通，了解系統規模、流量、安全需求
2. 設計架構：規劃雲端網路（Virtual Private Cloud; VPC）、Kubernetes 叢集、資料庫佈署方式
3. 成本管理：透過預算、長期的承諾使用折扣 （Committed Use Discount）、短期的續用折扣（Sustained Use Discount） 等機制降低雲端使用成本
4. 資安規劃：設定 Cloud IAM 權限和角色、防火牆、金鑰管理服務（KMS）設定加密、Security Command Center 監控雲端環境
5. 技術支援：協助開發團隊解決各種雲端疑難雜症
6. 維運監控：建立 Cloud Monitoring、Cloud Logging 警告機制

雲端架構師 vs 一般軟體工程師的差異

很多人會問：「雲端架構師跟工程師哪裡不一樣？」

最簡單的區分方式是：軟體工程師「寫程式解決問題」，雲端架構師「設計環境讓程式可以穩定運行」。工程師關注的是程式的各項功能運作，架構師關注的是基礎設施和整體系統架構。

兩者的互動是：工程師寫好程式，但不知道如何放到雲端上跑，由雲端架構師把環境設定好，然後幫工程師把程式放上去。

在薪資上，架構師普遍高於同年資的開發工程師，這也是為什麼許多工程師選擇往雲端架構師方向發展的主要原因。

2026 年台灣雲端架構師薪水行情

根據台灣 1111 人力銀行、104 人力銀行、CakeResume 及 LinkedIn 等平台的職缺資料，台灣雲端架構師月薪範圍約落在 8 萬到 20 萬新台幣之間，年薪含獎金可達 120 萬到 250 萬元，具備多雲認證者更有談判高薪的籌碼。

以下依照資歷分三個等級說明：

初階雲端架構師薪資（0～3 年雲端經驗）

初階雲端架構師通常來自系統工程師、網路工程師或軟體工程師轉職而來。這個階段的工作以「執行」為主，配合資深架構師的規劃進行實作。

初階薪資提升關鍵： 拿到第一張雲端 Associate 等級認證後，月薪通常可立即提升 5,000 至 15,000 元，對應聘資格影響非常大。

中階雲端架構師薪資（3～8 年雲端經驗）

這個階段的架構師已經能獨立主導專案，開始帶領小團隊，並且有能力與客戶直接溝通技術方案。如果你同時具備兩張以上 Professional 等級認證，薪資談判空間會更大。

資深雲端架構師薪資（8 年以上 / 特殊專長）

資深架構師的薪水往往不只來自技術能力，更來自「業務開發能力」——能不能幫公司拿到大型雲端專案，直接決定你的市場價值。

很多高薪的雲端架構師，其實就是售前（Presales），主要職責就是協助公司推廣雲端產品，拿到雲端開發或建置案，除了能賺取專案的人力費用，客戶每個月使用雲端產生的被動收益，也是公司的主要收入來源。這種能夠幫公司賺錢的雲端架構師，薪水就遠遠超過只是操作內部系統的雲端架構師。

台灣雲端架構師的薪資天花板遠高於一般工程師職位。初階月薪 6～9 萬，中階 9～15 萬，資深可達 15～25 萬，年薪突破 200 萬並非少見。具備 GCP Professional Cloud Architect、AWS Solutions Architect 等 Professional 等級認證，是突破薪資瓶頸最直接有效的方式。

全球雲端架構師薪水比較

如果你有考慮出國工作或遠端接案，以下是各主要市場的薪資對比：

美國、日本、新加坡薪資比較

從這份比較表可以看出，台灣雲端架構師的薪資雖然相對美國偏低，但如果跟台灣其他 IT 職位相比，仍屬於高薪族群。尤其新加坡市場對台灣雲端架構師的需求相當高，是值得關注的出海選項。

像我個人也曾經收到要去新加坡建置大型雲端架構的案子，客戶會願意為此進行大筆投資。

影響雲端架構師薪水的關鍵因素

同樣是雲端架構師，為什麼薪水可以差到兩倍以上？以下是最關鍵的幾個因素：

GCP / AWS / Azure 認證的薪資加乘效果

雲端認證是影響架構師薪資最直接的因素之一，如果你沒有證據證明你在雲端的能力和經驗，持有證照就是唯一客觀的評估標準。持有 GCP Professional Cloud Architect 認證的工程師，平均薪資比未持有認證者高出 20%～40%。若同時持有 GCP + AWS 雙認證，在台灣的求職市場幾乎是「有求必應」的狀態。

主要認證對薪資的影響如下：

GCP 系列認證：

• Associate Cloud Engineer：月薪提升 5,000～15,000 NTD
• Professional Cloud Architect：月薪提升 15,000～30,000 NTD
• Professional Data Engineer / Security Engineer：額外加給 10,000～20,000 NTD

AWS 系列認證：

• AWS Solutions Architect – Associate：月薪提升 8,000～18,000 NTD
• AWS Solutions Architect – Professional：月薪提升 20,000～40,000 NTD

關鍵提醒： 認證只是敲門磚，沒有實戰經驗搭配的認證說服力有限。最理想的狀況是邊工作邊考證，讓認證為你的實戰能力背書。

產業別薪資差異

不同產業對雲端架構師的需求和出價也有明顯差異：

如何成為雲端架構師？轉職路徑完整說明

從非技術背景轉職的真實案例

我自己的經歷就是一個很好的例子。我大學念統計系、研究所念企管，完全沒有資工背景，後來卻成為 GCP 的雲端架構師，現在在 YouTube 和部落格上教別人 GCP。

我的轉職路徑大概是這樣：

1. 2008年：花十萬元自費學習 Windows Server + SQL Server，考取 MCSA、MCDBA、RHCE 證照
2. 2009年：進入系統整合商，實際接觸政府 IT 系統，寫過 C# 和 Java
3. 2013年：透過前主管介紹，進入 Google 合作夥伴公司做 Presales
4. 2014年：GCP 在台灣開始大力推廣，轉型為 GCP 雲端架構師
5. 2023年：跳出來做自媒體「東東 GCP 教學」，分享 GCP 知識

轉職雲端架構師不一定需要資工本科背景。許多成功的雲端架構師來自系統工程師、網路管理員、甚至非技術職位（如 IT Presales、專案經理）。關鍵在於「取得認證 + 累積實戰案例 + 持續學習」這三個同步進行的動作，缺一不可。

接近 40 歲的時候，我也非常擔心機會越來越少。但事實證明，只要在一個特定的技術領域持續深耕，即使非本科也能建立別人難以取代的競爭優勢。

需要哪些技能與證照？

成為雲端架構師需要的技能可以分成「硬技能」和「軟技能」兩大類：

硬技能（技術能力）：

1. 網路基礎：TCP/IP、DNS、VPC、防火牆規則
2. Linux 系統管理：基本指令操作、權限管理、Log 分析
3. 容器技術：Docker、Kubernetes（GKE）
4. IaC（基礎設施即程式碼）：Terraform、Kubernetes YAML 撰寫
5. 資安概念：IAM 設計、加密金鑰管理、Zero Trust 架構
6. 資料庫：Cloud SQL、BigQuery、Spanner 的使用情境
7. 監控：Cloud Monitoring、Cloud Logging、告警設定

軟技能（非技術能力）：

1. 溝通能力：能把技術翻譯給非技術主管聽
2. 問題分析：面對客戶疑難雜症時的邏輯思維
3. 成本意識：設計架構時要同步考量 ROI
4. 文件撰寫：架構圖、技術提案、RFP 回覆

建議取得的認證順序（以 GCP 為例）：

1. 第一步：GCP Associate Cloud Engineer（建立基礎）
2. 第二步：GCP Professional Cloud Architect（主力認證）
3. 第三步：依照工作方向加考 Professional Data Engineer 或 Professional Security Engineer

雲端架構師薪水成長策略

光知道「雲端架構師薪水高」還不夠，你需要一套具體的薪資成長策略：

如何用 GCP 認證快速提升薪資

策略一：先考再談，用證照打開門

很多公司對認證持有者有加薪機制，甚至有證照獎金（有些公司每張證照獎勵 1 萬到 3 萬不等）。拿到認證後，跳槽或內部升遷都有更多籌碼。

策略二：做出可量化的成果

在面試時，「我幫公司把雲端帳單降低 30%」比「我有三年雲端架構師經驗」有力得多。每做完一個專案，一定要記錄下來：做了什麼、節省多少成本、解決什麼問題。

策略三：建立個人品牌

我自己從 2023 年開始做「東東 GCP 教學」，透過 YouTube 頻道、部落格（dongdonggcp.com）、Linked-in、和 Threads 分享 GCP 知識。這不只帶來了額外的收入來源，更讓我在行業內建立了可信度。

對雲端架構師來說，公開展示自己的技術知識，是目前最有效的個人品牌策略之一。

策略四：專精一個垂直領域

與其成為「什麼都懂一點」的泛用型架構師，不如在某個特定領域（如金融雲、醫療雲、AI 基礎設施）成為領域專家。垂直深度往往比水平廣度更能帶來薪資溢價。

雲端架構師要有效提升薪資，最快的方法是：取得 Professional 等級認證（立即增加談判籌碼）、記錄可量化的成果（降低帳單、提升穩定性的具體數字）、以及在特定垂直產業建立深度專業。這三個動作同步進行，年薪提升 30%～50% 是可預期的。

雲端架構師薪水 FAQ 常見問題

Q1：沒有資工背景可以成為雲端架構師嗎？

A： 完全可以。許多優秀的雲端架構師來自非資工背景，包括統計、企管、甚至人文科系。關鍵是你願不願意主動考取認證、累積實戰經驗。台灣確實有很多成功案例，從統計系、商科出身轉職為 GCP 架構師的人並不少見。重要的是要有系統地學習：先從 GCP Associate Cloud Engineer 認證入門，邊學邊做，循序漸進。

Q2：雲端架構師和 DevOps 工程師的薪水哪個比較高？

A： 在台灣市場，雲端架構師的平均薪資略高於 DevOps 工程師，尤其在資深等級差距更明顯。因為 DevOps 工程師雲端架構師月薪區間約 8 萬～20 萬，DevOps 工程師約 7 萬～16 萬。不過兩者界線越來越模糊，很多公司的雲端架構師職位本身就包含 DevOps 工作，具備 CI/CD pipeline 設計能力的架構師，薪資競爭力會更強。

Q3：GCP 認證和 AWS 認證，哪個對薪資幫助更大？

A： 以台灣市場來看，AWS 認證的市場認知度略高，職缺數量也稍多；但 GCP 認證在特定產業（尤其是媒體、廣告科技、AI 應用）有明顯優勢，而且考試難度相對較高，持有者的含金量也相對較高。最理想的狀況是同時持有 GCP Professional Cloud Architect + AWS Solutions Architect，雙認證的組合在談薪水時最有底氣。

Q4：轉職雲端架構師大約需要多久？

A： 有技術基礎（如系統工程師、網路管理員）的人，通常 1～2 年可以完成轉型；從非技術職位（如 IT Presales、PM）轉職則需要 2～3 年。關鍵不是時間長短，而是「是否有機會接觸真實的雲端專案」。即使沒有，也可以透過 Google 官方的 Cloud Skills Boost 平台刷題目、做 Lab，累積實戰感。如果你覺得自學太慢了，可以加入雲端架構師養成班，藉由完整的學習和實作，加快考取證照並成功轉職的速度。

Q5：台灣雲端架構師的未來發展前景如何？

A： 非常樂觀。隨著台灣企業數位轉型加速、AI 應用崛起（Vertex AI、Gemini API 的整合需求），以及半導體產業上雲趨勢持續，雲端架構師的需求預計在未來 5 年內仍持續成長。特別是具備 AI/ML 基礎設施規劃能力的架構師，將成為市場上最搶手的人才之一。

結論：雲端架構師是值得投資的職涯方向

雲端架構師是目前台灣 IT 市場薪資成長最快的職位之一，年薪 120 萬到 250 萬的機會對有認證、有實戰的人來說相當實際。轉職門檻雖然存在，但並非不可跨越——只要系統性學習、取得認證、累積可量化成果，即使是非本科背景，也能在 2～3 年內完成轉型。

我自己從完全不懂 GCP，到成為雲端架構師、再到現在透過「東東 GCP 教學」分享這些知識，走了超過十年。這條路不一定要走那麼久——因為現在的學習資源、認證體系、社群支持都比十年前豐富太多了。

如果你對轉職雲端架構師有興趣，或者已經在雲端領域工作但想要加速薪資成長，歡迎來 dongdonggcp.com 看看我整理的 GCP 實戰教學，或是訂閱「東東 GCP 教學」的 YouTube 頻道，我們一起在雲端世界找到自己的位置。

如果還有什我疑問，也可以加 Line: @754xlakm 直接與我聯絡，透過線上諮詢來了解你的情況，並提供你適合的發展方向。

The post 雲端架構師薪水完整指南：薪資行情、加薪技巧與轉職攻略 first appeared on 東東 GCP 教學 - GCP 實戰講師.

當 Mac 電腦提示你更新作業系統（OS）時，它會先把整個安裝檔下載到你的硬碟裡。這個安裝檔通常非常大，可能有 12GB 到 15GB 左右，就像你下載了一部超高畫質的電影檔案一樣佔空間。下載完成後，系統才會開始執行安裝程序，但如果這時候硬碟空間不夠，安裝就會卡住無法進行。

問題是這個已經下載好的安裝檔不會自動消失，它會一直待在你的硬碟裡佔用空間。要把它刪除其實很簡單，你可以打開 Finder（就是 Mac 上那個藍白相間、笑臉圖案的檔案管理程式），然後在上方選單列點選「前往」，接著選「應用程式」這個資料夾。進去之後，你會看到一個名稱類似「安裝 macOS Sonoma」或「Install macOS」開頭的檔案，檔案圖示通常是一個彩色的山景或地標圖案，這就是那個占空間的安裝檔。

找到這個安裝檔之後，你可以直接把它拖到右下角的垃圾桶圖示，或者在檔案上按右鍵選「移到垃圾桶」。不過光是把檔案丟到垃圾桶還不夠，因為垃圾桶裡的東西還是會佔用硬碟空間，就像你家的垃圾桶雖然裝了垃圾，但垃圾還在房子裡一樣。所以最後一個步驟是要「清空垃圾桶」，在垃圾桶圖示上按右鍵，選擇「清空垃圾桶」，這樣才會真正把檔案從硬碟上刪除，釋放出那 12-15GB 的空間。

如果你之後還是想更新系統，建議先騰出至少 30-40GB 的可用空間再開始，因為安裝過程不只需要放安裝檔，還需要額外的空間來進行安裝作業。這樣才不會再遇到下載完卻裝不了的窘境。

The post Mac 叫我更新作業系統，下載完安裝檔，結果空間不足不能安裝，結果硬碟快滿了，怎麼辦？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

當我們在瀏覽器輸入 www.youtube.com 按下 Enter 鍵時，網頁幾乎瞬間就載入了。但你有沒有想過，電腦是怎麼知道要連到哪台伺服器的呢？這背後的功臣就是 DNS（Domain Name System，網域名稱系統）。DNS 就像網際網路的電話簿，將我們容易記憶的網域名稱轉換成電腦能理解的 IP 位址。今天我們就來深入了解 DNS 到底是什麼、它如何運作，以及為什麼它對我們的上網體驗如此重要。

DNS 的基本概念

什麼是 DNS？

DNS 全名為 Domain Name System，中文稱為「網域名稱系統」。簡單來說，DNS 是一個分散式的資料庫系統，負責將人類容易記憶的網域名稱（例如 facebook.com）轉換成電腦網路中實際使用的 IP 位址（例如 157.240.1.35）。想像一下，如果沒有 DNS，我們每次想上 Facebook 就得記住一串數字，那上網會變得多麼麻煩啊！

我們可以把 DNS 比喻成一本巨大的通訊錄。當你想打電話給朋友時，你只需要記住他的名字，然後在通訊錄裡找到對應的電話號碼。DNS 做的就是類似的事情，只不過它查找的是網站的「電話號碼」——也就是 IP 位址。

這套系統採用階層式架構，從全球的根伺服器開始，一層層往下延伸到各個網域的權威伺服器。這種設計讓 DNS 能夠處理數十億個網域名稱，同時保持高效率的查詢速度。更重要的是，DNS 是分散式的，沒有單一故障點，這讓整個網際網路更加穩定可靠。

為什麼需要 DNS？

你可能會問，為什麼不直接使用 IP 位址就好？原因很簡單：IP 位址對人類來說太難記了。試想一下，如果你要記住常用的十個網站的 IP 位址，像是 142.250.185.46（Google）、13.107.42.14（Microsoft）等等，是不是很容易搞混？而且 IP 位址可能會改變，但網域名稱可以保持不變，這為網站管理者提供了靈活性。

DNS 的出現解決了這個問題。它讓我們可以用有意義、容易記憶的名稱來訪問網站。當網站需要更換伺服器或 IP 位址時，只需要更新 DNS 記錄就好，使用者完全不會察覺到任何變化。這就像你的朋友換了手機號碼，只要更新通訊錄就能繼續聯絡，不需要記新的號碼。

此外，DNS 還支援負載平衡 (Load Balance) 和故障轉移 (Failover) 功能。一個網域名稱可以對應到多個 IP 位址，當某台伺服器故障時，DNS 可以自動將流量導向其他正常運作的伺服器。這對於大型網站來說至關重要，確保了服務的高可用性。

DNS 的運作原理

DNS 查詢的完整流程

當我們在瀏覽器輸入一個網址時，DNS 查詢就開始了。這個過程看似簡單，實際上涉及多個步驟和不同的伺服器協作。讓我們一步步來看看當你輸入 www.example.com 時會發生什麼事。

首先，你的電腦會檢查本地快取，看看最近是否查詢過這個網域。如果有，就直接使用快取中的 IP 位址，這樣可以節省時間。如果沒有，查詢請求會被送到你的 ISP（網際網路服務供應商）提供的 DNS 解析器，或者你手動設定的 DNS 伺服器。

DNS 解析器收到請求後，它會先查看自己的快取。如果沒有找到，它就會開始一系列的查詢過程。首先，它會向根名稱伺服器詢問：「誰知道 .com 網域的資訊？」根伺服器會回覆：「你去找 .com 的 TLD 伺服器吧。」

接著，解析器向 TLD 伺服器詢問：「example.com 的權威伺服器在哪裡?」TLD 伺服器會提供權威名稱伺服器的位址。

最後，解析器向 example.com 的權威名稱伺服器查詢 www.example.com 的 IP 位址。權威伺服器回覆正確的 IP 位址後,解析器會將這個結果快取起來,並回傳給你的電腦。整個過程通常在幾十毫秒內完成,我們幾乎感覺不到任何延遲。

下圖是完整流程：

DNS 解析的四大伺服器

DNS 系統的運作依賴四種主要的伺服器類型,每一種都扮演著不可或缺的角色。了解這些伺服器的功能,可以幫助我們更深入理解 DNS 的工作機制。

遞迴解析器(Recursive Resolver)

遞迴解析器是 DNS 查詢的起點,也是最接近使用者的那一層。當你的電腦需要解析一個網域名稱時,它會將請求發送給遞迴解析器。這個解析器就像是一個勤奮的圖書館員,它會代替你去查找所需的資訊。

遞迴解析器的特點是它會「遞迴」地進行查詢,也就是說,它會一直追問下去直到找到答案。它會記住你查詢過的結果,下次有人查詢相同的網域時,就能直接提供答案,不需要再跑一遍完整的查詢流程。大多數 ISP 都會提供自己的遞迴解析器,但你也可以使用像 Google Public DNS 或 Cloudflare 這樣的公共 DNS 服務。

根名稱伺服器(Root Nameserver)

根名稱伺服器位於 DNS 階層架構的最頂端。全球只有 13 組根伺服器(標記為 A 到 M),但實際上透過任播技術,每組根伺服器在世界各地都有多個實體伺服器副本,總數超過數百台。

根伺服器不會直接告訴你某個網站的 IP 位址,它們的工作是指引查詢到正確的 TLD 伺服器。當遞迴解析器詢問 www.example.com 的位址時,根伺服器會說:「我不知道具體位址,但我知道誰負責 .com 網域,你去問它。」這就像是總機告訴你應該轉接到哪個部門。

TLD 名稱伺服器

TLD(Top-Level Domain)名稱伺服器負責管理頂級網域,像是 .com、.org、.tw 等等。每個 TLD 都有專門的名稱伺服器來處理該網域下的查詢。當你查詢 example.com 時,.com 的 TLD 伺服器會告訴你哪個權威名稱伺服器負責 example.com 這個網域。

TLD 伺服器維護著該頂級網域下所有註冊網域的記錄。它們就像是各個城市的資訊中心,知道城市裡每條街道的負責單位。台灣的 .tw 網域就是由 TWNIC(台灣網路資訊中心)負責管理其 TLD 伺服器。

權威名稱伺服器(Authoritative Nameserver)

權威名稱伺服器是 DNS 查詢鏈的最後一站,它擁有特定網域的最終、最權威的資訊。如果說前面的伺服器都在指路,那麼權威名稱伺服器就是真正知道答案的那個人。

當查詢到達 example.com 的權威名稱伺服器時,它會查看自己的記錄,然後回覆:「www.example.com 的 IP 位址是 93.184.216.34。」這個答案就會一路傳回給遞迴解析器,最終到達你的電腦。網域的擁有者可以透過 DNS 管理介面來設定和更新權威名稱伺服器上的記錄。

DNS 記錄類型有哪些？

A 記錄與 AAAA 記錄

DNS 記錄是儲存在權威名稱伺服器上的資料,定義了網域名稱與各種資源之間的對應關係。最基本也最重要的是 A 記錄和 AAAA 記錄。

A 記錄(Address Record)是最常見的 DNS 記錄類型,它將網域名稱對應到 IPv4 位址。例如,www.example.com 的 A 記錄可能指向 93.184.216.34。當你在瀏覽器輸入這個網址時,DNS 會查詢 A 記錄來找到對應的伺服器。

AAAA 記錄(也讀作「quad-A」)則是 A 記錄的 IPv6 版本。隨著 IPv4 位址逐漸耗盡,IPv6 變得越來越重要。AAAA 記錄將網域名稱對應到 128 位元的 IPv6 位址,例如 2606:2800:220:1:248:1893:25c8:1946。現代網站通常會同時設定 A 和 AAAA 記錄,以支援使用不同 IP 協定的使用者。

CNAME、MX 與其他常見記錄

除了 A 和 AAAA 記錄,還有許多其他類型的 DNS 記錄服務於不同目的。CNAME 記錄(Canonical Name)用於建立別名。例如,你可以設定 www.example.com 為 example.com 的 CNAME,這樣兩個網址都會指向同一個地方。這在管理多個子網域時特別方便。

MX 記錄(Mail Exchange)指定了接收電子郵件的郵件伺服器。當有人寄信到 user@example.com 時,發送方的郵件伺服器會查詢 example.com 的 MX 記錄,找出應該將郵件送到哪台伺服器。MX 記錄還包含優先順序,讓你可以設定主要和備用郵件伺服器。

TXT 記錄可以儲存任意文字資訊,常用於網域驗證、SPF(Sender Policy Framework)設定來防止郵件欺騙,或是 DKIM 數位簽章。NS 記錄(Name Server)則指定了該網域使用哪些名稱伺服器。還有 PTR 記錄用於反向 DNS 查詢,SOA 記錄儲存網域的管理資訊等等。

DNS 的快取 (暫存) 機制

瀏覽器與作業系統快取

為了提升效能和減少網路流量,DNS 系統在多個層級實作了快取機制。最接近使用者的快取存在於瀏覽器和作業系統中。當你訪問一個網站時,瀏覽器會將 DNS 查詢結果儲存在記憶體中。下次你再訪問同一個網站時,瀏覽器就能直接使用快取的 IP 位址,不需要再進行 DNS 查詢。

每個瀏覽器都有自己的 DNS 快取管理機制。Chrome 瀏覽器的快取通常會保留數分鐘到數小時,你可以在網址列輸入 chrome://net-internals/#dns 來查看和清除快取。Firefox、Safari 等瀏覽器也都有類似的功能。

作業系統層級的 DNS 快取則由系統的 DNS 客戶端服務管理。Windows、macOS 和 Linux 都會維護自己的 DNS 快取。當瀏覽器的快取過期或沒有找到記錄時,就會詢問作業系統的快取。這層快取通常保留時間較長,能夠讓多個應用程式共享 DNS 查詢結果。

TTL 生存時間的重要性

TTL(Time To Live,生存時間)是 DNS 記錄中的一個重要參數,它決定了這筆記錄可以被快取多久。TTL 以秒為單位,例如 TTL=3600 表示這筆記錄可以被快取一小時。當 TTL 到期後,快取會被視為過期,下次查詢時就需要重新向權威伺服器取得最新資料。

設定適當的 TTL 值需要在效能和靈活性之間取得平衡。較長的 TTL(例如 86400 秒,即 24 小時)可以減少 DNS 查詢次數,降低伺服器負載,提升網站存取速度。但缺點是,當你需要更改 IP 位址時,更新會較慢生效,因為舊的記錄可能還在全球各地的快取中。

較短的 TTL(例如 300 秒,即 5 分鐘)讓你能快速更新 DNS 記錄,這在伺服器遷移或故障轉移時很有用。但代價是會產生更多的 DNS 查詢流量。一般建議是,在正常運作時使用較長的 TTL,而在計劃進行變更前幾天先降低 TTL 值,這樣變更時就能更快生效。

常見的 DNS 問題與解決方法

DNS 解析失敗怎麼辦？

有時候我們會遇到網頁無法開啟的情況,錯誤訊息顯示「DNS_PROBE_FINISHED_NXDOMAIN」或「找不到伺服器」。這通常是 DNS 解析出現問題。首先,你可以嘗試清除 DNS 快取。在 Windows 上,開啟命令提示字元並執行 ipconfig /flushdns;在 macOS 上使用 sudo dscacheutil -flushcache;Linux 用戶則可以重啟 systemd-resolved 服務。

如果清除快取後問題仍然存在,可能是你的 DNS 伺服器本身出了問題。這時候切換到其他 DNS 伺服器通常能解決問題。你也可以檢查網路連線是否正常,嘗試 ping 8.8.8.8 這樣的 IP 位址,如果能 ping 通但網頁打不開,就確認是 DNS 問題。

有時候問題出在網域本身。網域可能過期未續約,或是 DNS 記錄設定錯誤。如果你是網域管理者,可以使用 nslookup 或 dig 這類工具來檢查 DNS 記錄是否正確。線上工具如 DNS Checker 可以幫你從全球不同地點檢查 DNS 傳播狀況。Google 自己也有 Google Admin Toolbox 可以用喔！

如何更換 DNS 伺服器？

更換 DNS 伺服器是改善上網速度和安全性的簡單方法。在 Windows 10/11 上,進入「設定」>「網路和網際網路」>「乙太網路」或「Wi-Fi」,點擊你的連線,選擇「編輯 IP 設定」,然後手動輸入 DNS 伺服器位址。

macOS 用戶可以前往「系統設定」>「網路」,選擇你的網路連線,點擊「進階」,然後在「DNS」分頁中新增伺服器。你可以新增多個 DNS 伺服器,系統會依序嘗試使用它們。

在路由器層級更改 DNS 設定會影響連接到該路由器的所有裝置。登入路由器管理介面(通常是 192.168.1.1 或 192.168.0.1),找到 WAN 或網際網路設定,將 DNS 伺服器從「自動取得」改為「手動設定」,然後輸入你想使用的 DNS 伺服器位址。更改後記得重啟路由器讓設定生效。

公共 DNS 服務推薦

Google DNS、Cloudflare DNS 等選擇

市面上有許多優質的公共 DNS 服務可供選擇。Google Public DNS 是最早也是最受歡迎的公共 DNS 之一,主要 DNS 位址是 8.8.8.8 和 8.8.4.4(IPv4),或 2001:4860:4860::8888 和 2001:4860:4860::8844(IPv6)。Google DNS 以穩定性和全球覆蓋率著稱,在世界各地都有伺服器節點。

Cloudflare 的 1.1.1.1 是後起之秀,主打速度和隱私。Cloudflare 承諾不會記錄使用者的查詢資料,並在 24 小時後刪除所有日誌。他們的 DNS 服務在許多效能測試中都名列前茅,備用伺服器是 1.0.0.1。Cloudflare 還提供 1.1.1.1 for Families 服務,可以過濾惡意軟體和成人內容。

Quad9(9.9.9.9)注重安全性,會封鎖已知的惡意網域,保護你免受網路釣魚和惡意軟體威脅。OpenDNS(208.67.222.222 和 208.67.220.220)提供家長控制功能,可以過濾不適當的內容。台灣用戶可以考慮使用 HiNet 的 DNS(168.95.1.1 和 168.95.192.1),因為地理位置較近,理論上延遲會較低。

選擇 DNS 服務時,可以考慮速度、隱私政策、安全功能和可靠性。你也可以使用 DNS Benchmark 這類工具來測試不同 DNS 服務在你所在位置的實際表現,選擇最適合自己的那一個。

DNS 安全性議題

DNS 劫持與中間人攻擊

DNS 系統雖然便利,但也存在安全隱憂。DNS 劫持(DNS Hijacking)是指攻擊者透過修改 DNS 設定,將你導向錯誤的 IP 位址。這可能發生在你的路由器、電腦或 ISP 的 DNS 伺服器上。攻擊者可能將你導向偽造的銀行網站,竊取你的帳號密碼和個人資料。

DNS 快取污染(DNS Cache Poisoning)是另一種常見攻擊。攻擊者向 DNS 伺服器發送偽造的回應,讓伺服器快取錯誤的記錄。當其他使用者查詢這個網域時,就會得到錯誤的 IP 位址。這種攻擊可以影響大量用戶,而且很難被發現。

中間人攻擊 (Man-in-the-Middle) 利用 DNS 查詢未加密的特性。攻擊者可以攔截你的 DNS 查詢,並回傳偽造的回應。傳統的 DNS 查詢是明文傳輸的,任何人都能看到你查詢了哪些網站,這也是隱私方面的問題。要防範這些攻擊,可以使用有信譽的 DNS 服務、定期檢查路由器設定、保持系統更新,並注意網站的 SSL 憑證是否正確。

DNSSEC 是什麼？

DNSSEC (DNS Security Extensions) 是為了解決 DNS 安全問題而開發的一套擴充協定。它透過數位簽章來驗證 DNS 回應的真實性,確保你收到的 DNS 記錄確實來自權威伺服器,而且沒有被竄改過。

DNSSEC 的運作原理類似於 HTTPS 的數位憑證。網域擁有者會用私鑰對 DNS 記錄進行簽章,而查詢者可以用公鑰來驗證簽章。每一層的 DNS 伺服器都會驗證下一層的簽章,形成一條信任鏈,從根伺服器一直延伸到目標網域。

雖然 DNSSEC 提供了更好的安全性,但它的部署還不夠普及。啟用 DNSSEC 需要額外的設定和管理,而且會增加 DNS 回應的大小和處理時間。不過,越來越多的網域開始支援 DNSSEC,尤其是政府機關和金融機構的網站。GCP 的 Cloud DNS 也有提供 DNSSEC 的功能，說明文件在此。

除了 DNSSEC,DNS over HTTPS(DoH)和 DNS over TLS(DoT)也是提升 DNS 安全性的技術。它們透過加密連線來傳輸 DNS 查詢,防止被竊聽或竄改。Firefox 和 Chrome 等現代瀏覽器都已經支援 DoH,讓你的 DNS 查詢更加私密和安全。

結論

DNS 是網際網路基礎建設中不可或缺的一部分,它將複雜的 IP 位址轉換成我們容易記憶的網域名稱,讓上網變得簡單直覺。透過本文,我們了解了 DNS 的基本概念、運作原理、各種記錄類型,以及快取機制。我們也探討了常見的 DNS 問題和解決方法,介紹了值得信賴的公共 DNS 服務,並討論了 DNS 的安全性議題。

雖然 DNS 的運作過程複雜,涉及多層伺服器的協作,但對一般使用者來說,它就是默默在背後工作,讓我們能順暢地瀏覽網頁、收發郵件、使用各種網路服務。當你遇到連線問題時,現在你知道如何從 DNS 的角度來診斷和解決。選擇適合的 DNS 服務,注意安全性,就能享受更快速、更安全的上網體驗。

DNS 技術還在不斷演進,從 DNSSEC 到 DoH,都是為了讓這個系統更安全、更有效率。作為網路使用者,了解 DNS 的基本知識能幫助我們更好地掌控自己的上網體驗,也能在遇到問題時知道該如何應對。希望這篇文章能讓你對 DNS 有更深入的認識!

常見問題解答

Q1: DNS 和 IP 位址有什麼差別?

IP 位址是網路上每台裝置的實際地址,就像門牌號碼一樣。DNS 則是將容易記憶的網域名稱(如 google.com)轉換成 IP 位址的系統。簡單說,DNS 是翻譯機,IP 位址是目的地。我們輸入網域名稱,DNS 幫我們找到對應的 IP 位址,然後電腦才知道要連到哪台伺服器。

Q2: 更換 DNS 能提升網速嗎?

可以,但效果有限。更換到速度較快的 DNS 服務可以縮短網域解析時間,讓網頁開始載入得更快一點。不過 DNS 查詢通常只佔整個連線過程的一小部分,而且有快取機制。真正影響網速的主要是你的網路頻寬、伺服器距離和網站本身的效能。換 DNS 比較明顯的好處是提升穩定性和安全性。

Q3: 為什麼更改 DNS 設定後還是連不上網?

可能有幾個原因:首先,DNS 記錄有 TTL 設定,舊的記錄可能還在快取中,需要等待一段時間或手動清除快取。其次,可能是你輸入的 DNS 伺服器位址有誤,仔細檢查數字是否正確。也可能是網路連線本身有問題,或是防火牆阻擋了 DNS 查詢。試著用其他裝置測試,或暫時改回自動取得 DNS 來排除問題。

Q4: 什麼是 DNS 污染?如何避免?

DNS 污染是指 DNS 伺服器的快取被植入錯誤或惡意的記錄,導致使用者被導向錯誤的網站。這可能是遭受攻擊,或是某些地區刻意的網路管制。要避免 DNS 污染,可以使用可信賴的公共 DNS 服務如 Cloudflare 或 Google DNS,啟用 DNSSEC 驗證,或使用 DoH/DoT 加密 DNS 查詢。定期清除 DNS 快取也有幫助。

Q5: 企業需要架設自己的 DNS 伺服器嗎?

這取決於企業規模和需求。大型企業通常會架設內部 DNS 伺服器來管理內部網域和提供更好的控制。自己的 DNS 伺服器可以加快內部網域的解析速度,提供客製化的 DNS 記錄,並增強安全性。但小型企業可能不需要,使用網域註冊商提供的 DNS 服務就足夠了。架設 DNS 伺服器需要專業知識和持續維護,要考慮成本效益。

The post DNS 是什麼？就是把網址轉成 IP，你的手機和電腦才能找到網站 first appeared on 東東 GCP 教學 - GCP 實戰講師.