AWS VPC 入門（下）：多 VPC、多帳號與混合雲架構演進

2026-11-07

單一 VPC 只要靠一條預設的 local 路由，就能讓所有子網路彼此互通。但當業務成長、架構擴充，網路跨出單一 VPC 的邊界時，維運團隊馬上會面臨三個全新的挑戰：

連線：封包如何在多個 VPC 或地端機房之間安全傳遞？
名稱：跨網路的主機，如何解析彼此的私有網域名稱？
治理：幾十個 AWS 帳號並存時，誰負責分配 CIDR，由內對外的流量又該如何集中管理與檢查？

在 L3 網路層連線多個 VPC 與地端時，底層依然依賴三個不變原則：路由依 Route Table 的最長字首決定（多筆路由皆可抵達時，以網段最精確者優先）、打通的網路間 CIDR 嚴禁重疊，以及跨網路元件各有自己的計費方式；若遇到網段衝突或跨組織協同，則需改用 L4 服務層（只針對單一服務開放）的方案。

本文接續上篇基礎，梳理雲端網路跨出單一 VPC 後的跨網架構與演進路徑。

NOTE

延伸閱讀：AWS VPC 入門（上）：單一 VPC 路由、防火牆與帳單

VPC Peering：一對一私有互連

VPC Peering 是在兩個 VPC 之間建立的一對一私有通道，支援跨帳號與跨區域。建立後只要在雙方路由表加入指向對方 CIDR 的路由，並放行安全群組即可通訊。

 +-----------+      VPC Peering      +-----------+
 |   VPC A   | <-------------------> |   VPC B   |
 | 10.0.0.0  |   (Non-transitive)    | 10.1.0.0  |
 +-----------+                       +-----------+

Peering 雖然設定直接，但在官方架構限制中有三個重要限制：

CIDR 嚴禁重疊：即使只打算使用兩端各自未重疊的子網路，只要 VPC 整體 CIDR 有任何重疊，連線就完全無法建立。
不具遞移性（Non-transitive）：A 與 B 相連、A 與 C 相連，B 與 C 之間絕不會自動互通，A 無法作為轉發封包的中繼站。
無法借用邊界閘道（No Edge-to-Edge Routing）：B 無法借用 A 的 Internet Gateway、NAT Gateway、VPN 或 Direct Connect 走入其他網路。

不具遞移性意味著全網狀連線（Full Mesh）的連線數會隨 VPC 數量爆炸。 $N$ 個 VPC 彼此全通需要 ${N \times (N-1) / 2}$ 條 Peering。5 個 VPC 需要 10 條，20 個 VPC 則高達 190 條。

不過，Peering 沒有每小時固定費用，同可用區（AZ）傳輸免費，跨 AZ 也僅收取標準跨 AZ 傳輸費（每 GB $0.01）。因此在 VPC 數量極少，或特定兩端有超大流量時，Peering 依然是划算的選擇。

Transit Gateway：從網狀拓撲邁向星狀中樞

當 VPC 數量增長至雙位數，全網狀 Peering 的維護負擔將變得難以承受。AWS Transit Gateway（TGW）扮演了區域級的雲端虛擬路由器，將拓撲收斂為星狀（Hub-and-Spoke）。

 +-----------+       +---------------+       +-----------+
 |   VPC A   |-------|               |-------|   VPC B   |
 +-----------+       |    Transit    |       +-----------+
                     |    Gateway    |
 +-----------+       |   (Router)    |       +-----------+
 |   VPC C   |-------|               |-------|  On-Prem  |
 +-----------+       +---------------+       +-----------+

每個 VPC、VPN 或 Direct Connect 只需要向 TGW 建立一條連線（Attachment）。TGW 具備遞移性，地端連上 TGW 後便能自然抵達所有掛載的 VPC。

TGW 路由架構與網路分段

TGW 的路由管理分為兩個層次：

VPC 路由表：將目的端網段指向 tgw-xxxx，讓封包出 VPC。
TGW 路由表：透過 Association（關聯） 與 Propagation（傳播） 控制封包轉發。

一個 Attachment 只能關聯（Associate）一張 TGW 路由表——封包要轉發時就查這張表；但可以把自身網段傳播（Propagate）到多張 TGW 路由表，讓其他環境知道怎麼把封包送進來。透過設定三張路由表即可實現完整的環境隔離與雙向互通：

rt-prod：關聯正式環境 VPC，僅接收 prod 與共用服務 VPC 的路由傳播。
rt-dev：關聯開發環境 VPC，僅接收 dev 與共用服務 VPC 的路由傳播。
rt-shared：關聯共用服務 VPC，同時接收 prod 與 dev 的路由傳播以建立回程路由。

這讓 prod 與 dev 均能存取共用服務並正常收到回應，但 prod 與 dev 之間彼此完全隔離，省去在每個 VPC 裡維護複雜安全群組的負擔。

成本考量與混合架構

依據 Transit Gateway 定價，每個 Attachment 需支付小時費（每小時 $0.05，約每月 $36.5），且每 GB 流量需額外收取 $0.02 資料處理費。20 個 VPC 光是 Attachment 每月固定開銷就超過 $700，但能將 190 條 Peering 簡化為 20 條。

在企業實務中，最常見的折衷架構是以 TGW 作為預設骨幹，但在少數高流量 VPC 之間疊加 VPC Peering。

只要在 VPC 路由表將預設骨幹設為較大範圍的彙總路由（如 10.0.0.0/8 $\rightarrow$ TGW），再針對特定大流量 VPC 加入具體的網段路由（如 10.2.0.0/16 $\rightarrow$ Peering），最長字首匹配原則就會自動讓大流量改走不需支付 TGW 資料處理費的直連 Peering，兼顧治理與成本。

PrivateLink：以服務為邊界的單向安全開放

Peering 與 TGW 都是在 L3 網路層將兩個網路打通，連線後雙方所有主機在路由層面皆可達，僅依賴安全群組防護。但若只需對合作夥伴、客戶或特定內部團隊開放單一應用程式，便適合改用 AWS PrivateLink。

PrivateLink 將服務端置於 Network Load Balancer（NLB）後方建立 Endpoint Service；消費端則在自己的 VPC 內建立 Interface Endpoint，產生一張帶有本地私有 IP 的彈性網路介面（ENI），可以想成掛在 VPC 內的一張虛擬網路卡。

 [ Consumer VPC: Local App (192.168.1.5) ]
         |
         v  (AWS Internal Network)
 [ Interface ENI ] --> [ NLB ] --> [ Provider VPC: App ]

PrivateLink 具備三項關鍵特性：

單向連線：僅允許消費端主動發起連線，服務端無法反向刺探消費端網路。
允許 CIDR 重疊：消費端只連線自己 VPC 內的本地 ENI IP，封包在 AWS 底層轉發，兩端網段即使完全相同也完全不衝突。
最小權限開放：不打通整段子網路，僅開放該 NLB 後端的特定連接埠。

跨 VPC 連線模式比較

比較面向	VPC Peering	Transit Gateway	AWS PrivateLink
通訊層級	L3 網路層（打通全網）	L3 網路層（打通全網）	L4 服務層（僅開放單一服務）
連線方向	雙向主動連線	雙向主動連線	單向（僅消費端可發起）
CIDR 衝突	嚴禁重疊	嚴禁重疊	完全允許重疊
拓撲模式	點對點（無遞移性）	星狀中樞（具遞移性）	點對服務端點
費用特性	無小時費，同 AZ 免費	需支付 Attachment 小時費與處理費	需支付 Endpoint 小時費與處理費

混合雲連線：VPN 與 Direct Connect 的取捨與備援

串接企業地端機房與 AWS 雲端主要有兩種管道：走公網加密的 Site-to-Site VPN 與實體專線 Direct Connect（DX）。

 [ On-Premises DC ]
     |
     +--> Site-to-Site VPN (IPsec / Internet)
     |
     +--> Direct Connect (Dedicated Fiber)
     |
     v
 [ Transit Gateway ]

核心特性對比

比較面向	Site-to-Site VPN	Direct Connect (DX)
連線介質	網際網路（IPsec 加密）	專屬實體線路（不經公網）
開通時間	數分鐘內完成	數週至數月（需拉實體線）
延遲與穩定度	隨網際網路狀況波動	穩定、可預期
預設加密	內建 IPsec	預設無加密（部分連線支援 MACsec，或疊加 VPN）
成本特性	固定小時費極低，適合中小流量	連接埠小時費高，但資料傳出費率較優惠

主備架構與路由優先權陷阱

企業關鍵系統通常採用 Direct Connect 作為主線，VPN 作為備援。當 DX 與 VPN 都以 BGP（自動交換路由資訊的動態路由協定）宣告相同網段時，依據 AWS TGW 的路由評估順序，Direct Connect Gateway 傳播的路由優先於 VPN 傳播路由。Direct Connect Gateway 是串接專線與多個 VPC 的閘道元件。

這讓 DX 正常時流量走專線，中斷時自動切換至 VPN。

此處最常見的維運陷阱在於：TGW 路由表中，靜態路由的優先權高於任何 BGP 傳播路由。若在建置備援 VPN 時誤設定為靜態路由，該靜態路由將會強行壓過 DX 的動態路由，導致平時主要流量全數被錯誤導向 VPN。因此備援 VPN 務必同樣設定 BGP。

混合 DNS：Route 53 Resolver 解析跨網名稱

打通跨網路由後，緊接著就是名稱解析問題。VPC 內建的 Route 53 Resolver 預設無法回應地端查詢，VPC 內的主機也無法解析地端的內部網域。

DHCP Option Set 是指定 VPC 內主機使用哪台 DNS 的設定。若直接修改它指向地端 DNS，實例就會繞過 VPC 內建的預設解析器（AmazonProvidedDNS，即各子網 .2 位址上的解析服務），導致私有託管區域（Private Hosted Zone）與 PrivateLink 的內部名稱解析全面失效。

正確作法是部署 Route 53 Resolver Endpoints：

 [ VPC Workloads ]
       |
       +-- [ Inbound Endpoint ]
       |       ^
       |       |  （查詢 aws.internal）
       |       |
       |  [ On-Prem DNS ]
       |
       +-- [ Outbound Endpoint ]
               |
               |  （轉發 corp.local）
               v
           [ On-Prem DNS ]

Inbound Endpoint：在 VPC 內建立具備私有 IP 的 ENI，地端 DNS 透過條件式轉發（Conditional Forwarding）將雲端私有網域名稱（如 *.aws.internal）送交此 IP 解析。
Outbound Endpoint：搭配轉發規則（Forwarding Rules），當 VPC 內應用程式查詢企業內部網域（如 *.corp.example.com）時，自動轉發至地端 DNS 伺服器。

Resolver 轉發規則可透過 AWS RAM（Resource Access Manager，AWS 的跨帳號資源共享服務）跨帳號共用，只需在核心網路帳號集中建置一組 Endpoint，就能服務全企業。

多帳號治理：Shared VPC 與 IPAM

隨著組織規模擴大，單一 AWS 帳號無法滿足權限隔離需求。然而每個帳號各自建立 VPC，往往會引發網段衝突與設定分散等治理難題。

Shared VPC：集中網段控管與資源切分

VPC Sharing 允許中央網路團隊在「擁有者帳號」建立 VPC 與子網路，再透過 AWS RAM 將子網路分享給「參與者帳號」。

責任分工：業務團隊在受分享的子網路內啟動 EC2、RDS 或 Lambda，無權修改子網路 CIDR、路由表或 NACL（網路存取控制清單，子網路層級的防火牆規則）；網路團隊則專注維持拓撲安全。
成本效益：減少全組織的 VPC 總數與 TGW Attachment 數量。參與者支付自身資源與資料傳輸費，網路帳號統一負擔 NAT 與閘道固定費用。

VPC IPAM：自動化網段規劃

IP Address Manager（IPAM）將網段規劃制度化。透過在 Organization 頂層建立階層式位址池（如 10.0.0.0/8 $\rightarrow$ 區域池 $\rightarrow$ 環境池），各帳號在建立 VPC 時自動由所屬池分配 CIDR，從根本上杜絕網段重複設定。

集中出口架構與安全檢驗

當環境中存在數十個 VPC 時，若每個 VPC 的每個 AZ 各自設定 NAT Gateway，光是閒置小時費就極為可觀。集中式出口（Centralized Egress）將 NAT Gateway 與 Internet Gateway 統一部署在獨立的 Egress VPC。

 [ Spoke VPC 1 ] --+
                   |
 [ Spoke VPC 2 ] --+--> [ Transit Gateway ]
                   |
 [ Spoke VPC 3 ] --+               |
                                   v
                        [ Egress VPC (NAT GW) ] --> Internet

所有 Spoke VPC 的預設路由（0.0.0.0/0）皆導向 TGW，再由 TGW 轉送至 Egress VPC 集中對外傳輸。這種做法不僅大幅削減 NAT 小時費，還能把企業對外的公網出口集中到少數幾個 IP（便於夥伴設定白名單與內部稽核），並能更輕鬆地整合 AWS Network Firewall 進行集中流量過濾與深層封包檢測。

自 2025 年起，Network Firewall 更支援直接掛載為 TGW Attachment，省去過去必須先把流量繞進專責檢查用的 Inspection VPC、再轉送往目的地的繁瑣路由設定，進一步簡化了企業安全架構。

實務架構演進：升級臨界點與決策指標

以一家成長中的公司為例，雲端網路往往隨業務規模經歷五個演進階段，每個階段都有明確的切換臨界點：

 Stage 1: 雙 VPC 直連 (VPC Peering)
    | (VPC 數量增長，全網狀管理成本激增)
 Stage 2: 多環境星狀互通 (Transit Gateway + 路由分段)
    | (帳號數量拆分，面臨網段衝突與分散失控)
 Stage 3: 多帳號組織化 (Shared VPC + IPAM + PrivateLink)
    | (業務需要與地端機房核心系統整合)
 Stage 4: 混合雲整合 (Direct Connect + VPN 備援
          + Resolver Endpoints)
    | (多 VPC 的 NAT 閒置費攀升，且面臨嚴格資安合規)
 Stage 5: 企業級集中治理 (Egress VPC + AWS Network Firewall)

從 Peering 升級至 TGW 的時機：當 VPC 數量達到 5 至 10 個、路由表手動維護成為負擔，或需要讓多個 VPC 共用同一條地端專線時。
導入 Shared VPC 與 IPAM 的時機：當各團隊在獨立帳號隨意切割 CIDR 造成網段耗盡或衝突，且各帳號網路設定品質參差不齊時。
選用 PrivateLink 的時機：當需要對外部夥伴、客戶或 SaaS 系統提供單一服務，且雙方 CIDR 存在衝突或無法互相信任整個網路時。
地端專線與 DNS 整合時機：業務需要穩定、低延遲且大頻寬的專線（DX）時，以 BGP 設定 VPN 作為容錯備援；並透過 Resolver Endpoints 在不破壞雲端原生解析的前提下，打通雙向的內部網域解析。
集中出口與防火牆導入時機：當全組織數十個 VPC 的 NAT 閘道閒置小時費過高，或面臨資安合規要求統一對輸出流量實施深層封包檢測（DPI）時。

結語

從單一 VPC 到混合雲與多帳號架構，元件數量雖然大幅增加，但核心原則始終未變：路由永遠由最長字首決定、網段規劃必須嚴防重疊、跨網連線得先透過名稱解析這一關、流量走哪條路徑就照哪條路徑計費。

理解各個元件要解決的痛點與本質限制，在架構規模擴充時依序升級，就能建構出兼具安全性、彈性與成本效益的現代雲端網路。