VPC 設計與資源階層簡介
在 Google Cloud 中，VPC 不僅僅是一張網路，而是一張全球性的軟體定義網路骨幹，支撐著每一台 Compute Engine 虛擬機、每一個 GKE 節點、每一條 Cloud Run 直連 VPC 的出口連線、以及每一台採用私有 IP 的 Cloud SQL 執行個體。PCNE 考試實際在測的，是你能否把這張骨幹延伸到整個組織而不會在六個月後把自己畫進死角——當初建立 default VPC 的團隊早已離開，三個事業單位都想加入卻又不想重新編號。本份學習筆記涵蓋考試真正會問的選擇題：auto-mode 與 custom-mode、子網路與 CIDR 規劃、Alias IP 與 GKE 次要範圍、MTU 調校、Shared VPC 拓樸、Network Connectivity Center hub-and-spoke、單一 VPC 與多 VPC 的權衡、配額、以及那些能讓你第一天的小失誤不會變成第 365 天大停機的組織政策約束。
Google Cloud Resource Hierarchy 的「組織—資料夾—專案」三層階層包覆著每一個 VPC。host project 放在哪個資料夾、由誰擁有，決定了誰能加入、誰能稽核、計費如何彙整。所以 VPC 設計與資源階層既是路由議題，也是治理議題。
白話文解釋（Plain English Explanation）
網路抽象概念用實體例子來理解通常最快。
把 VPC 想像成一條私人高速公路系統
大多數雲端供應商給你的是一條到州界就停下來的區域收費公路。Google 的 VPC 是一條全球高速公路。你規劃一套高速公路系統，在每個城市倒出像子網路一樣的交流道，一輛從聖保羅進入的車（封包）可以一路開到新加坡的出口而不需要離開你的柏油路面。Cloud Router 是與外面高速公路用 BGP 溝通的交通控制中心。Auto-mode 是建商免費送你的制式高速公路——每個地區都有 /20 交流道；custom-mode 則是你自己丈量地形、依照實際要跑的卡車尺寸來鋪的高速公路。生產環境的團隊絕大多數選 custom-mode，原因就跟城市拒絕忽略當地地形的預鑄高速公路一樣。
把 Shared VPC 想像成一間購物商場
購物商場有一個房東擁有整棟建築、停車場、水電管線。租戶——美食街、書店、健身房——租下空間經營自己的生意，但都接到房東的基礎設施。在 Shared VPC 裡，host project 就是擁有網路、子網路、防火牆規則、Cloud Router 的房東；service projects 是租戶，他們的 VM 和 GKE 叢集住在房東的子網路裡。一位水電工（網路管理員）處理所有漏水；租戶不能重畫樓層平面，但可以裝潢自己的店面。這就是為什麼中央網路團隊堅持用 Shared VPC，而不是讓每個產品團隊各自蓋 VPC 然後再全部 peering 起來。
把 NCC 想像成機場樞紐
在 hub-and-spoke 機場出現之前，每一個航班都需要從 A 城市直飛 B 城市，整張班表像一鍋義大利麵。樞紐機場（想想亞特蘭大或杜哈）把這張網狀圖收斂：spoke 連到 hub，hub 處理所有轉乘。Network Connectivity Center 就是雲端與站點之間流量的機場樞紐。你的 VPC、VPN 通道、Interconnect 介接都變成 spoke。Hub 統籌轉乘，你不必再去蓋 N×N 的完整 mesh peering，不必再去算 peering 配額，也不必再去稽核上千條雙邊路由。當考題問你怎麼把跨四個地區的 30 個 VPC 串起來又不被配額燒到崩潰時，答案幾乎一律是 NCC。
VPC 設計與資源階層的核心概念
Google Cloud 上的 VPC 設計與資源階層由幾個基本元件組成，技藝在於把它們組合成一張能撐過組織重組、併購、第二波 GKE 叢集的網路。
全域 VPC、區域子網路、區域 VM
VPC 本身是一個全域資源——gcloud compute networks create prod-vpc --subnet-mode=custom 建立一個同時存在於所有 Google 地區的物件。子網路則是區域性的：gcloud compute networks subnets create web-use1 --network=prod-vpc --region=us-east1 --range=10.10.0.0/22。VM 與 GKE 節點池是這些子網路的區域或地區層級消費者。考試很喜歡測你能不能說清楚：單一 VPC 可以觸及所有地區，但每個你想用的地區都還是需要建一個子網路。
Auto-mode 與 custom-mode
Auto-mode VPC 會在每個 Google 地區自動拿到一個 /20 子網路，全部從預留的 10.128.0.0/9 區塊切出來。實驗用很方便，生產環境很危險：範圍會跟常見的內部部署區塊重疊、不能縮減、每新增一個 Google 地區就會默默多一個子網路。Custom-mode VPC 一開始是空的，每個子網路都要明確建立。組織政策 compute.skipDefaultNetworkCreation 可以阻止新建專案自動生成 auto-mode default 網路；compute.restrictVpcPeering 則讓平台團隊管控誰能 peering。
子網路與區域資源界線
每個子網路有一個主要 IPv4 範圍、選擇性的次要範圍清單、選擇性的 IPv6 範圍，以及一個所在地區。同一 VPC 內子網路範圍不得重疊。你可以無中斷地擴充主要範圍（gcloud compute networks subnets expand-ip-range），但不能縮小，也不能把子網路搬到另一個地區。Private Google Access 是子網路層級的開關，不是 VPC 層級——這個細節考試會反覆考。
動態路由模式
VPC 的 BGP 範圍由它的動態路由模式決定。regional 表示 Cloud Router 只宣告自己地區的子網路，也只學習自己地區的路由。global 表示每一台 Cloud Router 都宣告 VPC 內所有子網路，也接受所有地區進來的 BGP 前綴。生產環境的混合雲設計幾乎一律要 global，這樣 us-east1 的 Interconnect 故障時，europe-west1 的工作負載才不會被孤立。切換指令是 gcloud compute networks update prod-vpc --bgp-routing-mode=global。
為長期目標規劃 CIDR
CIDR 規劃是 VPC 設計與資源階層中，工程師偷懶不做、公司規模翻倍時就後悔的部分。
先預留、再配發
把你的 VPC 當成 IP 配發者，不是 IP 消費者。先切出一個超網——例如 10.0.0.0/9——然後依地區、依環境、依可用區再往下分配。一個務實的配置是：10.0.0.0/12 給 us-east 生產、10.16.0.0/12 給 us-west 生產、10.32.0.0/12 給 europe-west 生產，平行的 10.128.0.0/9 保留給非生產環境。考試期望你能辨識範圍衝突、以及如何在不重新編號既有工作負載的情況下修補（劇透：修不了，所以一次做對）。
避開 Google 保留範圍
169.254.0.0/16（link-local）、192.168.0.0/16 與 172.16.0.0/12（內部部署常用的 RFC1918 片段）、以及 Google 自家的負載平衡器範圍都不該拿來當可路由子網路。Private Service Connect 範圍、35.191.0.0/16 與 130.211.0.0/22 健康檢查範圍、auto-mode 的 10.128.0.0/9 也都不是你的——健康檢查必須放行但不能配給 VM。
預先處理 VPN 與 Interconnect 的範圍重疊
內部部署網路常常落在 10.0.0.0/8 或 192.168.0.0/16。如果你的新 VPC 哪怕只跟公司辦公網重疊一個 /24，HA VPN 會話就會拒絕安裝衝突路由。挑選的 VPC 超網要被記錄在公司 IPAM 中，並視為不可變動。
Google Cloud VPC 一個子網路約可有 300 個次要範圍（預設軟性配額），每個 VPC 每個地區預設 100 個子網路。這些數字看起來很大，但只要一個 GKE 叢集就會吃掉兩個次要範圍（Pod 與 Service）。第一個叢集建出來之前就先把 CIDR 圖規劃好——重新編號正在運行的 GKE 叢集等於重建。
次要範圍、Alias IP 與 GKE
Alias IP 是 Google Cloud 讓一台 VM 或 GKE 節點不需第二片 NIC 就能擁有許多額外 IP 位址的機制。所有 alias 位址都必須落在子網路的次要範圍內。
次要範圍如何運作
子網路宣告一個主要範圍（給節點自己的 NIC）和零個以上具名次要範圍。gcloud compute networks subnets create gke-use1 --range=10.10.0.0/22 --secondary-range=pods=10.20.0.0/16,services=10.30.0.0/20 會建立一個子網路：NIC 在 10.10.0.0/22，Pod IP 從 10.20.0.0/16 抽取，Service ClusterIP 從 10.30.0.0/20 抽取。每個 Pod 都拿到一個真正可路由的 IP——沒有 overlay 封裝——這也是為什麼 VPC-native（Alias IP）是 GKE 的預設網路模式。
Pod 與 Service 範圍的大小估算
GKE 節點池預設每個節點 110 個 Pod，意味著每個節點吃掉 Pod 範圍裡一塊 /24。100 個節點的叢集因此需要 100 × /24 = /17 的空間。再翻倍給自動擴展用是常規做法。Service 範圍可以小一點——/20 對多數叢集都夠——但建立後不能擴充，所以要為成長預留。
不連續多重 Pod CIDR
較新版的 GKE 支援單一叢集多個不連續 Pod CIDR，挽救了那些一開始預留不夠位址空間的團隊。加上 --additional-pod-ipv4-ranges 就可以在不重建叢集的前提下再掛一個次要範圍——情境題若以「我們 Pod IP 用完了」開頭，考題暗示的就是這個解法。
子網路的次要範圍會計入 VPC 與專案層級的配額，且不能與同一 VPC 內任何主要或次要範圍重疊。把同一個 10.20.0.0/16 在兩個地區子網路「重複使用」的團隊，會在 peering 時發現第二個範圍默默匯入失敗。即使現在沒打算 peering，也要配發互不重疊的次要範圍。
MTU：1460、1500 與 8896
MTU 是 VPC 設計與資源階層裡最被忽略的旋鈕，也是唯一一個可以把 Dataflow shuffle 吞吐量砍半的設定。
三個合法的 VPC MTU 值
Google Cloud VPC 接受三個 MTU 值：1460（舊版預設）、1500（標準 Ethernet，自 2021 年起為新 VPC 的預設）、8896（jumbo frame）。gcloud compute networks update prod-vpc --mtu=8896 可切換，但只對切換後新建或重啟的 VM 生效。混合 MTU 的 VPC 不被支援——每個子網路都繼承 VPC 層級的 MTU。
何時 jumbo frame 才划算
8896 的 jumbo frame 能降低高吞吐東西向流量的每封包額外負擔——Dataflow shuffle、BigQuery 匯出、Filestore Enterprise、GKE 節點之間的 Pod 流量。當工作負載並非 CPU bound 時，10–20% 的吞吐提升是常態。網際網路出口會在邊緣分片回 1500，所以 jumbo frame 是內部最佳化，不是 WAN 招式。
Interconnect 與 VPN 的 MTU 不一致
Dedicated Interconnect 介接視配置支援 1440、1460、1500 或 8896；HA VPN 則因為 IPSec 在已經只有 1500 的承載網之上再多一層額外負擔而上限只到 1460。經典的失敗情境是 VPC 設為 8896 但要透過 HA VPN 與內部部署通訊——TCP 因 PMTU discovery 還能動，但 UDP-based 工作負載（DNS、遊戲流量）卻會被默默黑洞。VPC MTU 一律設為混合路徑上的最小 MTU，否則就接受你必須在出口側做 MSS clamping。
VPC MTU 值：1460（舊版預設）、1500（現行預設）、8896（jumbo）。HA VPN 上限：1460。Dedicated Interconnect 上限：8896。PMTU discovery 預設啟用，但需要 ICMP「Fragmentation Needed」能穿過內部部署防火牆——這是個常見的故障排除題型。
Shared VPC 拓樸模式
Shared VPC 是讓單一網路團隊集中控制、又能讓眾多產品團隊持續出貨的標準做法。
Host project 與 service projects
Shared VPC 的 host project 擁有 VPC、子網路、防火牆規則和 Cloud Router。Service project 透過 gcloud compute shared-vpc associated-projects add service-proj --host-project=host-proj 掛到 host。Service project 內的使用者可以建立 VM、GKE 叢集、內部負載平衡器、Cloud SQL 執行個體並使用 host project 裡的子網路，但不能建立新子網路、不能修改防火牆規則、也不能改路由。子網路上的 compute.networkUser 角色才是給予 service project 使用者使用「該特定子網路」的權利——不是整個 VPC。
單一 host 與多 host
多數組織至少需要兩個 host project：一個生產、一個非生產，有時還會加一個安全/DMZ 工作負載專用的。每個 host 內你還可以用子網路層級 IAM 再切環境。常見的反模式是「為了簡化」把所有東西塞進一個 host project——直到你需要在非生產環境部署中途緊急改生產防火牆的那一刻，才發現為什麼 host project 要分開。
Shared VPC 與 VPC Peering
Peering 在路由層串起兩個 VPC，但每個專案仍各自擁有自己的 VPC、各自的防火牆面、各自的配額負擔。Shared VPC 把治理收斂到單一 VPC。考試喜歡這種情境：正確答案是「Shared VPC——peering 需要 N×(N-1)/2 個連線並強迫每個團隊重複實作防火牆政策」。
每個環境（prod、non-prod、dmz）配一個 Shared VPC host project，每個環境用一個資料夾包住 host 與其 service project。這個對應讓 IAM 繼承可預測，刪掉一整套非生產環境只要刪一個資料夾，完全不會碰到生產。
用 Network Connectivity Center 做 Hub-and-Spoke
Network Connectivity Center（NCC）是 Google 對 peering 配額牆的解法。
Hub、spoke 與資源 attachment
NCC hub 是一個全域控制物件，每個組織網域建立一次：gcloud network-connectivity hubs create global-hub。Spoke 掛到 hub 上，可以代表 VPC、HA VPN tunnel、Interconnect 介接、第三方 SD-WAN router。一個 VPC spoke 實際上讓多個 VPC 透過 hub 交換路由，省掉 N×(N-1)/2 的 peering。Interconnect 上的站點對雲流量也能透過 hub 被每個 spoke VPC 觸及，不必再蓋一堆站對站 VPN。
Site-to-cloud 與 cloud-to-cloud
NCC 有兩種資料平面。Site-to-cloud（最早版本）把 VPN/Interconnect spoke 上的內部部署流量帶進單一中轉 VPC。Cloud-to-cloud（較新）則讓多個生產 VPC 透過 hub 本身做完整 mesh，消除了中轉 VPC 與卡在它中間的 Compute 設備瓶頸。考題用症狀來區分兩者：當客戶有「30 個 VPC 而且 peering 配額還在漲」時，答案就是 cloud-to-cloud。
何時用 NCC 取代中轉 VPC
傳統中轉 VPC 架構會在中間放一台第三方防火牆或路由器，逼所有流量都穿過它。NCC 透過 hub 本身做路由交換，消除了東西向流量的單點故障。你仍然需要狀態防火牆，但可以把它放在 spoke 邊緣（Cloud NGFW、Cloud Armor），而不是塞在中間掐住喉嚨。
單一 VPC 與多 VPC 的權衡
「一個大 VPC 還是很多小 VPC」是 PCNE 架構審查最常見的單一議題。
單一 VPC 何時勝出
如果你的安全模型接受子網路層級防火牆隔離、每個團隊都共用 IAM、且你還沒撞到配額上限，一個全域 VPC 能讓路由維持簡單。內部負載平衡器觸及所有地區、Private Service Connect 端點運作一致、防火牆面只有一份要稽核。
多 VPC 何時勝出
強租戶界線（HIPAA 工作負載不能與行銷分析共用控制平面）、法規資料居留禁止某些出口路徑、併購中兩張網路要共存好幾年、超過單一 VPC 防火牆規則上限（預設 500 ingress、可申請放寬但仍有上限）的專案，都會把你推向多 VPC。多 VPC 也縮小爆炸半徑——某個 VPC 不小心宣告錯誤的 BGP 前綴不會毒到另一個。
折衷：Shared VPC 加上選擇性 peering
成熟的組織最後通常會落在少量 Shared VPC host project（每個環境一個）之間用 NCC 或選擇性 peering 串接，加上 PSC 消費端點橋接到廠商管理的 VPC。這個折衷正是考題在問「我們要怎麼擴展到 10 個以上團隊又不要 N×N peering」時通常期待的答案。
VPC 配額、上限與專案足跡
配額不是考試的瑣碎細節——它直接決定什麼方案行得通。
每個 VPC 與每個專案的限制
值得背的預設值：每個專案 5 個 VPC（軟性、可申請放寬）、每個 VPC 每個地區 100 個子網路、每個 VPC 25 個 VPC peering 連線、每個 VPC 200 條路由、每個 VPC 500 條防火牆規則（軟性）、每個專案每個地區 7 台 Cloud Router。每個子網路次要範圍預設約 300。VPC 總 IP 位址數沒有限制，只要底層 CIDR 夠大。
Peering 數學與為何 NCC 重要
Peering 只有在 NCC 上才有遞移性，原生 VPC peering 沒有。要把 10 個 VPC 用原生 peering 做完整 mesh，需要 45 條 peering，每條都計入單一 VPC 25 條的上限。超過 6 個 VPC 之後，這道牆就無法迴避。NCC cloud-to-cloud spoke 把 45 條 peering 換成 10 條 spoke attachment，消除了平方爆炸。
如何監控配額
Cloud Monitoring 在 compute.googleapis.com/quota/usage 之下提供每個資源的配額指標。在 70% 用量處掛告警——路由或防火牆規則一旦過 90%，緊急變更可能就無法執行，配額提升工單動輒幾個小時起跳。
組織政策約束與治理
VPC 設計與資源階層的耐用度，最終由保護它免於善意專案擁有者誤觸的組織政策決定。
鎖住第零天失誤的約束
compute.skipDefaultNetworkCreation 阻止任何新專案建立 auto-mode default VPC——對生產資料夾來說是最有用的單一約束。compute.restrictVpcPeering 允許清單限制哪些專案可以發起 peering。compute.restrictSharedVpcHostProjects 與 compute.restrictSharedVpcSubnetworks 控制 service project 可以掛到哪些 host project 與子網路。
預防資料外洩的約束
compute.vmExternalIpAccess 允許清單限制哪些 VM 可以擁有對外 IP——對合規敏感工作負載至關重要。再搭配 BigQuery、Storage、Pub/Sub 周圍的 VPC Service Controls 周邊，這條約束就能阻止開發者開個臨時 VM 加對外 IP 把資料複製出去。
資料夾繼承與例外處理
組織政策採用資料夾層級繼承並允許每個資料夾覆寫。可行的模式是：在組織層級預設拒絕、在沙箱或開發資料夾以例外允許、在生產資料夾再次拒絕。每次新增資料夾時用 gcloud resource-manager org-policies list --folder=FOLDER_ID 稽核繼承關係。
組織建立的那一天就把 compute.skipDefaultNetworkCreation = true 設在組織層級。default VPC 預載「允許所有內部流量」防火牆規則和可預測的 10.128.0.0/9 範圍，會與內部部署衝突。等到組織內已有上千個專案才回頭清，是一個跨季度的工程。
維運模式與考試陷阱
PCNE 考試常出現幾種維運模式。
子網路擴充是單向操作
gcloud compute networks subnets expand-ip-range 可以把 /24 擴成 /22，但反向不行。如果一開始給太多，就得永遠揹著。如果給太少，可以擴一次，直到撞到隔壁子網路。
Auto-mode 遷移到 custom-mode
存在單向遷移：gcloud compute networks update <name> --switch-to-custom-subnet-mode。Auto-mode VPC 不能與範圍重疊的 custom-mode VPC peering，這也是團隊在併購過來的公司帶著 auto-mode default 出現時會撞牆的原因之一。
IPv6 雙堆疊
外部 IPv6 是子網路層級，Google 從 /64 區塊配發。內部 IPv6（ULA）是 VPC 層級，從 fd20::/20 抽取。內部 IPv6 一旦啟用就無法關閉，所以要刻意決定才開。防火牆規則需要分別有 v4 與 v6 的 ingress 條目——最常見的雙堆疊故障就是忘了 v6 ACL。
VPC-native（Alias IP）：一種 GKE 叢集網路模式，Pod IP 在 VPC 內可路由，因為它們從節點子網路的次要範圍抽取而非用 overlay 封裝。這是預設模式，也是 Private Service Connect、跨地區內部 Pod-to-Pod 通訊、以及大多數受監管工作負載的必要模式。
常見問題
一個子網路能跨越多個地區嗎？
不能。每個子網路都是區域性。但一個 VPC 跨越所有地區，通常每個你想用的地區建一個子網路。
建立後我能縮小子網路的主要範圍嗎？
不能。可以用 gcloud compute networks subnets expand-ip-range 擴大，但無法縮小——只能把工作負載遷移到新子網路後刪掉舊的。
跨專案連線時，Shared VPC 與 VPC Peering 有何差別？
Shared VPC 把一張網路集中到 host project，讓許多 service project 共享；peering 則是在路由層串起兩個各自獨立擁有的 VPC。Shared VPC 可擴展到數十個團隊而不必每個專案重複設防火牆；peering 約在 6 個 VPC 時就會撞到單一 VPC 25 條的配額牆。
什麼時候該用 Network Connectivity Center 而不是原生 VPC peering？
當你需要連接超過約 6 個 VPC、當你需要站點與雲端之間的遞移路由、或是當你想要一個樞紐統籌混合雲流量而不要傳統中轉 VPC 時。
新生產 VPC 該用什麼 MTU？
1500 是安全預設，且能與 HA VPN 一起運作。只有當你能控制兩端、不依賴 HA VPN、且工作負載能受益於 jumbo frame（Dataflow shuffle、GKE 節點間吞吐、Filestore Enterprise）時，才用 8896。
單一子網路能有多少個次要範圍？
預設軟性配額大約 300，但實際的叢集會用 2–5 個。更大的限制是次要範圍不能與同一 VPC 內任何主要或次要範圍重疊。
compute.skipDefaultNetworkCreation 約束會影響既有專案嗎？
不會——它只阻止新專案自動建立 default VPC。既有的 default 網路必須手動或透過自動化管線刪除。
切換 VPC 動態路由模式會中斷服務嗎？
不會。gcloud compute networks update <name> --bgp-routing-mode=global 是控制平面變更，幾分鐘內生效，且不會中斷既有流量。遠端地區 Cloud Router 上的新 BGP 工作階段可能需要重新建立才會開始宣告更廣的範圍。