Google PCNE: 網路自動化、治理與成本營運 — 學習指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

屬於 Google Professional Cloud Network Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Google Cloud 上，網路自動化、治理與成本營運是密不可分的學問，它們共同決定了您的網路在大規模運作時的可靠性、安全性及經濟效益。有效的實踐結合了結構良好的資源階層、最低權限 IAM、基礎設施即程式碼 (IaC) 以及事件驅動的工作流程，並以清晰的預算、配額和可稽核性作為基礎。最終目標是實現可預測的資源佈建、最少的人工變更、可供佐證的合規性證據，以及透明的網路單位經濟效益。

治理與存取控制

• 資源階層

  • Organization → Folders → Projects 是權限繼承和政策護欄的控制平面。將生產環境和非生產環境放在不同的資料夾中，以隔離政策和配額。在 VPC、子網路、路由器、轉送規則和執行個體上使用標籤，以進行成本分攤和資源定位。
  • Shared VPC 將路由和連線能力整合在一個主機專案中，同時將運算資源委派給服務專案。僅分享每個服務專案所需的子網路，以遵循明確公開網路的原則，並減少非預期的路由暴露。

• IAM 與最低權限

  • 將網路管理與安全管理分開。Compute Network Admin 授予對網路建構的完全控制權以及對防火牆規則的唯讀存取權，而 Security Admin 則管理防火牆規則和 SSL 憑證。這種分離避免了權限過大的操作員，並與變更控制保持一致。
  • 授予目標明確的角色：
    • 若要修改防火牆規則，請在 Shared VPC 上使用 Security Admin。
    • 若要管理 VLAN attachment 和其他核心網路資源，使用 Compute Network Admin 是合適的。
    • 對於針對特定資源的自動化，盡可能授予資源層級的權限，而非專案範圍的角色，或建立一個僅限於必要權限的自訂角色。
  • 優先使用服務帳戶模擬 (impersonation) 和短期權杖，而非永久金鑰。盡可能透過組織政策禁止建立服務帳戶金鑰。使用 Workload Identity Federation 為地端或多雲自動化完全移除金鑰。
  • 對於資料平面的任務，遵循最低權限存取原則。例如，一個讀取 Cloud Storage 的作業僅需目標儲存桶的 storage object viewer 權限，而非專案的廣泛 editor 權限。

• 組織政策

  • 預設強制 VM「無外部 IP」；使用 Private Google Access 和 Cloud NAT 來存取 Google API，而無需公開位址。
  • 將對等互連 (peering) 和外部共享限制在核准的模式內（例如，限制 VPC peering 設定以避免擴散）。
  • 限制服務帳戶金鑰的建立和使用，以限制憑證擴散。
  • 失敗模式與權衡取捨：
    • 在資料夾層級過於寬鬆的繼承角色可能會悄悄地授予對許多專案的寫入權限。使用有效權限分析來審查角色綁定。
    • 在未規劃 Private Google Access 和 NAT 的情況下，阻止 VM 擁有外部 IP，會在呼叫 Google 服務時導致服務中斷。
    • 在未重構那些假設使用自動子網路的範本的情況下，將 VPC 從自動模式轉換為自訂模式會破壞部署；此後應明確參照自訂子網路。

自動化、IaC 與事件驅動營運

• 使用 Terraform 實現基礎設施即程式碼 (IaC)

  • 採用模組化設計：每個基礎元件（VPC、子網路、防火牆、Cloud Router、Cloud NAT、interconnect attachment）一個模組，然後組合出環境堆疊。對模組進行版本控制，並在使用中的堆疊中鎖定版本，以控制推出。
  • 將狀態遠端儲存並加上鎖定（例如，透過後端模式使用 Cloud Storage 搭配 Dynamo 風格的鎖定），以防止並行變更。加密並備份狀態；將狀態視為敏感資料。
  • 差異管理：
    • 透過 CI 中的 pull request 和 terraform plan 來強制執行變更，以揭示預期與實際之間的差異。執行排程的差異偵測 (plan -detailed-exitcode)，並在出現差異時發出警報。
    • 避免在生產環境中進行臨時的 gcloud 變更；如果必須進行緊急修復，應立即記錄並在程式碼中進行核對。
  • 冪等性與護欄：始終進行 plan、review 和 apply。使用目標性的 apply 來最小化爆炸半徑。使用變數驗證和政策即程式碼（例如 Sentinel 或 OPA）來阻止反模式，如重疊的 CIDR 或開放的防火牆。

• gcloud、API 與工作流程

  • 使用 gcloud 和 REST 執行低延遲的營運任務，但應將它們包裝在可重複執行的腳本中。透過重試和指數退避來處理最終一致性和 API 速率限制。
  • 事件驅動營運：
    • 使用 Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions 來自動化例行任務，例如配額檢查、NAT 使用率審核或防火牆日誌取樣。
    • 將 Admin Activity 和 Data Access 日誌串流到 Pub/Sub，以觸發護欄工作流程（例如，自動還原未經授權的防火牆規則變更）。
  • 範例片段

    • 授予角色：

undefined

- 建立一條路由至 Google API，以繞過指向 NGFW 的預設路由：
  -

undefined

• 營運陷阱
  • 當多個 pipeline 管理共享資源（例如，在一個共用 VPC 中的防火牆）時，競爭條件會導致狀態不穩定 (flapping)。使用所有權慣例和資料夾範圍的 pipeline。
  • 在高並行性下，API 的不穩定會觸發配額錯誤；應按區域和資源類型對操作進行節流和批次處理。

成本、配額與容量管理

• 配額與 API 限制

  • 追蹤每個專案和每個地區的配額（位址、轉送規則、防火牆規則、互連附件、路由器）。自動化配額監控，並在新環境上線前申請提高配額。將預檢的配額檢查整合到 CI 中，以實現快速失敗。
  • 透過以下方式進行大規模佈建：
    • 區域分片 (Regional sharding)（每個地區建立資源，以避免區域配額的競爭）。
    • 預先分配 (Preallocation)（在尖峰事件前預留位址並設定路由器）。
    • 分階段推出 (Staged rollouts)（建立、驗證，然後再掛載後端）。

• 輸出流量與拓撲的經濟效益

  • VPC 內部跨地區的流量會產生地區間的輸出流量成本。當延遲和成本很重要時，將需要互相通訊的工作負載放在同一個地區，或是在地區間複製資料。
  • 對於靠近 us-east1 和 europe-west1 的使用者，單一 VPC 搭配區域子網路可以啟用私有的 RFC1918 通訊，將 NAT 和對等互連的開銷降到最低，同時也讓政策和路由變得簡單。
  • 使用 VPC Network Peering 在專案或部門之間建立低開銷的連線，它沒有 NAT 也沒有可轉移的路由；請保持 CIDR 不重疊。使用獨立的 VPC 來隔離那些絕對不能互相通訊的部門。
  • Cloud CDN 可以減少 HTTP(S) 流量的輸出並改善延遲；全域 HTTP(S) 負載平衡器是 CDN 的控制平面。網路負載平衡器無法改善 Web 應用程式的全域延遲，因為它缺乏邊緣分發和快取功能。
  • 明智地選擇互連方式：在主機專案中使用帶有 VLAN 附件的 Dedicated Interconnect，可以集中管理並降低大型、共享地端連線的每個專案成本。Cloud VPN 搭配 Cloud Router 適合在組織之間建立快速、加密的連線，之後可以再演進為互連。

• 成本分配、預算與預測

  • 為所有網路資源加上部門、環境和成本中心的標籤。將帳單資料匯出到 BigQuery，並推導出單位成本（例如，每個服務的輸出流量 $/GB）。
  • 在專案、資料夾或標籤的層級建立預算。將警示傳送到 Pub/Sub，並串接到 ChatOps 或 Cloud Run 回應器。自動化超支時的應對措施（例如，減少日誌取樣或縮減非關鍵測試環境的規模）。
  • 最佳化輸出流量：
    • 優先使用 Private Google Access 和 Cloud NAT，而非外部 IP，以控制輸出路徑並集中化帳單。
    • 對於強制通道 (forced-tunnel) 拓撲，為 Google API 新增自訂路由到預設的網際網路閘道，或為地端設定 Private Google Access，以避免流量透過第三方防火牆形成髮夾彎 (hairpinning)。
    • 透過分析 VPC Flow Logs 和負載平衡器日誌來預測容量；並與季節性因素建立關聯。在尖峰期來臨前，適當調整 NAT 閘道和互連的容量。

可稽核性與卓越營運

• 記錄與證據

  • Cloud Audit Logs：
    • 「管理員活動記錄」會擷取對 VPC、路由、防火牆、路由器和負載平衡器的控制層變更；此功能會永久開啟。請集中保留記錄，並在需要時使用 CMEK 將其路由到一個專門的安全性專案。
    • 「資料存取記錄」對於網路 API 來說可能量很大；請選擇性地啟用，並套用取樣或接收器 (sinks)。
  • VPC Flow Logs 和防火牆規則記錄為事件應變和合規性提供資料層的證據。請依據所需的保留期限儲存，並使用 BigQuery 建立索引以供調查。
  • 變更記錄：要求每個網路變更都必須源自 IaC，並附上不可變的計畫產物 (plan artifact) 和工單參考。對於例外的を手動變更，應在中央登錄檔中擷取 gcloud 指令、操作人員、時間戳記和理由。

• 安全憑證與自動化風險控管

  • 消除長期有效的服務帳戶金鑰。使用 IAM Conditions 依資源、時間或 IP 來限定自動化的範圍。對於高風險權限（例如 compute.firewalls.update、compute.routers.updateBgpPeer），應使用核准工作流程加以保護。
  • 對 CI/CD 套用最低權限原則，使用每個環境專屬的服務帳戶，並頻繁輪替權杖。在存在資料外洩風險的地方，使用 VPC Service Controls 來保護服務邊界。

• Runbook、生命週期與持續改進

  • 維護日常操作的 Runbook：將專案加入 Shared VPC、建立 VPC peering、使用 IKEv2 建立 Cloud VPN、將預覽中的 Cloud Armor 規則升級為強制執行。
  • 定義生命週期政策：
    • 沙箱 → 預備環境 → 生產環境的升級流程，使用相同的 Terraform 模組和區域特定的變數。
    • 用於安全地移除 peering、NAT 和路由的除役 playbook。
  • 持續改進：
    • 事件後檢討應回饋到模組中（例如，新增預設拒絕的 egress 規則並搭配明確的允許清單，或預設啟用 NAT 記錄）。
    • 定期檢視組織政策、標籤和預算，檢查是否偏離預期狀態。

實務問題情境

Contoso Retail 在北美和歐洲營運。使用者和服務主要在 us-east1 和 europe-west1 中運行。資安部門要求預設路由指向第三方 NGFW、VM 上不能有外部 IP，以及集中式的地端連線。公司還需要按部門清晰地分攤成本，並建立自動化的防護機制。

1. 建立治理與拓撲

• 建立一個 Shared VPC 主機專案，內含一個 VPC 和位於 us-east1 及 europe-west1 的兩個區域性子網路。理由：單一 VPC 搭配區域性子網路，可讓區域之間透過簡單的路由和政策直接進行 RFC1918 通訊，從而將每個專案的開銷降至最低。
• 僅將必要的子網路分享給三個服務專案（行銷、供應鏈、財務）。理由：子網路層級的分享限制了路由和防火牆的曝險，同時保留了集中控管。
• 為必須隔離的舊有財務系統建立一個獨立的 VPC；僅在需要時與行銷和供應鏈專案進行對等互連 (peer)。理由：VPC peering 為這兩個部門提供了低延遲的私有連線，同時保持與財務系統的隔離。

2. 設定在沒有公用 IP 的情況下安全存取 Google 服務

• 在所有共享子網路上啟用 Private Google Access。理由：沒有外部 IP 的執行個體可以私下存取 Google API。
• 由於預設路由指向 NGFW，因此新增一條指向預設網際網路閘道的自訂靜態路由，目的地為 199.36.153.8/30。理由：確保對 Google API 的呼叫不會經過防火牆形成髮夾彎 (hairpin)，從而減少延遲並避免單一壅塞點。

3. 集中化地端連線

• 在 Shared VPC 主機專案中部署 Dedicated Interconnect 和 VLAN attachments，並在每個區域連接到一個 Cloud Router。理由：集中化的互連可降低成本和重複的營運工作；Cloud Router 為未來的擴展提供動態路由。
• 將 Compute Network Admin 權限授予網路操作人員，並將 Security Admin 權限授予資安團隊。理由：強制執行最低權限和職責分離原則；網路管理員未經資安團隊批准不得變更防火牆。

4. 自動化佈建與防護機制

• 為 VPC、子網路、路由器、NAT、peering 和防火牆政策實作 Terraform 模組。將狀態檔 (state) 遠端儲存並啟用鎖定；在 CI 中透過 terraform plan 強制執行 pull-request 審查。理由：可重複、版本化的變更搭配漂移控制 (drift control)，可將服務中斷降至最低。
• 新增一條 OPA 政策，以阻擋重疊的 CIDR 和對內部子網路開放 0.0.0.0/0 的傳入流量。理由：在審查階段防止常見的錯誤配置。
• 使用 Cloud Scheduler 每天將配額檢查結果發布到 Pub/Sub；一個 Cloud Run 服務會呼叫 Service Usage API 來驗證地址、轉送規則和互連附件的可用餘裕。理由：避免因配額耗盡而導致部署失敗。

5. 優化成本並準確分攤

• 透過 Terraform 將 env、dept 和 service 標籤應用於所有網路資源。將帳務資料匯出到 BigQuery，並為每個部門定義預算，警示發送到 Pub/Sub。理由：透明的成本分攤和對費用突增的早期預警，有助於採取預防性行動。
• 使用全域 HTTP(S) 負載平衡器作為公開網站的前端，並啟用 Cloud CDN。理由：改善全球使用者的延遲，並透過在邊緣提供快取內容來減少 egress 流量。

6. 強化可稽核性與事件應變

• 將「管理員活動記錄」和「防火牆規則記錄」路由到一個使用 CMEK 的中央記錄專案。理由：防竄改的變更記錄和資料層證據可滿足合規要求。
• 對於可疑的惡意用戶端，在 HTTP(S) 負載平衡器上以預覽模式部署一條 Cloud Armor 規則，並在強制執行前檢視記錄。理由：在驗證緩解措施的同時，將對使用者的干擾降至最低。

7. 文件化與迭代

• 發布 Runbook，內容涵蓋將專案加入 Shared VPC、在行銷和供應鏈專案之間建立 VPC peering，以及為缺乏 BGP 的合作夥伴建立基於政策的 Cloud VPN。理由：標準化的執行可減少 MTTR 和操作差異。
• 在每個變更窗口後，擷取指標（部署時間、錯誤、egress $/GB、快取命中率），並將改進回饋到模組和政策中。理由：持續改進將可靠性和成本控制融入日常營運中。

← 網路可觀測性、可靠性與疑難排解 · 所有領域

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →