多個 GCP 專案的網路怎麼接？Shared VPC、Peering 與 Cloud NAT

前言

在 GCP-104 建過 VPC、子網路和防火牆之後，接下來常遇到的是跨專案問題：幾個團隊要共用網路嗎？兩個 VPC 要互通嗎？沒有外部 IP 的 VM 又該怎麼連出去？

這篇會用具體情境比較 Shared VPC、VPC Peering、Cloud NAT 和 Private Google Access，讓每個服務的用途與限制更容易分清楚。

💡 動手前先確認

這課接在 GCP-104 後面，預設你已經知道什麼是子網路（subnet）、以及防火牆規則有方向之分——INGRESS（入站）管別人連進來、EGRESS（出站）管自己連出去。如果這兩個還有點模糊，建議先回頭把 GCP-104 翻一翻，不然底下講 Cloud NAT、防火牆優先順序時會卡住。

場景一：多專案共用網路 — Shared VPC

假設你公司有三個 GCP 專案：dev-project、staging-project、prod-project，每個各自帶一個 VPC。現在 VM 之間要互通，你得拉幾條 VPC Peering？三條——A↔B、B↔C、A↔C。三個專案還好，等哪天變成十個專案，連線數會爆炸成幾十條，光是管這些對接就夠你頭痛了。

這時候你需要的不是「把每個網路接起來」，而是「大家根本共用同一個網路」。

解法：Shared VPC

Shared VPC 讓你把一個 VPC 共享給多個專案用，這樣只要管一個網路就好。

flowchart TB
  ORG["GCP Organization"] --> HOST["Host Project<br/>擁有 Shared VPC"]
  ORG --> SERVICES["Service Projects<br/>dev／staging／prod"]
  HOST --> NETWORK["shared-vpc<br/>集中管理路由與防火牆"]
  NETWORK --> SUBNETS["依環境分配共享 Subnet<br/>subnet-dev／staging／prod"]
  SERVICES --> COMPUTE["VM／GKE／其他運算資源<br/>仍由各 Service Project 擁有"]
  SUBNETS -. "授予 compute.networkUser<br/>後附掛網路介面" .-> COMPUTE
  XPN["Organization Admin<br/>compute.xpnAdmin"] -. "啟用 Shared VPC<br/>並掛接 Service Projects" .-> HOST
  NETADMIN["Network Admin<br/>compute.networkAdmin"] -. "管理 VPC、Subnet、<br/>路由與防火牆" .-> NETWORK
  SA["Service Project SA<br/>compute.networkUser"] -. "只使用被授權的 Subnet" .-> COMPUTE

角色與權限

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

設定步驟

# 1. 啟用 Shared VPC（需要組織管理員）
gcloud compute shared-vpc enable HOST_PROJECT_ID

# 2. 將服務專案連接到主機專案
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \
  --host-project=HOST_PROJECT_ID

# 3. 授予服務專案的 Service Account 網路使用權限
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member="serviceAccount:app-sa@SERVICE_PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/compute.networkUser"

# 4. 在主機專案建立子網路（供服務專案使用）
gcloud compute networks subnets create subnet-dev \
  --network=shared-vpc \
  --region=asia-east1 \
  --range=10.10.0.0/24 \
  --project=HOST_PROJECT_ID

重要限制

• 一個專案只能是 主機專案 OR 服務專案，不能兩者兼具
• 一個服務專案只能附屬於一個主機專案
• 必須在同一個組織（Organization）內

場景二：VPC 間直連 — VPC Peering

什麼是 VPC Peering？

VPC Peering 讓兩個 VPC 直接走 Google 私有骨幹網路互通，不用公開 IP，延遲低、頻寬也高。

⚠️ 關鍵限制：不支援傳遞路由（Non-Transitive）

這裡要注意的是，VPC Peering 不會把路由一路轉送到第三個 VPC：

flowchart TB
  subgraph EXISTING["目前建立的直接連線"]
    direction LR
    A["VPC-A"] <-->|"Peering A↔B"| B["VPC-B"]
    B <-->|"Peering B↔C"| C["VPC-C"]
  end
  A -. "不能借道 B" .-> BLOCK["✕ 沒有 A→B→C<br/>傳遞路由"]
  BLOCK -.-> C
  NEED{"A 與 C 也需要互通？"} -->|"少量固定網路"| DIRECT["另外建立 A↔C<br/>直接 Peering"]
  NEED -->|"網路數量持續增加"| SCALE["改評估 Shared VPC 或<br/>Network Connectivity Center"]
  A --> NEED
  DIRECT --> CHECK["確認 CIDR 不重疊、<br/>雙邊設定與各自防火牆"]
  SCALE --> CHECK

A 要連到 C 的話，就得另外再拉一條 A↔C 的 peering。

💡 重點：Peering 不會替第三個 VPC 轉送

A↔B 和 B↔C 已建立 Peering，不代表 A 能透過 B 連到 C。若三個 VPC 都要直接互通，還需要 A↔C；網路越多，完整網狀 Peering 的連線數會很快增加。這時可比較 Shared VPC、Network Connectivity Center 等拓撲，但要先確認各網路的管理邊界和連線需求。（參考：VPC Network Peering 文件）

其他限制

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

設定步驟

# VPC-A 專案建立 peering 到 VPC-B（舊教學常見的 --auto-create-routes 已棄用，不用加）
gcloud compute networks peerings create a-to-b \
  --network=vpc-a \
  --peer-project=PROJECT_B \
  --peer-network=vpc-b

# VPC-B 專案也要建立對應 peering（雙向設定）
gcloud compute networks peerings create b-to-a \
  --network=vpc-b \
  --peer-project=PROJECT_A \
  --peer-network=vpc-a

# 確認狀態（兩邊都是 ACTIVE 才算成功）
gcloud compute networks peerings list --network=vpc-a

Shared VPC vs VPC Peering 選擇

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

場景三：私有 VM 連出網路 — Cloud NAT

為了安全，你很可能會把 VM 的外部 IP 拿掉——沒有公開 IP，外面就攻不進來。但問題立刻來了：這台 VM 想跑 apt-get update、想 pip install 拉套件、想呼叫某個第三方 API，全都連不出去了。沒有對外的門，VM 等於被關在房間裡。

那要怎麼讓它「只能出去、不能被進來」？這就是 Cloud NAT 要解決的事。

解法：Cloud NAT

Cloud NAT 是全托管的出站 NAT 服務，讓沒有外部 IP 的 VM 也能連上網際網路（只出不進）。

sequenceDiagram
  autonumber
  participant VM as 私有 VM<br/>10.0.0.5
  participant NAT as Cloud NAT<br/>掛在 Cloud Router 設定
  participant WEB as Internet<br/>第三方端點
  VM->>NAT: 主動建立出站連線
  Note over NAT: 建立來源 IP／port 對應<br/>換成 NAT 外部 IP
  NAT->>WEB: 以 NAT IP 送出請求
  WEB-->>NAT: 回應既有連線
  NAT-->>VM: 依對應表還原並送回 10.0.0.5
  WEB-xNAT: 未經請求的入站連線
  Note over NAT,VM: 沒有既有對應，不會轉送到 VM

⚠️ 重要：Cloud NAT 只支援出站連線

方向是單向的：VM 可以主動發起連線出去，但外面沒辦法主動連進來（不支援 inbound）。如果你的服務需要被外部連入，那 Cloud NAT 幫不上忙——這時候 VM 得有公開 IP，或是擺在 Load Balancer 後面。

建立 Cloud NAT

Cloud NAT 自己不能單獨存在，得搭配一個 Cloud Router（雲端路由器，GCP 裡負責動態管理路由的元件）。你可以把 Cloud Router 想成 NAT 的「掛載點」：它本身管路由，Cloud NAT 則像外掛一樣裝在它上面，借它來處理那些位址轉換。所以順序一定是先建 Router、再建 NAT：

# 1. 建立 Cloud Router
gcloud compute routers create my-router \
  --network=my-vpc \
  --region=asia-east1

# 2. 建立 Cloud NAT（自動分配 NAT 外部 IP）
gcloud compute routers nats create my-nat \
  --router=my-router \
  --region=asia-east1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips

# 3. 若需要靜態外部 IP（方便 IP 白名單）
gcloud compute addresses create nat-ip-1 --region=asia-east1

gcloud compute routers nats create my-nat \
  --router=my-router \
  --region=asia-east1 \
  --nat-all-subnet-ip-ranges \
  --nat-external-ip-pool=nat-ip-1

各服務的 Cloud NAT 支援

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

場景四：私有 VM 存取 Google API — Private Google Access

問題

私有 VM 想呼叫 storage.googleapis.com（Cloud Storage API）或 bigquery.googleapis.com，但又不想讓流量走公網。

解法：Private Google Access

在子網路上啟用 Private Google Access，私有 VM 就能走 Google 私有骨幹網路存取 Google API，流量完全不出 Google 網路。

flowchart TB
  START["沒有外部 IP 的私有 VM<br/>需要連到哪裡？"] --> DEST{"目的地或連線方向"}
  DEST -->|"Google APIs<br/>Storage、BigQuery、Logging"| PGA["在子網路啟用<br/>Private Google Access"]
  PGA --> GOOGLE["沿 Google 網路到<br/>受支援的 googleapis.com"]
  DEST -->|"公開網站或第三方 API<br/>GitHub、套件庫"| NAT["設定 Cloud Router + Cloud NAT<br/>提供出站網際網路"]
  NAT --> INTERNET["Internet<br/>只能回應既有連線"]
  DEST -->|"兩種目的地都需要"| BOTH["同時啟用 PGA 與 Cloud NAT<br/>兩者不是互斥選項"]
  BOTH --> GOOGLE
  BOTH --> INTERNET
  DEST -->|"網際網路要主動連入服務"| INBOUND["使用外部 Application Load Balancer<br/>或明確配置外部 IP"]
  INBOUND --> FIREWALL["再以防火牆與應用認證<br/>限制允許的入站流量"]

支援的服務

• Cloud Storage、BigQuery、Pub/Sub、Cloud SQL Admin API（Auth Proxy 取憑證用；資料庫連線本身要走 Private IP 或 Private Service Connect）
• Cloud Logging、Cloud Monitoring
• 絕大多數 *.googleapis.com 端點（少數區域型的 rep.googleapis.com 端點除外）
• 不包含：公網網站（GitHub、npm registry 等）→ 需要 Cloud NAT

啟用方式

# 建立子網路時啟用
gcloud compute networks subnets create private-subnet \
  --network=my-vpc \
  --region=asia-east1 \
  --range=10.0.1.0/24 \
  --enable-private-ip-google-access

# 在現有子網路上啟用
gcloud compute networks subnets update private-subnet \
  --region=asia-east1 \
  --enable-private-ip-google-access

Private Google Access vs VPC Service Controls

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

💡 重點提點：Cloud NAT 跟 Private Google Access 最容易搞混

兩者解決的是不同連線需求：沒有外部 IP 的 VM 若要連 GitHub、npm 等外部服務，可以透過 Cloud NAT 出站；若要私下存取 Cloud Storage、BigQuery 等 Google API，則要檢查 Private Google Access 的設定。像「VM 要執行 apt-get，也要讀 Cloud Storage」這種情境，應分別確認兩條路徑，不要把它們當成同一個開關。

防火牆規則深度解析

優先順序（Priority）

防火牆規則優先順序：數字越小，優先級越高（0 = 最高，65535 = 最低）。

建議分配：

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

⚠️ 自訂規則的合法 priority 是 0–65535（含），你其實可以建 priority=65535 的規則。重點在於：VPC 的隱含規則（允許出站、拒絕入站）是評估的最後一步，只有在沒有任何規則匹配時才會套用。所以自訂的 catch-all 拒絕規則（例如 priority 65000）會在隱含的 allow-egress / deny-ingress 之前先生效。

隱含規則（Implied Rules）

每個 VPC 都有兩條隱含的最低優先規則：

flowchart LR
  subgraph SELECT["找出匹配規則"]
    direction TB
    PACKET["封包到達 VM 網路介面"] --> DIRECTION{"方向是 INGRESS<br/>還是 EGRESS？"}
    DIRECTION --> CANDIDATES["比對來源／目的、協定、<br/>target tag 或 Service Account"]
    CANDIDATES --> MATCH{"有自訂規則匹配？"}
  end
  subgraph CUSTOM["有自訂規則"]
    direction TB
    PRIORITY["選數字最小的 Priority<br/>0 最高、65535 最低"] --> TIE{"同一 Priority 同時有<br/>allow 與 deny？"}
    TIE -->|"是"| DENY["deny 生效"]
    TIE -->|"否"| ACTION["執行規則的<br/>allow 或 deny"]
  end
  subgraph DEFAULT["沒有自訂規則"]
    direction TB
    IMPLIED{"封包方向"}
    IMPLIED -->|"EGRESS"| ALLOW_OUT["隱含 allow egress<br/>允許出站"]
    IMPLIED -->|"INGRESS"| DENY_IN["隱含 deny ingress<br/>拒絕入站"]
  end
  MATCH -->|"有"| PRIORITY
  MATCH -->|"沒有"| IMPLIED

這也是為什麼你不設防火牆時，VM 連得出去（出站預設允許），但外面連不進來（入站預設拒絕）。

防火牆規則範例

# 允許特定 IP 範圍 SSH
gcloud compute firewall-rules create allow-ssh-from-office \
  --network=my-vpc \
  --direction=INGRESS \
  --allow=tcp:22 \
  --source-ranges=203.0.113.0/24 \
  --priority=1000

# 允許 HTTP/HTTPS 公開存取
gcloud compute firewall-rules create allow-http-https \
  --network=my-vpc \
  --direction=INGRESS \
  --allow=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web-server \
  --priority=1000

# 使用 Service Account 作為目標（更安全）
gcloud compute firewall-rules create allow-db-from-app \
  --network=my-vpc \
  --direction=INGRESS \
  --allow=tcp:5432 \
  --source-service-accounts=app-sa@my-project.iam.gserviceaccount.com \
  --target-service-accounts=db-vm-sa@my-project.iam.gserviceaccount.com \
  --priority=1000

Network Tags vs Service Accounts

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

Cloud NGFW 防火牆政策（Firewall Policies）

傳統防火牆規則是綁在單一 VPC 上的（per-VPC）。Cloud NGFW 的防火牆政策（firewall policies） 則可以階層式套用到組織、資料夾或 VPC 網路：

flowchart TB
  ORG["Organization Firewall Policy<br/>全公司安全基線"] --> FOLDER_A["Folder Policy<br/>事業群 A 例外與限制"]
  ORG --> FOLDER_B["Folder Policy<br/>事業群 B 例外與限制"]
  FOLDER_A --> PROJECT_A["Project／VPC Rules<br/>應用 A 的連接埠與來源"]
  FOLDER_A --> PROJECT_B["Project／VPC Rules<br/>應用 B 的連接埠與來源"]
  FOLDER_B --> PROJECT_C["Project／VPC Rules<br/>應用 C 的連接埠與來源"]
  SECURITY["中央 Security Team"] -. "維護不可缺少的基線" .-> ORG
  PLATFORM["Platform／BU Team"] -. "管理事業群需求" .-> FOLDER_A
  APP["Application Team"] -. "維護最小必要流量" .-> PROJECT_A

組織層級的規則可以強制套用到所有 VPC，合規性比較好顧。

把四個場景串起來看

先區分要解決的是「多專案網路治理」還是「單一私有工作負載的連線路徑」，再走對應的選型圖；兩組工具可以在同一架構中並存。

flowchart TB
  START["多專案／多 VPC<br/>需要互通或集中治理"] --> MODEL{"最主要的治理需求？"}
  MODEL -->|"同一組織共用 Subnet、<br/>路由與防火牆"| SHARED["Shared VPC<br/>共享 Subnet 與集中治理"]
  MODEL -->|"少量獨立 VPC<br/>一對一直接互通"| PEERING["VPC Peering<br/>CIDR 不重疊、路由非傳遞"]
  MODEL -->|"許多獨立網路<br/>需要樞紐式互通"| NCC["NCC<br/>樞紐式拓撲"]

flowchart TB
  START["私有工作負載<br/>沒有外部 IP"] --> PATH{"需要哪種連線路徑？"}
  PATH -->|"存取受支援的<br/>Google API"| PGA["Private Google Access<br/>由子網路啟用"]
  PATH -->|"主動連到一般公網<br/>並接收既有連線回應"| NAT["Cloud NAT<br/>全托管出站 NAT"]
  PATH -->|"讓公網使用者<br/>主動連入服務"| INBOUND["外部 Load Balancer／外部 IP<br/>再限制 ingress"]

ACE 考試重點整理

必背知識點

1. Shared VPC：一個專案不能同時是 host 和 service project
2. VPC Peering 非傳遞：A↔B、B↔C，但 A 無法透過 B 連到 C
3. Cloud NAT 只支援出站：無法從網際網路主動連入
4. Private Google Access 只能存取 Google API，不是完整網路
5. 防火牆優先數字：數字越小優先級越高（0 = 最高）
6. 隱含規則：出站預設允許、入站預設拒絕
7. Service Account > Network Tag（防火牆安全性）

常見陷阱題

Q：VPC-A peering VPC-B，VPC-B peering VPC-C，VPC-A 能連 VPC-C 嗎？ A：不能。VPC Peering 不支援傳遞路由，要直接建立 A↔C 的 peering 才行。

Q：私有 VM 要能 apt-get 並且存取 Cloud Storage，需要分別設什麼？ A：apt-get → Cloud NAT（公網出站）；Cloud Storage → Private Google Access（Google API）。兩個都要設。

Q：Cloud NAT 支援從網際網路連入 VM 嗎？ A：不支援。Cloud NAT 純出站（egress only）。

Q：防火牆規則 priority=500 和 priority=1500 哪個先被評估？ A：priority=500 先被評估（數字小 = 高優先）。

總結

這幾個網路功能常一起出現在架構圖上，但負責的事情不同：

• Shared VPC：組織內多專案共用一個 VPC，集中管理，需要在同組織內
• VPC Peering：兩個 VPC 直連，注意非傳遞限制與子網路不重疊
• Cloud NAT：讓私有 VM 能出站到網際網路，只出不進
• Private Google Access：讓私有 VM 透過 Google 私有骨幹存取 Google API

下一課 ACE-211：BigQuery 資料倉儲實戰，學習如何用 SQL 分析 PB 級資料。

網路系列

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