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

前言

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

這是 GCP 入門系列第 10 課，會帶你搞懂企業環境裡最常碰到的四個進階網路需求。

---

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

問題

你的公司有三個 GCP 專案：dev-project、staging-project、prod-project。每個專案各有一個 VPC，VM 之間要互通，要建幾條 VPC Peering？答案是 3 條（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
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。

其他限制

限制	說明
子網路不能重疊	兩個 VPC 的 CIDR 不能有 overlap
雙向設定	兩個 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
需要傳遞路由（A→B→C 都通）	Shared VPC
連接不同組織或外部合作夥伴 VPC	VPC Peering
各專案需要獨立的 CIDR 規劃	VPC Peering
簡化防火牆管理	Shared VPC

---

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

問題

安全上最理想的做法是 VM 不掛外部 IP，但這樣一來 VM 就沒辦法跑 apt-get update、下載程式依賴、或呼叫第三方 API。

解法：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 可以主動發起連線到網路
• ❌ 網路無法主動連入 VM（不支援 inbound）
• 若需要網路連入，VM 必須有公開 IP 或透過 Load Balancer

建立 Cloud NAT

Cloud NAT 需要搭配 Cloud Router 使用：

# 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	❌	Google 管理，不支援

---

場景四：私有 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 端點
• 不包含：公網網站（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	雙向存取控制
設定層級	子網路	組織/專案層級
適合場景	基本私有網路需求	高度合規、資料外洩防護

---

防火牆規則深度解析

優先順序（Priority）

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

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

建議分配：

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

⚠️ 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 先被評估（數字小 = 高優先）。

---

總結

GCP 進階網路設計，記住這四大工具就夠用：

• 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、混合雲連線