GCP-110：VPC 進階網路設計——Shared VPC、VPC Peering 與 Cloud NAT 完全指南

前言

GCP-104 我們把 VPC 基礎走過一遍：建網路、切子網路、設防火牆規則。這篇要往上一層，講進階場景：專案一多，網路到底怎麼設計才不會亂？ 還有，私有 VM 要存取 Google API、或是要連出網際網路，又該怎麼搞定？

這些都是企業環境裡天天會碰到的問題。接下來用四個真實場景一個一個拆，看完你就知道專案多了之後網路該怎麼擺。

💡 動手前先確認

這課接在 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 共享給多個專案用，這樣只要管一個網路就好。

組織
│
├─ [Host Project] 主機專案         ← 擁有 VPC、子網路、防火牆規則
│     └─ shared-vpc
│          ├─ subnet-dev
│          ├─ subnet-staging
│          └─ subnet-prod
│
├─ [Service Project] dev-project   ← 使用 shared-vpc 中的 subnet-dev
├─ [Service Project] staging-project
└─ [Service Project] prod-project

角色與權限

角色	誰需要	說明
roles/compute.xpnAdmin	組織管理員	啟用/管理 Shared VPC（xpn = Cross-Project Networking，Shared VPC 的舊內部代號，看到這串別被嚇到，就是它）
roles/compute.networkAdmin	主機專案網路管理員	管理 VPC 與子網路
roles/compute.networkUser	服務專案 Service Account	使用共享子網路建立 VM

設定步驟

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

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

# 3. 授予服務專案的 Service Account 網路使用權限
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member="serviceAccount: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）

這是 ACE 考試最愛考的陷阱：

VPC-A ←──peering──→ VPC-B ←──peering──→ VPC-C

問：VPC-A 能透過 VPC-B 連到 VPC-C 嗎？
答：❌ 不能！VPC Peering 不是傳遞的。

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

💡 重點提點：「非傳遞」這四個字釘死它

Peering 只認「直接對接」的兩方。A 跟 B 接了、B 跟 C 接了，不代表 A 就能借道 B 連到 C——這條路 GCP 不會幫你自動打通。三個 VPC 要兩兩互通，你得老老實實拉三條（A↔B、B↔C、A↔C）；十個 VPC 全互通就是 45 條，數量會以平方速度膨脹。這也正是專案一多就該換 Shared VPC（大家共用一個網路）或 Network Connectivity Center 的原因。考題只要出現「A 透過 B 連 C」，反射性回答不行就對了。

其他限制

限制	說明
子網路不能重疊	兩個 VPC 的 IP 範圍（CIDR，標記 IP 區段的寫法，例如 10.0.0.0/24 代表一段 256 個位址）不能重疊；重疊了 GCP 會搞不清楚某個 IP 該送去哪一邊
雙向設定	兩個 VPC 都需要各自建立 peering（不是單邊設定）
防火牆獨立	各 VPC 的防火牆規則不會互相繼承
跨區域收費	跨 region peering 流量有小額費用

設定步驟

# VPC-A 專案建立 peering 到 VPC-B
gcloud compute networks peerings create a-to-b \
  --network=vpc-a \
  --peer-project=PROJECT_B \
  --peer-network=vpc-b \
  --auto-create-routes

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

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

Shared VPC vs VPC Peering 選擇

需求	選擇
同組織多專案，需要集中管理單一網路	Shared VPC
多個專案想共用同一套子網路與防火牆規則	Shared VPC
連接不同組織或外部合作夥伴 VPC	VPC Peering
各專案需要獨立的 CIDR 規劃	VPC Peering
簡化防火牆管理	Shared VPC

---

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

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

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

解法：Cloud NAT

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

私有 VM（無外部 IP）
    │ 出站請求（10.0.0.5 → 8.8.8.8）
    ▼
[Cloud Router] ← Cloud NAT 掛在這裡
    │ 轉換來源 IP（35.200.x.x → 8.8.8.8）
    ▼
Internet
    │ 回應（8.8.8.8 → 35.200.x.x）
    ▼
[Cloud NAT] 把 IP 轉換回去 → 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 支援

服務	支援 Cloud NAT	備注
Compute Engine	✅	原生支援
GKE	✅	Node 和 Pod 均可
Cloud Run	✅（透過 Serverless VPC Access 連接器或 Direct VPC Egress）	將出向流量導入 VPC 後即可用 Cloud NAT；Direct VPC Egress 為較新的推薦做法
App Engine Standard	✅（透過 Serverless VPC Access 連接器）	把 connector 的 egress 設成 all-traffic，就和 Cloud Run 走同一套 serverless→VPC→NAT 機制，可取得固定外部 IP

---

場景四：私有 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 網路。

私有 VM（無外部 IP）
    │ 存取 storage.googleapis.com
    ▼
Google 私有骨幹網路（不走公網！）
    │
    ▼
Cloud Storage API

支援的服務

• Cloud Storage、BigQuery、Cloud Pub/Sub、Cloud SQL（Auth Proxy）
• 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

功能	Private Google Access	VPC Service Controls
目的	讓私有 VM 存取 Google API	防止資料外洩（加安全邊界）
方向	私有 VM → Google API	雙向存取控制
設定層級	子網路	組織/專案層級
適合場景	基本私有網路需求	高度合規、資料外洩防護

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

這兩個名字長得不像，但新手常常分不清誰管什麼，連考題也愛拿來坑你。一句話記死：Cloud NAT 連的是「公網」（GitHub、npm、第三方 API），Private Google Access 連的是「Google 自家 API」（Cloud Storage、BigQuery…）。 一台沒有外部 IP 的私有 VM，如果它既要 apt-get 又要讀 Cloud Storage，那就是兩個都得設——不是二選一。考場上看到「私有 VM 同時要 apt 和 GCS」這種題目，答案幾乎都是「兩個一起開」。

---

防火牆規則深度解析

優先順序（Priority）

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

Priority 0    ─── 最高優先，最先評估
Priority 100  ─── 緊急封鎖規則
Priority 1000 ─── 預設優先值（一般應用規則）
Priority 65535 ── 最低優先，最後評估

建議分配：

範圍	用途
0–999	緊急封鎖（例：阻擋已知攻擊 IP）
1000–9999	標準應用規則
10000–64999	低優先規則
65000–65534	自訂 catch-all 拒絕規則（在隱含規則之前生效）

⚠️ 自訂規則的合法 priority 是 0–65535（含），你其實可以建 priority=65535 的規則。重點在於：VPC 的隱含規則（允許出站、拒絕入站）永遠最後評估，而且自訂規則蓋不過它。所以要自訂 catch-all 拒絕規則時，請用比 65535 小的數字（例如 65000），確保它在隱含的 allow-egress / deny-ingress 之前先生效。

隱含規則（Implied Rules）

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

priority 65535, allow egress to 0.0.0.0/0   → 允許所有出站
priority 65535, deny  ingress from 0.0.0.0/0 → 拒絕所有入站

這也是為什麼你不設防火牆時，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-sa@my-project.iam.gserviceaccount.com \
  --priority=1000

Network Tags vs Service Accounts

特性	Network Tags	Service Accounts
安全性	較低（任何人都能加 tag）	較高（綁定 IAM）
審計紀錄	有限	完整的 IAM 審計日誌
建議用途	開發/測試環境	生產環境（推薦）

VPC Firewall Policies（2024+ 推薦）

傳統防火牆規則是綁在單一 VPC 上的（per-VPC）。VPC Firewall Policies 則支援階層式套用：

組織 Firewall Policy（全公司基線規則）
├─ 資料夾 Firewall Policy（事業群規則）
│   └─ 專案 VPC 防火牆規則（應用程式規則）

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

---

把四個場景串起來看

GCP 組織
│
├── [Host Project] 主機專案 ── Shared VPC ──→ 多個服務專案共用
│
├── [VPC-A] ── VPC Peering ──→ [VPC-B]（跨組織/跨專案直連，非傳遞）
│
├── 私有子網路 VM
│     ├─ Private Google Access ──→ *.googleapis.com（不走公網）
│     └─ Cloud NAT ──→ Internet（只出站，不入站）
│
└── 防火牆規則（優先數字小 = 高優先；Service Account > Network Tag）

---

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 級資料。

網路系列

課程	主題
GCP-104	VPC 基礎、防火牆、Cloud IAP
本課 GCP-110	Shared VPC、VPC Peering、Cloud NAT
GCP-114	Cloud DNS、DNSSEC、路由策略
ACE-210	負載均衡、Cloud CDN、Cloud Armor
ACE-216	VPN、Interconnect、混合雲連線