為什麼混合網路是架構師的核心戰場
在前面的遷移課程中，我們談到了混合雲架構模式與連線選項的概覽。這一課將深入網路層——當企業同時擁有地端資料中心、GCP 環境、甚至其他雲端供應商時，架構師必須設計出安全、高效能且具備容錯能力的網路拓撲。PCA 考試中，混合連線與網路架構的題目佔有相當比重，理解每種連線方式的特性與適用場景至關重要。
GCP 的混合連線選項構成一個頻譜：從低成本的 VPN 到高頻寬的專用互連，再到跨雲互連，每種方案在頻寬、延遲、成本和可靠性之間有不同的取捨。
Cloud Interconnect：企業級專線連線
Cloud Interconnect 提供地端到 GCP 的私有網路連線，流量不經過公共網際網路，適合大量資料傳輸和延遲敏感的工作負載。
三種 Interconnect 類型
| 面向 | Dedicated Interconnect | Partner Interconnect | Cross-Cloud Interconnect |
|---|---|---|---|
| 頻寬 | 10 / 100 Gbps 單埠 | 50 Mbps - 50 Gbps | 10 / 100 Gbps |
| 連線方式 | 自行在共置設施（colocation）與 Google 直接對接 | 透過服務供應商連線 | Google 代為建立與其他雲端的互連 |
| 延遲 | 最低且最穩定 | 依供應商而定，通常略高 | 低延遲（Google 骨幹網路） |
| SLA | 99.99%（建議雙迴路配置） | 依配置最高 99.99% | 依配置而定 |
| 適用場景 | 大型企業、PB 級資料傳輸 | 無法到達共置設施的中型企業 | GCP + AWS / Azure 多雲架構 |
| 初始建置時間 | 數週（需實體佈線） | 數天至數週 | 數週 |
Dedicated Interconnect 適合在 Google 共置設施（如 Equinix、NTT）有機櫃的企業，提供最高效能與最低延遲。每條連線支援 10 或 100 Gbps，可綁定多條連線（Link Aggregation）達到更高頻寬。
Partner Interconnect 透過已與 Google 對接的電信或網路服務供應商建立連線，適合地理位置無法觸及共置設施的企業，頻寬選項更彈性。
Cross-Cloud Interconnect 是多雲架構的關鍵元件——由 Google 代為建立 GCP 與 AWS、Azure 或 Oracle Cloud 之間的專線連線，流量走 Google 的骨幹網路，免去自行在共置設施中管理跨雲連線的複雜度。
💡 考試小提示：題目出現「multi-cloud connectivity」或「需要 GCP 與 AWS 之間的低延遲專線」，Cross-Cloud Interconnect 是首選答案。這是較新的服務，考試中出現頻率正在增加。
HA VPN：靈活且加密的連線
HA VPN（High Availability VPN）透過 IPsec 加密通道連接地端與 GCP，流量走公共網際網路但全程加密。相較於 Interconnect，HA VPN 建置快速、成本較低，是最常見的混合連線起步方案。
HA VPN vs Classic VPN
| 面向 | HA VPN | Classic VPN（已停止新建） |
|---|---|---|
| SLA | 99.99%（正確拓撲下） | 99.9% |
| 介面 | 雙介面（自動分配外部 IP） | 單介面 |
| 路由 | 僅支援動態路由（BGP） | 支援靜態與動態路由 |
| 建議用途 | 所有新建 VPN | 不建議新建 |
要達到 99.99% SLA，HA VPN 需要正確的拓撲配置：兩個 HA VPN Gateway 介面各建立通道至對端的兩個介面，確保任一介面故障時流量可自動切換。搭配 Cloud Router 的 BGP 動態路由，failover 過程完全自動化。
💡 考試小提示：題目強調「99.99% VPN SLA」時，答案必須包含 HA VPN + 正確的雙通道拓撲 + BGP 動態路由。缺少任一元素都無法達到 99.99%。
Cloud Router：混合網路的路由大腦
Cloud Router 是 GCP 的託管 BGP 路由器，負責在 GCP 和地端（或其他雲端）之間動態交換路由資訊。它是 HA VPN 和 Cloud Interconnect 的必要搭配元件。
核心功能
- BGP Sessions — 與地端路由器建立 BGP 對等連線，自動學習和宣告路由
- Custom Route Advertisements — 自訂向地端宣告的路由，例如只宣告特定子網路或匯總路由，控制流量走向
- Global vs Regional Dynamic Routing — VPC 層級設定；Regional 模式下 Cloud Router 只宣告同區域的子網路，Global 模式下宣告所有區域的子網路
路由模式選擇
| 模式 | 行為 | 適用場景 |
|---|---|---|
| Regional | Cloud Router 只學習和宣告同區域的路由 | 單一區域部署、簡單拓撲 |
| Global | Cloud Router 學習和宣告所有區域的路由 | 多區域部署、需要跨區域容錯 |
💡 考試小提示：遇到「地端需要存取多個 GCP 區域的資源」這類題目，務必確認 VPC 的 Dynamic Routing Mode 設為 Global，否則地端只能看到連線所在區域的路由。
Cloud DNS：混合環境的名稱解析
DNS 在混合環境中往往是被低估但極為關鍵的基礎設施。Cloud DNS 是 GCP 的全託管 DNS 服務，支援公有和私有區域。
混合 DNS 架構
- Public Zones — 對外的網域解析（如
example.com），全球 Anycast 網路提供低延遲 - Private Zones — 僅在指定 VPC 內解析的內部網域（如
internal.corp.example.com） - DNS Forwarding — 將特定網域的查詢轉送至地端 DNS 伺服器（Outbound Forwarding），或讓地端查詢 GCP 的 Private Zone（Inbound Forwarding）
- DNS Peering — 讓一個 VPC 的 DNS 查詢可以解析另一個 VPC 的 Private Zone，無需建立 VPC Peering
- DNSSEC — 為公有區域啟用 DNS 安全擴充，防止 DNS 欺騙攻擊
Split-Horizon DNS
在混合環境中，同一個網域名稱（如 app.example.com）在內部和外部需要解析到不同的 IP 位址——內部流量走私有 IP，外部流量走公有 IP。這就是 Split-Horizon DNS 的典型應用場景，透過 Cloud DNS 的 Private Zone 覆蓋 Public Zone 中的相同記錄來實現。
Hierarchical Firewall Policies：企業級網路治理
對於大型企業，逐一管理每個 VPC 的防火牆規則既費時又容易出錯。Hierarchical Firewall Policies 允許在組織（Organization）或資料夾（Folder）層級定義防火牆規則，自動套用到所有下層專案和 VPC。
核心概念
- Policy 層級 — Hierarchical Firewall Policy 僅能掛在 Organization 與 Folder 兩層；評估順序為 Organization Policy → Folder Policy → 各 VPC 的防火牆規則（從高到低，最後才下放到 VPC 層的 VPC firewall rules / network firewall policy）
- 優先順序（Priority） — 數字越小優先順序越高，
0最高、65535最低 - 動作 —
allow、deny、goto_next（交由下一層級決定）、apply_security_profile_group - 繼承邏輯 — 高層級的
allow或deny會覆蓋低層級規則；使用goto_next則將決策權下放
治理場景
- 安全團隊在 Organization 層級封鎖所有 SSH（port 22）從外部存取
- 特定開發資料夾透過
goto_next豁免，允許在 VPC 層級自行管理 SSH 規則 - 全組織強制允許 GCP Health Check 的 IP 範圍，確保 Load Balancer 正常運作
💡 考試小提示：當題目提到「organization-wide security policy」或「centralized firewall management」，Hierarchical Firewall Policies 是標準答案。注意
goto_next的用法——它是實現「集中管理但彈性例外」的關鍵。
Network Connectivity Center：Hub-and-Spoke 架構
Network Connectivity Center（NCC） 是 GCP 的網路中樞服務，實現 hub-and-spoke 拓撲，讓多個地端站點透過 Google 的全球骨幹網路互相通訊。
核心價值
- Transit Connectivity — 地端站點 A 的流量可以透過 GCP 骨幹傳輸至地端站點 B，無需額外建立站點間的專線
- Spoke 類型 — 支援 HA VPN、Cloud Interconnect（VLAN Attachment）和 Router Appliance 作為 spoke
- 集中管理 — 在單一 Hub 中統一管理所有連線的路由和策略
NCC 特別適合擁有多個分支辦公室或資料中心的企業，將 Google 的全球網路當作廣域網路（WAN）的骨幹，取代昂貴的 MPLS 專線。
連線方式選型決策
面對考試或實際設計時，根據以下決策表快速收斂答案：
| 需求特徵 | 建議方案 | 理由 |
|---|---|---|
| 頻寬 > 10 Gbps，延遲敏感 | Dedicated Interconnect | 最高頻寬、最低延遲 |
| 中等頻寬，無共置設施 | Partner Interconnect | 透過供應商靈活連線 |
| GCP 與其他雲端專線 | Cross-Cloud Interconnect | Google 代管跨雲連線 |
| 快速建置、成本敏感、加密需求 | HA VPN | 數小時內建置完成 |
| 多站點透過 GCP 互聯 | NCC + HA VPN / Interconnect | Hub-and-spoke 架構 |
| Interconnect 的備援通道 | HA VPN | 成本效益高的備援方案 |
💡 考試小提示：PCA 考試常考「最具成本效益的方案」——如果題目沒有明確的高頻寬或低延遲需求，HA VPN 通常是正確答案。Interconnect + HA VPN 的組合也是經典考題，主線路走 Interconnect，備援走 VPN。
實戰情境
情境一：跨國企業多站點連線
背景：一家零售集團在台北、東京、新加坡各有一座資料中心，需要統一連接到 GCP 進行集中分析，同時三個站點之間也需要互相通訊。
架構決策：
- 台北總部流量最大 → 使用 Dedicated Interconnect（2 x 10 Gbps，雙迴路 99.99% SLA），搭配 HA VPN 作為備援通道
- 東京和新加坡 → 使用 Partner Interconnect 連接至最近的 GCP 區域
- 三站點互聯 → 部署 Network Connectivity Center，將三條 Interconnect 作為 spoke 連接至中央 Hub，流量透過 Google 骨幹傳輸
- 所有連線搭配 Cloud Router（Global Dynamic Routing），確保任一區域的子網路變更自動傳播至所有站點
- DNS → Cloud DNS Private Zone + Forwarding，讓雲端和地端共用統一的內部名稱解析
情境二：金融業多雲合規架構
背景：一家銀行主要工作負載在 GCP，但因監管要求需要將部分災難復原環境部署在 AWS，同時地端核心銀行系統仍需維持連線。
架構決策：
- GCP 與 AWS 之間 → Cross-Cloud Interconnect（10 Gbps），確保跨雲資料複製的低延遲和穩定頻寬
- 地端與 GCP → Dedicated Interconnect + HA VPN 備援
- 網路治理 → Hierarchical Firewall Policies 在 Organization 層級強制執行金融合規的網路隔離規則，各部門透過
goto_next管理細部規則 - DNS → Split-Horizon DNS 確保內部系統走私有連線，外部客戶走公有端點
重點整理
- Cloud Interconnect 三種類型各有定位：Dedicated（最高效能）、Partner（彈性部署）、Cross-Cloud（多雲專線）
- HA VPN 提供 99.99% SLA，但前提是正確的雙通道拓撲 + BGP 動態路由
- Cloud Router 是所有混合連線的路由核心，注意 Global vs Regional Dynamic Routing 的差異
- Cloud DNS 在混合環境中需要 Forwarding 和 Private Zone 搭配，Split-Horizon DNS 是常見設計模式
- Hierarchical Firewall Policies 實現企業級集中式網路治理，
goto_next是彈性管理的關鍵 - Network Connectivity Center 讓多個地端站點透過 Google 骨幹互聯，取代昂貴的 MPLS
- 選型決策核心：頻寬需求決定 Interconnect vs VPN，地理位置決定 Dedicated vs Partner，多雲需求選 Cross-Cloud
下一步
在下一課中，我們將深入運算與儲存系統配置，包括 GKE 叢集配置、Cloud Run 進階設定、持久化儲存選型與 Spot VM 成本優化策略。