Google PCA: 網路、混合式連線與流量架構 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

屬於 Google Professional Cloud Architect — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Google Cloud 上的網路、混合式連線與流量架構，主要圍繞著安全、可擴充的 Virtual Private Cloud (VPC) 設計；可靠的混合式互連；智慧的流量管理；以及強健的可觀測性。其目標是提供低延遲、具彈性的服務，並具備清晰的區隔、受控的輸出流量，以及可預測的故障模式。本節將概述核心 Google Cloud 網路服務的實用設計模式、權衡取捨與操作指南。

VPC 架構與區隔

• 位址規劃與子網路

  • 使用自訂模式 VPC 來控制子網路的建立與 IP 位址分配。避免在正式環境中使用預設 VPC。
  • 及早分配不重疊的 RFC1918 區塊。考量未來的成長、高可用性拓撲，以及混合式擴充。為服務（例如 Private Service Connect 端點）以及對等互連/Interconnect 預留範圍。
  • 偏好使用較小的、依功能或環境劃分的子網路，而非大型扁平網路，以最小化故障爆炸半徑並簡化防火牆設定。

• 路由

  • 每個 VPC 都有一個系統路由表；路由會依據最長前綴匹配，然後是優先順序進行評估。Google 管理的路由包含預設網際網路路由（若存在外部 IP）以及子網路路由。動態路由則是透過 Cloud Router 與地端交換。
  • 謹慎使用自訂靜態路由；盡可能依賴動態路由以獲得彈性。除非是作為刻意的控制措施，否則應避免使用黑洞路由。

• 防火牆規則

  • VPC 防火牆是狀態式的，並依優先順序評估，結尾有隱含的拒絕規則。以網路標記或服務帳戶為目標；與標記相比，以服務帳戶為目標能提供更強的身分保證。
  • 依目的（健康狀態檢查、層內通訊、管理用途）區分允許規則，並將其範圍限定在來源服務帳戶或 IP 範圍。
  • 為關鍵規則記錄防火牆決策至 Cloud Logging，以協助鑑識與效能分析。

• 階層式防火牆政策與組織政策

  • 階層式防火牆政策應用於組織或資料夾層級，並在 VPC 層級的規則之前進行評估。使用它們來設定全域性的防護機制（例如，拒絕 0.0.0.0/0 的 SSH），讓專案無法覆寫。前置與後置政策提供了彈性，但較高層級的拒絕規則無法被取代。
  • 搭配組織政策限制（例如，限制建立外部 IP、不允許專案建立 VPC 對等互連）來強制執行治理。

• Shared VPC 與區隔

  • 使用 Shared VPC 將網路集中在宿主專案 (Host Projects) 中，同時將工作負載隔離在服務專案 (Service Projects) 裡。此模式可減少重複的輸出路徑、標準化控制措施，並簡化混合式傳輸。
  • 將環境（正式、非正式）隔離在不同的宿主專案或資料夾中；透過階層式政策與獨立的子網路來強制執行區隔。限制 IAM，使僅有網路維運團隊能管理宿主專案的資源。

• VPC Network Peering

  • 對等互連是私密、可擴充且低延遲的，但非傳輸性。它最適合用於連接自主網路或第三方管理的服務。避免使用對等互連來建立傳輸中樞；應使用 Network Connectivity Center 進行傳輸，或使用集中式的 Shared VPC。
  • 限制：不允許重疊的 IP；某些路由（例如，預設網際網路路由）和部分服務不會被傳播。設計時需了解自訂路由的匯入/匯出。

權衡取捨與故障模式：

• 重疊的 IP 範圍會阻擋對等互連與混合式路由交換；可透過重新編號或 NAT 解決。
• 過於寬鬆的防火牆規則或遺漏健康狀態檢查規則，會導致服務中斷與難以診斷的行為。
• 靜態路由會產生脆弱的依賴關係；偏好使用 Cloud Router 以進行容錯移轉。

流量管理、DNS 與邊緣安全

• Cloud Load Balancing 模式

  • External HTTP(S) Load Balancer 是全域 anycast，具備單一 anycast VIP、跨區域容錯移轉、路徑與主機路由，以及 CDN/Armor 整合功能。適用於面向網際網路的 Web 與 API 工作負載。
  • Internal HTTP(S) Load Balancer 是區域性的，用於 VPC 內部或透過 Private Service Connect 的服務對服務流量。
  • External/Internal TCP/UDP Network Load Balancer 是區域性的 L4 平衡器；適用於非 HTTP 協定或需要保留來源 IP 的情境。
  • 後端服務與網路端點群組 (NEGs)：為 VM 集區使用區域級執行個體群組後端；為 GKE、混合式後端或 Cloud Run 使用區域級、地區級或無伺服器 NEGs。根據不同的流量類別、健康狀態設定檔或容量政策，建立獨立的後端服務。例如：透過路徑路由將新舊 API 版本導向不同的後端服務，讓它們在同一個主機名稱下提供服務，同時保持兩者皆可獨立部署與擴展。

• 健康狀態檢查與常見陷阱

  • 健康狀態檢查必須由防火牆允許。對於外部 HTTP(S) 健康狀態檢查，需允許 130.211.0.0/22 和 35.191.0.0/16 的流量存取後端。若缺少此規則，會導致後端被標記為不健康，且如果自動擴展功能對負載平衡器的信號做出反應，將會造成 VM 快速重啟。
  • 將健康狀態檢查的路徑和通訊埠與容器的 readiness endpoints 對齊；設定逾時和閾值，以在快速容錯移轉與避免誤判之間取得平衡。

• DNS 架構

  • 使用 Cloud DNS 作為權威區域 (authoritative zones)。為內部名稱建立私有區域；為網際網路名稱建立公開區域。
  • Split-horizon DNS：透過建立名稱相同但分開的公開與私有區域，來對內部與外部提供不同的解析答案。這能安全地支援私有服務主機名稱和公開紀錄。
  • 轉送與對等互連區域：使用 DNS 政策與伺服器政策，將特定網域的查詢轉送到地端 DNS，以達成整合；使用條件式轉送來避免遞迴迴圈。
  • 服務探索：為每個環境和服務採用一致的命名慣例。對於 GKE，可考慮使用 headless services 搭配 Cloud DNS，或透過 Internal HTTP(S) Load Balancer 和私有 DNS 名稱來對應服務端點。

• 邊緣快取與保護

  • Cloud CDN 在邊緣卸載可快取的內容，以降低來源伺服器延遲和出口成本。請謹慎設定快取金鑰、TTL 和 negative caching；對於個人化或動態端點，應繞過快取。
  • Cloud Armor 提供 WAF、速率限制以及基於地理位置/IP 的存取控制。將安全政策附加到負載平衡器上；監控規則的命中日誌。使用預先配置的規則來防禦常見的 CVE，並使用自訂簽章來應對應用程式特定的威脅。
  • 在負載平衡器上終止 TLS 可集中管理憑證；盡可能啟用自動憑證佈建和託管續訂功能。

操作指引：

• 版本化 API：實作基於路徑或主機的路由，將流量導向不同的後端服務，以便每個版本都能透過藍綠部署或金絲雀模式獨立推出。
• 透過流量導向政策，使用請求標頭和 cookie 進行 A/B 測試；務必驗證日誌/指標是否與正確的後端身份相互關聯。

混合式連線、私密存取與傳輸

• Cloud Router 與 BGP

  • Cloud Router 透過 BGP 為 Cloud VPN 通道和 Interconnect attachment 與地端環境動態交換路由。當需要多區域輻射點連線時，請在 VPC 中使用全域動態路由模式。
  • 只宣告必要的 prefix；進行過濾以防止路由洩漏。在設計主要/備援路徑時，需了解 MED 與優先順序之間的互動關係。

• Cloud VPN、Dedicated Interconnect 與 Partner Interconnect

  • HA VPN 提供具備 SLA 保證、基於 IPsec 的備援通道，透過 Cloud Router 支援動態路由，適合具有中等頻寬需求的生產環境混合式部署。
  • Dedicated Interconnect 在一個或多個地點提供實體的 10/100 Gbps 鏈路；Partner Interconnect 則是透過服務供應商提供類似服務。為實現高可用性，請在不同的都會區或不同的邊緣可用區使用至少兩個位於不同地點的 interconnect。
  • 備援路徑與容錯移轉：設計橫跨每個區域的兩個 Cloud Router 和兩個地端路由器的 active/active BGP 架構；驗證對非對稱路由的容忍度。定期測試容錯移轉；調整 BFD 計時器和健康狀態閾值，以達到期望的收斂時間。
  • 故障模式：MTU 不匹配會導致封包碎片化和效能下降；確保 Interconnect 的端到端都啟用 jumbo frame。設定錯誤的路由過濾器可能導致子網路流量黑洞。單一歸屬的 partner 線路是常見的單點故障。

• Cloud NAT、Private Google Access 與 Private Service Connect

  • Cloud NAT 讓沒有外部 IP 的私有 VM 能對外存取網際網路。根據連線峰值規劃 NAT IP 和 port 的分配以避免 port 耗盡；啟用日誌以利於故障排除。
  • Private Google Access 允許私有 VM 使用內部 IP 存取 Google API；在子網路上啟用以供 VM 存取，並在 GKE 節點上啟用以供節點本地 API 存取。對於地端用戶端，請使用 Private Service Connect for Google APIs 來暴露作為 Google API 前端的私有 VIP。
  • Private Service Connect 針對生產者/消費者服務提供私有的內部 IP 端點，用於跨專案或跨組織的服務發布；可結合私有 DNS 來引導流量，而無需暴露網路。

• Network Connectivity Center (NCC) 與傳輸

  • NCC 可實現中樞輻射型 (hub-and-spoke) 拓撲，其中輻射點可以是 VPC、HA VPN 或 Interconnect attachment。使用一個中央中樞來簡化路由分發和多 VPC 傳輸，特別是在跨專案或組織時。
  • 在組織內部傳輸時，若治理模型允許，優先選用 Shared VPC；當您需要彈性的多網域傳輸或 SD-WAN 整合時，則使用 NCC。
  • 需了解 VPC Peering 不具備傳輸性 (non-transitive)；不要依賴它來進行傳輸。NCC 或一個集中的防火牆/負載平衡器 VPC 構成傳輸核心。

多區域選擇、延遲與輸出成本：

• 將運算資源部署在靠近使用者和有狀態後端的地方，以最小化 RTT。External HTTP(S) Load Balancing 提供具備智慧路由的全域傳入流量，但資料庫複製延遲和一致性仍然是應用程式層面的限制。
• 在同一區域內的跨可用區流量會產生費用；跨區域複製會增加輸出費用和延遲。使用 Cloud CDN 來減少網際網路輸出量和來源伺服器負載，並將通訊頻繁的服務部署在同一地點。
• 為了災難復原，需權衡在另一區域設置暖備援 (warm standby) 所帶來的輸出成本和維運複雜性。僅在資料平面和控制平面都能容忍區域性隔離的情況下，才使用具備容錯移轉政策和跨區域健康狀態檢查的全域負載平衡。

可觀測性、可靠性維運與管控

• 網路可觀測性

  • VPC Flow Logs：在子網路層級啟用，並調整取樣與中繼資料選項。用於流量基準分析、出向流量分析與威脅獵捕。匯出至 BigQuery 進行長期分析。
  • 防火牆規則日誌：在關鍵規則上啟用，以擷取允許與拒絕的流量；與流量日誌進行關聯分析以偵測設定錯誤。
  • Connectivity Tests：建立來源-目的地路徑的模型，以驗證可達性、路由選擇與防火牆評估。整合至 CI/CD 中，以便在部署前偵測漂移。
  • 健康狀態儀表板：監控負載平衡器後端健康狀態、Cloud NAT 通訊埠使用率、Cloud Router BGP 會話狀態以及 Interconnect 使用率。針對偏差發出警示。

• 可靠性模式與常見的故障模式

  • 可用區韌性：將後端分散到至少兩個可用區；使用受控執行個體群組或多可用區 GKE 節點池。驗證健康狀態檢查與防火牆標籤是否適用於所有可用區。
  • 路由韌性：使用全球動態路由與多個 Cloud Router 來實現跨區域的連線能力。測試黑洞情境，並確保監控涵蓋路由撤回。
  • DNS 韌性：透過 Cloud DNS 預設部署多個名稱伺服器；對於混合雲環境，確保轉送器具備備援能力，並避免地端解析器中的單點故障。防止會從錯誤的一方回傳無法路由之回應的 split-horizon 設定錯誤。
  • 邊緣安全：套用 Cloud Armor 速率限制以保護來源免於洪水攻擊；若未能這麼做，可能觸發自動擴展風暴與成本遽增。

• 成本管控

  • 盡量減少跨區域呼叫，VPC 內部流量優先使用內部負載平衡，並考慮為生產者-消費者流量使用 PSC 以避免 NAT 出向流量。
  • 為靜態與半靜態資產使用 Cloud CDN；調整可快取性。規劃 Interconnect 容量以避免為閒置的餘裕空間支付過多費用；使用流量資料來適當調整承諾用量。

維運程式碼片段：

• 允許負載平衡器的健康狀態檢查連線至私有後端：
  • gcloud compute firewall-rules create allow-lb-hc –network=prod –action=ALLOW –direction=INGRESS –rules=tcp:80,tcp:443 –source-ranges=130.211.0.0/22,35.191.0.0/16 –target-service-accounts=backend-sa@project.iam.gserviceaccount.com
• 在子網路上啟用 Private Google Access：
  • gcloud compute networks subnets update app-subnet –region=us-central1 –enable-private-ip-google-access
• 為 HA VPN 建立一個 Cloud Router：
  • gcloud compute routers create cr-us-central1 –region=us-central1 –network=prod –asn=64514

實務問題情境

Contoso Retail 計劃推出一個全球電子商務 API，要求具備零停機時間的版本控制、與後台系統的嚴格私有連線，且應用程式 VM 上沒有公有 IP。此解決方案必須提供 DDoS 防護、邊緣快取，以及從兩個資料中心進行可靠的混合雲存取。

解決方法：

1. 設計 VPC 與網路分段

• 建立一個自訂模式的 Shared VPC Host Project，並在兩個區域中為每個層級（web、api、data）配置專用的子網路。理由：Shared VPC 可集中化管控，而服務專案則可隔離團隊。每個層級的子網路能實現最小權限的防火牆設定，並縮小故障網域。
• 在組織層級套用階層式防火牆政策，以拒絕來自網際網路的入向 SSH 連線，並限制出向流量只能連到允許的目的地。理由：全域性的防護機制可降低專案中設定錯誤的風險。

2. 實作基於路徑的全域傳入流量與 API 版本控制

• 部署一個具備單一 anycast IP 與 HTTPS 終止的外部 HTTP(S) 負載平衡器。設定 URL 映射，將 /v1/* 與 /v2/* 路由到由區域級可用區 NEG 支援的不同後端服務。理由：獨立的後端服務允許在單一主機名稱與 TLS 下，為每個 API 版本進行獨立的部署與回滾。
• 掛載 Cloud Armor WAF 與速率限制；為可快取的端點（例如產品圖片）啟用 Cloud CDN。理由：保護來源伺服器，並降低延遲與出向流量成本。

3. 確保後端可達性與健康狀態

• 建立一條防火牆規則，允許負載平衡器的健康狀態檢查連線到 api 執行個體群組的預期通訊埠。理由：若無此規則，健康狀態檢查將會失敗，且當執行個體被視為不健康時，自動擴展器可能會發生抖動。
• 將執行個體分散到每個區域的兩個可用區；保守地設定健康狀態檢查的閾值以避免狀態抖動。理由：可用區的多樣性與穩定的健康狀態政策可提高可用性。

4. 建立具備 split-horizon 與服務探索的 DNS

• 為 contoso.com 建立一個公開的 Cloud DNS 區域，並為僅供內部使用的紀錄（例如 db.internal.contoso.com）建立一個同名的私有區域。理由：Split-horizon 可防止內部名稱外洩，同時保持命名的一致性。
• 設定 DNS 政策，將地端的 corp.local 查詢轉送到企業 DNS，並將私有區域匯入應用程式專案。理由：實現跨混合雲邊界的無縫解析，且不會產生遞迴迴圈。

5. 建立具備備援能力的混合雲連線

• 在每個區域中，為每個資料中心佈建兩條 HA VPN 通道，每對通道位於不同的 Cloud Router 上並使用 BGP。如果容量與 SLA 需求證明其合理性，則可新增具備備援附件的 Partner Interconnect，並置於不同的邊緣可用區。理由：多條不同的路徑提供故障轉移；BGP 可實現快速收斂與動態路由交換。
• 在 Shared VPC 中使用全球動態路由，並套用路由篩選器，以防止不想要的地端前綴傳播。理由：在各區域間實現一致的路由，同時降低路由洩漏的風險。

6. 提供對 Google API 的私有存取與對外的網際網路連線

• 在 app 子網路上啟用 Private Google Access，並為批次作業使用的 Google API 設定 Private Service Connect 端點。在需要時，為非 API 的出向流量使用 Cloud NAT。理由：後端不保留任何公有 IP，同時仍能連線到必要的服務；PSC 透過私有 DNS 簡化了名稱解析。

← 資料儲存、資料庫與分析架構 · 所有領域 · 安全性、合規性與資料保護架構 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →