VPC 網路架構與設計

網路設計先從流量開始

第一次規劃 VPC，很容易直接畫子網路、填 CIDR，最後才問應用怎麼連。比較穩妥的順序剛好相反：先把流量畫清楚，再決定網路元件。

至少要回答這幾個問題：

1. 使用者從網際網路進來，還是只有內部系統會呼叫？
2. 流量是 HTTP，還是資料庫、遊戲或其他 TCP／UDP 協定？
3. 哪些服務需要跨區域，哪些必須留在特定區域？
4. 工作負載要連 Google API、合作夥伴服務，還是一般網際網路？
5. 哪一層負責允許流量？哪一層負責記錄、檢查和阻擋？

把這五題寫在架構圖旁邊，通常比先列一排產品名稱有用得多。

VPC 是全球資源，子網路是區域資源

Google Cloud 的 VPC 可以跨區域；子網路則屬於特定區域。這個設計讓同一個 VPC 裡的區域資源能透過 Google 網路互通，但也代表 IP 規劃不能只看眼前的一個區域。

Auto mode 還是 custom mode？

• Auto mode 會替各區域建立預設子網路，適合教學、實驗或快速驗證。
• Custom mode 由團隊決定區域、CIDR 與次要 IP 範圍，適合需要和地端、其他雲端或 GKE 整合的環境。

生產環境常用 custom mode，不是因為 auto mode 一定不能上線，而是企業通常需要控制位址、區域和成長空間。選擇前先確認：

• CIDR 是否會和地端、併購公司或其他雲端重疊？
• GKE Pod 與 Service 的次要範圍是否留得夠大？
• 未來新增區域時，是否還有連續且好彙總的範圍？
• 共用服務、管理環境和產品環境是否需要分開？

VPC-native GKE 會使用 alias IP ranges，讓 Pod IP 成為 VPC 可路由的位址。這不表示「看到 GKE 就勾一個選項」；Pod 數、Service 數和叢集成長仍要先估算，否則後續最先遇到的可能不是算力不足，而是 IP 用完。

跨專案連線：先決定管理邊界

Shared VPC

Shared VPC 把網路放在 host project，再讓同一個組織內的 service projects 使用其中的子網路。常見做法是：

• 網路團隊管理子網路、路由和共用安全基線。
• 應用團隊在自己的 service project 管理運算和應用資源。
• IAM 權限分開授予，避免應用部署權限順便變成改網路的權限。

它解決的是「多個團隊共用一套集中管理的網路」，不是兩個獨立 VPC 之間的轉送問題。

VPC Network Peering

Peering 適合讓兩個仍各自管理的 VPC 交換可支援的路由。它可以跨專案、跨組織，但有幾個設計限制要先接受：

• Peering 不提供傳遞性路由。A 連 B、B 連 C，不代表 A 能經過 B 到 C。
• 兩邊的子網路 IP 不應重疊。
• 防火牆政策、DNS 與服務探索仍要分別設計。
• 規模上限會調整，正式設計應查當下的 VPC 配額。

如果需求已經變成許多 VPC 的集中連線、路由交換和分段，就不要硬把 peering 串成網狀。下一課會介紹 Network Connectivity Center。

flowchart TB
  Q{"跨環境連線的核心需求？"}
  Q -->|"同組織、多團隊<br/>共用集中網路"| S["Shared VPC<br/>Host project 管網路<br/>Service projects<br/>放工作負載"]
  Q -->|"兩個獨立 VPC<br/>直接交換路由"| P["VPC Network<br/>Peering<br/>各自管理、不可傳遞"]
  Q -->|"多 VPC／多站點／多雲<br/>需要集中拓撲與分段"| N["Network<br/>Connectivity Center<br/>Hub、spokes、<br/>route tables"]
  S --> G["再用 IAM 分開<br/>網路與應用管理權"]
  P --> V["驗證 CIDR、<br/>DNS、firewall<br/>以及無傳遞性"]
  N --> V2["驗證支援的<br/>route exchange<br/>與 import／<br/>export filters"]

負載平衡：用五個問題收斂

Google Cloud 現在把負載平衡器分成兩大家族：處理 HTTP(S) 的 Application Load Balancer，以及處理 L4 流量的 Network Load Balancer。實際選型時依序問：

1. 流量是 L7 HTTP(S)，還是 L4 TCP／UDP？
2. 用戶端在網際網路，還是在 VPC 或混合網路內？
3. 服務需要全球、跨區域，還是單一區域的入口？
4. 需要 proxy 模式的 TLS 終止與流量處理，還是要保留用戶端封包資訊的 passthrough 模式？
5. 後端是 MIG、NEG、Cloud Run、GKE，還是混合／外部端點？

例如，全球網站需要 URL routing、TLS 終止和多區域後端，可以評估 global external Application Load Balancer；區域內部的 TCP 服務，則可能更適合 internal passthrough Network Load Balancer。名稱很像，但流量層級和部署模式不同。

不要用「全球網站就一定選某一個答案」取代需求分析。資料落地、Network Service Tier、後端類型、容錯範圍和成本，都可能讓設計改變。最新的類型與限制以 Cloud Load Balancing overview 為準。

flowchart TB
  T["先描述 client 到<br/>backend 的流量"] --> L{"協定層？"}
  L -->|"HTTP(S)／gRPC"| A["Application<br/>Load Balancer"]
  L -->|"TCP／UDP"| N["Network Load Balancer"]
  A --> E{"External<br/>還是 Internal？"}
  N --> E
  E --> S{"Global／Cross-region<br/>還是 Regional？"}
  S --> M{"Proxy 還是<br/>Passthrough？"}
  M --> B{"Backend 類型？<br/>MIG／NEG／GKE／<br/>Cloud Run／Hybrid"}
  B --> C["核對功能相容性、<br/>故障範圍、tier 與成本"]

Cloud Armor 要接在受支援的入口

Cloud Armor 可以對支援的負載平衡後端服務套用安全政策，常見能力包括：

• IP、地理位置與 L7 屬性的存取規則。
• 預先設定的 WAF 規則。
• Rate limiting 與 bot 管理。
• Adaptive Protection 協助偵測 L7 DDoS 異常。

它不只和單一一種負載平衡器搭配，也不是所有負載平衡模式都支援同一種 policy。設計時要先確認「這個 backend service 和 load balancer mode 能否掛上需要的 policy」，再依 Cloud Armor 相容性與設定文件 實作。

WAF 也不是應用安全的替代品。輸入驗證、身分驗證、權限檢查與修補流程仍然要在應用和平台層完成。

私有存取不是只有一條路

Private Google Access

沒有外部 IP 的資源，可以透過 Private Google Access 存取支援的 Google API 與服務。這通常是既有應用要使用 Google API、又不想替每台 VM 配外部 IP 時的直接做法。

Private Service Connect

Private Service Connect（PSC）讓 consumer 在自己的 VPC 使用內部 IP 存取 Google API、受管理服務或 producer 發布的服務。Consumer 和 producer 的網路可以保持獨立，服務也不必因為一個 consumer 加入就合併位址空間。

PSC 常用在需要明確服務端點、集中治理，或要把內部服務私下提供給其他 VPC 的情境。DNS 是否能自動建立、支援哪些端點與服務，則取決於實際功能和設定，不能假設全部情境都會自動完成。

Private Google Access 和 PSC 有重疊之處，但不是單純的新舊替代關係。先問自己需要的是「讓私有工作負載呼叫 Google API」，還是「在 consumer VPC 建立可控的私有服務端點」。更多細節可參考 Private Service Connect overview。

Cloud NAT

工作負載沒有外部 IP，但仍要主動連一般網際網路時，可以評估 Cloud NAT。它提供來源 NAT，不會因為啟用 NAT 就允許外部主動連進 VM。

Cloud NAT、Private Google Access 和 PSC 解決的問題不同：

• 一般網際網路 egress：Cloud NAT。
• 私有工作負載存取支援的 Google API：Private Google Access。
• 透過 consumer 端點存取 Google API 或已發布服務：PSC。

flowchart TB
  W["沒有 External IP<br/>的 workload"] --> D{"目的地是什麼？"}
  D -->|"一般 Internet egress"| N["Cloud NAT<br/>只做主動出站來源 NAT"]
  D -->|"支援的 Google APIs<br/>需要直接私有存取"| P["Private Google<br/>Access"]
  D -->|"Google APIs／<br/>Managed service／<br/>Producer 發布服務"| C["Private Service<br/>Connect<br/>Consumer VPC<br/>內部 endpoint"]
  N --> X["外部不能因 NAT<br/>反向主動連入 VM"]
  P --> V["驗證 subnet、DNS<br/>與支援服務"]
  C --> V2["驗證 endpoint<br/>類型、DNS<br/>與 producer policy"]

防火牆要同時處理授權與治理

VPC firewall rules 會作用在網路層；hierarchical firewall policies 則能在 organization 或 folder 層級建立共同基線。評估規則時，不要只背「數字小的優先」，因為 hierarchical policy、global／regional network firewall policy、VPC rules 與 goto_next 會一起影響結果。遇到複雜環境，直接依 firewall rule evaluation order 逐層檢查。

先讀取 VPC 的 networkFirewallPolicyEnforcementOrder，再排求值順序。一般 VPC 的兩種設定如下：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

flowchart TD
  H["Hierarchical firewall policies<br/>Organization → 各層 Folder"] --> S["Regional system firewall policies"]
  S --> O{"VPC 的 enforcement order？"}
  O -->|"AFTER_CLASSIC_FIREWALL（預設）"| A["VPC rules → Global policy<br/>→ Regional policies"]
  O -->|"BEFORE_CLASSIC_FIREWALL"| B["Global policy → Regional policies<br/>→ VPC rules"]
  A --> I["尚未決定才進入 Implied actions"]
  B --> I
  H -.-> R["任一階段匹配終止動作<br/>就不再求值後續規則"]
  S -.-> R
  A -.-> R
  B -.-> R

Priority 數字只在對應的政策或規則集合內比較，不能把所有層級的數字排成一張清單。apply_security_profile_group 則把流量交給設定的安全檢查，由 security profile 決定允許或丟棄，不等同一般 allow。以上順序與動作以 官方求值文件 為準。

10 分鐘排錯練習：為什麼較小的 priority 沒有擋住？

假設要判斷送往一台 VM 的 TCP 443 新入站連線。所有規則都符合來源、方向、協定與目標；沒有其他中介設備或應用驗證影響結果：

• Organization／folder 與 regional system policies 都未做出終止決定。
• VPC firewall rule：priority 1000，動作 allow。
• Global network firewall policy：priority 100，動作 deny。
• Regional network policies 沒有匹配規則。

請先寫下答案，再展開參考判斷：

1. 使用預設 AFTER_CLASSIC_FIREWALL 時，連線會被允許還是拒絕？在哪一層停止？
2. 改用 BEFORE_CLASSIC_FIREWALL 後，結果如何改變？
3. 若 organization 層的 hierarchical firewall policy 先匹配明確的 deny，把 VPC rule priority 改成 1 能否解決？
4. 要驗證推論，需取得哪些設定與流量資訊？請列至少三項。

目標識別也要看治理模型：

• Network tag 容易理解，但能修改 VM 的人也可能改 tag。
• Service account target 適合以工作負載身分分組，但權限與服務帳戶生命週期要一起管理。
• Secure tag 可搭配 IAM 控制 tag 綁定，適合需要集中治理的環境。

不存在一種 target 適合所有規則。關鍵是：誰能改這個識別、改動會影響哪些工作負載，以及是否能稽核。

需要進一步的 L7／威脅防護時，可以評估 Cloud NGFW；要集中檢查和限制 HTTP(S) egress，則可評估 Secure Web Proxy。它們增加安全能力，也會增加成本、路徑和營運工作，應由風險要求驅動。

設計練習：三層式電商服務

假設一家電商有全球使用者，前端和 API 跑在 Cloud Run，交易資料放在使用 private IP 的 Cloud SQL。可以這樣討論，而不是直接把服務全塞進圖裡：

1. 入口：先確認要在哪些區域服務、容許什麼故障，再選 external Application Load Balancer 的部署模式。
2. Web 防護：確認所選負載平衡模式支援需要的 Cloud Armor policy，先用 preview／觀察模式驗證規則影響。
3. 服務間通訊：釐清前端是否真的需要經過另一個 load balancer，或可透過受控的服務端點與 IAM 呼叫 API。
4. 資料庫：Cloud SQL private IP 的連線、授權與憑證要按 Cloud SQL 的網路和身分機制設計，不能只畫一條 VM firewall rule 就算完成。
5. Egress：把 Google API、合作夥伴 API 和一般套件下載分開，分別決定 PSC／Private Google Access、受控 proxy 或 Cloud NAT。
6. 驗證：用 Connectivity Tests、VPC Flow Logs、負載平衡器日誌和應用指標確認實際路徑。

這個練習真正要培養的，是每一條箭頭都能說明「誰發起、走哪裡、誰允許、哪裡留下紀錄」。

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• Shared VPC 和 VPC Network Peering 各解決什麼問題？A 連 B、B 連 C，A 能不能經過 B 到 C？（回〈跨專案連線〉）
• 選負載平衡器之前，要先判斷哪幾件事？（回〈負載平衡〉）
• Private Google Access、Private Service Connect 和 Cloud NAT 各自解決什麼問題？（回〈私有存取不是只有一條路〉）

本課重點

• VPC 是全球資源；子網路與多數網路閘道有各自的區域範圍。
• IP 規劃要包含 GKE 次要範圍、混合網路與未來區域，不能只看第一天。
• Shared VPC 解決集中管理；peering 連接獨立 VPC，而且不具傳遞性。
• 負載平衡先判斷 L7／L4、外部／內部、proxy／passthrough、部署範圍與後端類型。
• Cloud Armor 能否套用，要依負載平衡器與 policy 類型確認。
• Private Google Access、PSC 和 Cloud NAT 的目的不同，不應互相當成同義詞。
• 防火牆設計先確認 enforcement order；priority 不跨層比較，goto_next 不等於允許。目標識別、可修改者和稽核方式也要一起考慮。

延伸閱讀

• VPC overview
• Shared VPC overview
• Cloud Load Balancing overview
• Private Service Connect overview

下一步

下一課會把 VPC 接到地端和其他雲端，重點不是背專線規格，而是把容量、加密、路由、DNS 和故障切換整成一個能演練的連線方案。