Shared VPC 與 VPC Network Peering

簡介

企業級 GCP 部署幾乎不會只用一個 project。法遵、計費、影響範圍隔離以及團隊自治等需求，會把組織推向數十甚至數百個 project；但這些 project 仍然需要存取共用的平台服務，例如 Cloud SQL、內部 API、集中式 egress。Google Cloud 用兩個截然不同的跨 project 網路原語回應這個需求：Shared VPC（又稱 XPN、Cross-Project Networking）與 VPC Network Peering。兩者表面上看起來相似 — 都能讓不同 project 的工作負載透過 RFC 1918 位址互相通訊、不走公網 — 但它們解決的問題本質上完全不同。

Shared VPC 是一種治理模式：由中央網路/資安團隊擁有 host project 裡的 VPC、subnet、防火牆規則與路由；應用團隊則在自己的 service project 中部署 VM、GKE 節點、Load Balancer，並掛接到那些 subnet 上。VPC Peering 相反，是一種點對點連線原語，連接兩個對等的 VPC 網路，雙方沒有共享的管理權。在 Professional Cloud Network Engineer (PCNE) 考試裡，你必須能根據題目中提到的治理、自治、遞移性與 IAM 需求，在兩者之間做選擇；同時必須記住硬性限制 — 非遞移路由、不可重疊的 CIDR、每個 VPC 25 個 peering 配額，以及 peering 無法用 IAM 控管存取。

Shared VPC 架構：Host、Service、組織層級附掛

Shared VPC 引入三種角色，考試時必須分清楚。Host project 是實際擁有 VPC 網路、subnet、防火牆規則與路由的 project。執行 gcloud compute shared-vpc enable PROJECT_ID 會把該 project 標記為 host，內部會把 project 資源的 xpnProject 屬性設為 true。一個 host 可以服務多個 service project，但 host 自己不能再變成另一個 host 的 service project — 關係嚴格是兩層，不能串接。

Service Project 附掛

Service project 是任何透過 gcloud compute shared-vpc associated-projects add SERVICE_PROJECT --host-project HOST_PROJECT 明確附掛到 host 的 project。附掛之後，符合資格的資源（Compute Engine VM、GKE 叢集、內部/外部 Load Balancer、Cloud Run direct VPC egress、Dataproc 叢集、App Engine flexible、Cloud Functions Gen 2）在 service project 建立時可以指定 host project 裡的 subnet。VM 的計費、IAM 與 project 層級配額仍歸 service project，但網卡實體掛接的是 host 擁有的 subnet。

組織層級 vs 資料夾層級的 Host

Shared VPC 原本是 project 範圍的設計，但 Organization Policy compute.restrictSharedVpcSubnetworks 以及較新的組織層級 Shared VPC 附掛讓單一 host 可以把 subnet 暴露給整個組織或資料夾下的 project，不必逐一列出 service project。在大型企業組織層級附掛能降低管理負擔，但相對地擴大了 host project 網管失誤的影響範圍 — 整個組織下的 project 都會突然能存取共用 subnet。

兩層限制

Host 不能再當另一個 host 的 service project。實務上這代表你無法建出 team-host → division-host → corporate-host 這類階層。如果需要跨 host 連線，就必須用 兩個 host VPC 之間的 VPC Peering、HA VPN 或 Network Connectivity Center。考試很喜歡測這個 — 任何提議把 Shared VPC 串接的選項都是錯的。

Shared VPC IAM：Network User 與 Service Project Admin

Shared VPC 是 GCP 網路原語中，幾乎完全靠 IAM（而非防火牆規則）管制存取的特例。考題裡有三個角色最常出現，搞混它們是 Shared VPC 最常見的陷阱。

compute.xpnAdmin（Shared VPC Admin）

在組織或資料夾層級授與 roles/compute.xpnAdmin，持有者可以把 project 啟用為 host、附掛/卸除 service project、並在 subnet 上授與 compute.networkUser。這個角色是給中央網路/平台團隊用的。它本身不允許持有者建立 VM 或修改防火牆規則 — 那些需要額外角色。

compute.networkUser（Network User）

在 subnet（或整個 host project）上授與 roles/compute.networkUser，可以讓 service project 裡的 principal 建立掛接到該 subnet 的資源。最小權限原則建議在 subnet 層級授與 — 例如 team-prod-sa@svc-proj 只在 subnet-prod-us-east1 上拿到 networkUser，絕不在整個 host project 授與。在 project 層級授與等於讓對方能存取 host 的所有 VPC 裡的每個 subnet。

compute.networkAdmin 與 compute.securityAdmin

這兩個是 host 端管理網路本身的角色：networkAdmin 建立/修改 subnet、route、peering、Cloud Router；securityAdmin 管理防火牆規則與 SSL 憑證。Service project 的管理員絕不會拿到這些 — 他們只透過 networkUser 消費 subnet。

Service Account 注意事項

當 service project 的 VM 建立在 host subnet 上，VM 會使用 service project 的預設 Compute Engine service account（或使用者指定的 SA）。該 SA 必須在該 subnet 上有 roles/compute.networkUser，而且host project 的 GKE/Compute service agent（例如 service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com）必須擁有對應的 host 端角色。遺漏 host service agent 授權是 Shared VPC 設定最常失敗的原因。

何時選 Shared VPC、何時選 VPC Peering

Shared VPC 與 Peering 之間的取捨，是 PCNE 最常考的架構決策之一。把它簡化成四個軸：

治理軸

• Shared VPC = 集中式治理。單一團隊擁有 IP、route、防火牆規則。Service project 只能消費。
• Peering = 聯邦式治理。每個 VPC 由自己的團隊擁有，雙方各自獨立管理防火牆、route、subnet。

遞移性軸

• Shared VPC = 在 host VPC 內天然遞移。所有 service project 都能互通，因為共用 route。
• Peering = 嚴格非遞移。A↔B 加 B↔C 不會推導出 A↔C。

IAM 控管存取軸

• Shared VPC = IAM 決定誰能掛接哪個 subnet。可以把 prod subnet 鎖給一個團隊、dev subnet 給另一團隊，方法是在 subnet 層級授與 networkUser。
• Peering = 沒有 IAM 過濾。兩個 VPC 一旦 peering，所有 subnet 都變成可路由。只能在防火牆/route 層做限制。

規模與配額軸

• Shared VPC = 每個 host 最多約 1,000 個 service project，配額由單一 VPC 決定。
• Peering = 每個 VPC 預設 25 個 active peering 軟配額（可申請提高到約 50）。超過就必須改用 NCC 或 Shared VPC 整併。

VPC Network Peering 基本原理

VPC Peering 連接兩個 VPC 網路，讓任一側的 VM 可以用內部 IP 互通，就像同網路一樣。連線是雙向的 — 一旦建立，雙方互相交換 subnet 路由 — 但必須雙方都建立才能讓 peering 進入 ACTIVE。如果只有一邊執行 gcloud compute networks peerings create，peering 會顯示 INACTIVE，直到對側也建立為止。

對稱設定

雙方 peering 對「對端網路名稱、project、import/export route 旗標」必須一致。如果不一致（例如一邊 --export-custom-routes 另一邊 --no-import-custom-routes），peering 仍然會 active，但 custom route 會靜默地不傳播 — 這是經典的除錯陷阱。

同 Org、跨 Org、同 Project

你可以對同一 project 內的 VPC、同一 organization 下不同 project 的 VPC、甚至完全不同 organization 的 VPC 做 peering。跨 org peering 不需要組織之間有任何關係 — 只要雙方知道對方的 project ID 與 VPC 名稱即可。這也是 peering 在 partner/B2B 整合場景很常用的原因。

不走公網

Peering 流量留在 Google 私有 backbone，完全不走公網。同區域跨 peering 的流量不收 egress 費用；跨區域 peering 流量則以標準跨區域網路費率計算。比起在 VPC 之間架 VPN 隧道，這在成本上有明顯優勢。

雙向路由交換

Peering 預設會雙向交換 subnet routes（建立 subnet 時 Google 自動產生的 route）。Static routes 與 Cloud Router 經由 BGP 學到的動態路由，要在輸出側啟用 --export-custom-routes，而且輸入側啟用 --import-custom-routes 才會交換。

非遞移 Peering 與 Hub-and-Spoke 困境

VPC Peering 最常考的單一性質就是非遞移性 (non-transitivity)。如果 VPC A 與 VPC B peering、VPC B 與 VPC C peering，那麼 A 無法經由 B 抵達 C。Google 的 data plane 根本不會把封包在同一 VPC 上的兩個 peering 之間轉發。這是在網路虛擬化層強制執行的，不是防火牆規則 — 沒有任何防火牆開關可以打開遞移性。

為什麼設計成非遞移

遞移路由會讓任何 peered VPC 不小心把 route 沿一條長鏈洩漏出去，造成安全與配額災難。Google 的設計強迫你部署一個遞移路由層，把遞移意圖顯式表達出來。

如何達成遞移路由

• Network Connectivity Center (NCC) 搭配 VPC spoke — 現代且原生的答案；單一 NCC hub 可以連接多個 VPC，並在 spoke 之間提供完整的遞移 mesh。
• VPC 之間建 HA VPN 隧道 — VPN gateway 不受 peering 規則限制可轉發流量，但代價是每隧道頻寬上限約 3 Gbps 與 BGP 設定複雜度。
• 中間 VPC 部署 Proxy/Router VM — 適合低吞吐量工作負載，但會新增 SPOF 與營運負擔。

Hub-and-Spoke vs Full Mesh

常見模式是一個中央 transit VPC 跟很多 spoke VPC peering。若沒有 NCC，spoke 都能連到 hub，但 spoke 之間無法互通。把 hub 改成 NCC VPC-spoke hub 後，拓撲立刻變成遞移，不必重新 peering。

CIDR 重疊、Subnet 衝突與位址規劃

VPC Peering 與 Shared VPC 都嚴格遵守一條規則：互通的網路之間不能有 IP 範圍重疊。這條規則同時適用於主要 subnet 範圍、GKE 用的次要範圍，以及 static route 的 destination。

重疊檢查

建立 peering 時，GCP 會掃描兩個 VPC 的所有 subnet，只要任何範圍重疊就拒絕。錯誤訊息是 subnets in network NETWORK_A overlap with subnets in network NETWORK_B。檢查純粹基於範圍 — 即使 VPC A 的某個 /24 沒有被使用，只要 VPC B 也宣告了同樣的 /24，peering 就會失敗。

次要範圍也算

GKE 叢集會在 subnet 上使用次要範圍給 Pod (pod-range) 與 Service (service-range)。這些範圍也會被檢查重疊。常見錯誤是在兩個之後要互通的叢集都配了一樣的 10.4.0.0/14 Pod 範圍 — 第二個 peering 就會失敗。

Static Route Destination

自訂 static route，如果 destination 與對端 VPC 的 subnet route 重疊，即使啟用 --import-custom-routes 也會被阻擋匯入。Peering 會帶著該 route 條目但標記為 conflicting，data plane 直接丟棄。

位址規劃最佳實踐

對任何之後要用 Shared VPC 或 Peering 的組織，把 RFC 1918 空間階層式切割：每個環境保留一個 /16、每個區域一個 /20、每個 subnet 一個 /24。在第一個 VPC 建立之前就用 IPAM 工具記錄好這個規劃。事後重新調整 CIDR 非常痛苦 — 要嘛重新編號 VM，要嘛建一層 NAT proxy。

Privately Used Public IPs

Cloud VPN 與 Peering 都支援私下使用的公網 IP — 傳統用 RFC 1918，但不是必需。如果不需要把那些範圍用於 internet egress，你可以私下路由公網範圍。這在實務上不常見，但偶爾會在「對接舊公司收購後其 on-prem 使用公網 IP」的考題中出現。

動態與靜態 Peering 路由（Import/Export Custom Routes）

預設情況下，VPC Peering 只交換 subnet routes（也稱為自動建立的 route）。其他東西 — 用 gcloud compute routes create 建立的 static route，或從 Cloud Router 經 Cloud VPN/Interconnect 學到的動態 BGP route — 預設不會交換，除非你明確啟用自訂路由交換。

--export-custom-routes

在輸出側 VPC 的 peering 上設 --export-custom-routes。這會讓 GCP 把 static custom routes 與 BGP 學來的動態路由一起 advertise 給對端。沒有區分 static 與 dynamic 的旗標 — export 旗標兩者都涵蓋。

--import-custom-routes

在輸入側 VPC 的 peering 上設 --import-custom-routes。Peering 會接受對方 advertise 來的 custom route，並裝進輸入側 VPC 的 route table。

--export-subnet-routes-with-public-ip 與 --import-subnet-routes-with-public-ip

有些 subnet 使用私下使用的公網 IP（公網可路由的位址空間私下部署）。預設這類 subnet route 不會跨 peering 交換。*-with-public-ip 旗標可以把它們納入。對端 VPC 內部 advertise 非 RFC-1918 範圍時需要設定。

不對稱設定陷阱

若 A 側啟用 --export-custom-routes，但 B 側沒啟用 --import-custom-routes，route 會被 advertise 但被忽略。Peering 仍顯示 ACTIVE — 沒有錯誤訊息。打算讓 custom route 流通時，務必雙方都設對應旗標。

Cloud Router 聚合

當 BGP route 從 on-prem 經 Cloud Router 流入 hub VPC，且 hub 與 spoke VPC peering 時，spoke 只有在 hub peering 啟用 --export-custom-routes 時才會看到 on-prem route。這就是「Cloud VPN/Interconnect 落在 hub VPC、spoke 透過 peering 消費 on-prem 連線」這個常見架構的線路設定。

跨組織 Peering 與多組織拓撲

VPC Peering 不需要雙方有任何組織關係。任何擁有 compute.networks.addPeering 權限的 project owner，只要知道對方的 project ID 與網路名稱，就能 peering 到任何 VPC。這讓 peering 在 M&A 整合、partner 連線、multi-tenant SaaS 架構中很有吸引力。

跨 Org 設定

雙方透過頻外（Slack、電子郵件、議題單）交換 project ID 與 VPC 名稱。各自執行 gcloud compute networks peerings create PEERING_NAME --network=LOCAL_VPC --peer-project=PEER_PROJECT --peer-network=PEER_VPC。只要名稱對得上、CIDR 不重疊，peering 就會變成 ACTIVE。

Org Policy 把關

組織層級 policy constraints/compute.restrictVpcPeering 讓中央資安團隊可以白名單或黑名單 peering 目標 project。設成 IN 清單可限制工程師未經資安審核就 peering 到外部組織。

IAM 稽核軌跡

每個 peering 的建立/刪除都會記錄在 Cloud Audit Logs 的 compute.googleapis.com/networks.addPeering 下。可用 Log Sink 加 BigQuery 或 SIEM 整合來偵測異常的跨組織 peering。

託管服務的 Service Networking Peering

使用 Private Service Access（Cloud SQL 私有 IP、Memorystore 等）時，GCP 會在你的 VPC 與 Google 的服務 VPC 之間建立由 service networking 託管的 peering。該 peering 會計入你 25 個的 peering 配額，且依標準 custom-route 旗標輸出 route。對端網路名稱通常是 servicenetworking-googleapis-com。

Peering 配額、限制與規模限制

Peering 有幾個硬性與軟性限制，會在大型拓撲考題中出現。

每個 VPC 的 Active Peering 數

預設軟配額為每個 VPC 25 個 active peering，可申請提高到 50。每個 peering 都占一個 slot，不分方向，也不分組織內或跨組織。超過 50 就必須改用 NCC 或 Shared VPC 整併。

每個 VPC 的 Route 數

Peered VPC 會繼承對端的 subnet route。合併的 route 總數受 VPC 動態路由配額限制（預設約 250，可申請提高）。一個 hub VPC 跟 25 個 peer 互通，每個 peer 又輸出 10 個 subnet 時，inbound route 就有 250，剛好頂到預設上限。撞到牆之前要先規劃路由聚合或配額提升。

每個 VPC 的 Subnet 數

單一 VPC 預設最多 7,000 個 subnet。結合 25 個 peering 上限，這會驅使大型組織在整併方案上選擇 Shared VPC 而非 peering。

Internal Load Balancer 可達性

跨 peering 時，Internal TCP/UDP Load Balancer (ILB) 對 peer VPC 預設可達。Internal HTTP(S) Load Balancer 透過 global access 旗標也可達。Internal Network Load Balancer（區域型 passthrough）跨區域或跨 peering 存取則需要 --global-access 旗標。這是個微妙但常考的細節。

Cloud DNS 可見性

私有 DNS zone 不會自動跨 peering 傳播。必須明確把該私有 zone 共享給對端 VPC（用 gcloud dns managed-zones create --visibility=private --networks=... 做 Cross-Project DNS Binding），或使用 Cloud DNS peering zone。

用 Network Connectivity Center 達成遞移路由

NCC 是現代且官方支援的方式，可以在多個 VPC 之間達成遞移路由，不必架一張 peering mesh。

Hub-and-Spoke 模型

你在 hub project 建一個 NCC hub（區域資源），把 VPC 網路掛成 VPC spoke。所有掛在 hub 上的 spoke 之間自動取得遞移可達性 — spoke 之間不需要手動 peering。

Site-to-Cloud Spoke

NCC 也支援混合 spoke — HA VPN 隧道與 Cloud Interconnect VLAN attachment — 讓你能把 VPC 與 on-prem 站點放在同一個 hub 裡。這是 Google 用來對標 AWS Transit Gateway 與 Azure Virtual WAN 的設計。

Route Policy 與過濾

NCC 支援 BGP 風格的 spoke 路由 policy，可以接受或拒絕特定 prefix。原生 VPC Peering 做不到 — peering 只能依 custom-route 旗標全有或全無地輸出。

NCC vs Shared VPC vs Peering 抉擇

• 當一個團隊應該治理所有網路、且很多 service project 需要共用 IP 空間時，選 Shared VPC。
• 當是少量（≤25）一次性連線、不需要遞移時，選 VPC Peering。
• 需要遞移、可擴充、特別還要混合 spoke 時，選 NCC。

白話文解釋（Plain English Explanation）

Shared VPC：只有一個房東的工業區

把 Shared VPC 想成一個工業區，由單一房東（host project）擁有所有土地、鋪好所有道路、架好電網、寫好所有租約（防火牆規則）。租戶（service project）搬進特定的廠房地塊（subnet），在那裡開工廠。租戶自己付電費（egress 費用）、雇自己的員工（跑自己的 VM 與配額），但他們不能改路、也不能改租約 — 那是房東的工作。IAM 授與 networkUser 就是那份租約，讓租戶能進駐特定地塊。如果要讓新租戶進駐另一塊地，房東會在那個 subnet 上授與 networkUser，絕不會在整個工業區範圍授與。

VPC Peering：兩個鄰居在共用牆上開一道門

VPC Peering 像兩戶共用一面牆的鄰居決定在牆上開一道門。現在他們的孩子可以在客廳之間跑來跑去，不必走出戶外（公網）。但每個家長還是擁有自己的房子，定自己的家規（防火牆規則），付自己的帳單。重點是，如果有第三戶鄰居跟 B 戶也有一道門，A 戶的孩子還是不能到 C 戶 — 要嘛 A 戶也跟 C 戶自己開一道門，要嘛三戶在共用中庭（NCC）會合。「CIDR 不可重疊」這條規則就像兩戶必須有不同的街道門牌號碼；若門牌相同，郵差就不知道信要送哪一邊。

Custom Route 交換：分享你的通訊錄

--export-custom-routes 與 --import-custom-routes 旗標就像把你的通訊錄分享給朋友。預設情況下兩個網路 peering 時，你只分享身邊鄰居的地址（subnet route）。如果朋友想知道你從電話公司學到的所有地址（Cloud Router 經 BGP 學到的 route）或你私人筆記上的（static route），你必須主動扳開「分享我的整本通訊錄」開關，而朋友也必須扳開「我接受你的整本通訊錄」開關。如果只有一邊扳開，什麼事也不會發生 — 兩邊都要同意。這也是為什麼設定錯的 peering 看起來「ACTIVE」但 custom route 卻靜默不通。

常見問題 (FAQs)

Shared VPC 的 host project 可以再與另一個 VPC peering 嗎？

可以。Shared VPC host 的 VPC 從 peering 角度看跟一般 VPC 完全一樣。你可以把它與另一個 VPC（Shared 或一般）peering 來擴充連線，受限於 25 個 peering 配額。常見模式是：企業 Shared VPC 跟第三方 SaaS 合作夥伴的 VPC peering。

VPC Peering 會增加延遲或費用嗎？

沒有可量測的延遲增加。Peering 走的是和同 VPC 流量一樣的 Jupiter fabric。費用上，同區域 peering 流量免費，跨區域 peering 流量依標準跨區域 egress 計費 — 嚴格比兩 VPC 之間建 VPN 隧道便宜。

在 subnet 上撤銷 compute.networkUser 能把 service project 的 VM 趕走嗎？

撤銷 networkUser 會立刻阻止新資源在該 subnet 建立，但不會刪除既有 VM。要強制驅離必須明確刪除那些 VM。這是常見的營運驚喜。

GKE 怎麼搭配 Shared VPC？

Service project 中的 GKE 叢集可以指定 --network=projects/HOST/global/networks/VPC --subnetwork=projects/HOST/regions/REGION/subnetworks/SUBNET 部署到 host project 的 subnet。叢集的 Pod 與 Service 次要範圍必須事先在該 subnet 定義好，且 GKE service agent 必須在該 subnet 與次要範圍上有 compute.networkUser。

刪除 peering 後，兩 subnet 之間的流量會怎樣？

所有從對端學來的 route 會立刻從 VPC route table 撤銷，進行中的 TCP 連線會中斷。沒有 graceful drain。對 production 工作負載刪除 peering 之前，務必安排維護視窗。

可以對 IPv6 subnet 做 peering 嗎？

可以 — 只要兩個 VPC 都啟用 dual-stack，VPC Peering 就支援 IPv6 subnet route。IPv6 範圍同樣遵守不重疊規則（在各 VPC 配置的 ULA 或外部 GUA 區段內），custom-route 旗標也一樣套用。

兩個 VPC peering 後，Cloud SQL 私有 IP 為什麼還是不通？

Cloud SQL Private Service Access 用自己的 service-networking peering。你那兩個 VPC 之間的 peering 不會遞移地共用 Cloud SQL service-networking peering — 那需要遞移路由。解法：(a) 在每個 VPC 各自複製 Cloud SQL instance、(b) 把兩個 VPC 都當 NCC spoke、(c) 改用 Cloud SQL 公網 IP 搭配 Authorized Networks。