前兩篇整理了單一 VPC 內的流量路徑：哪些資源需要接受連線，以及 Private Subnet 如何透過 NAT Gateway 或 VPC Endpoint 存取其他服務。
但系統規模增加後，Application 與 Service 很可能開始分散到不同 VPC，例如：
這些都屬於跨 VPC 存取，但需要開放的範圍不同。
有些需求需要連接兩個 Network，有些則只需要提供一項 Service。
今天就從這個差異，看看 VPC Peering、Transit Gateway 與 AWS PrivateLink 分別適合什麼情境。
可以先把需求分成三類：
| 情境 | 需要的連線範圍 | 可以優先評估 |
|---|---|---|
| 兩個 VPC 需要互相存取多項 Resource | Network-to-Network | VPC Peering |
| 多個 VPC 需要集中管理 Routing | Network-to-Network | Transit Gateway |
| 只提供一項 Internal API / Service | Consumer-to-Service | AWS PrivateLink |
因此，選型前可以先確認：
這次到底需要開放多少 Network Reachability？
假設 Production VPC：
10.20.0.0/16
需要存取 Shared Services VPC：
10.30.0.0/16
可以建立 VPC Peering：
Production VPC
10.20.0.0/16
│
│ VPC Peering
▼
Shared Services VPC
10.30.0.0/16
VPC Peering 可以把兩個 VPC 直接連起來，讓 Resource 透過 Private IP 通訊，可以先把它理解成：
VPC Peering = Point-to-Point Connectivity
不過，建立 Peering Connection 不代表 Resource 馬上可以互通。
雙方 Route Table 還需要知道對方網段該走哪裡，例如：
Production Route Table
10.30.0.0/16
→ VPC Peering
Shared Services 端也需要對應的 Return Route。
VPC Peering 另外有幾個重要限制：
例如：
A ↔ B
B ↔ C
不代表：
A ↔ C
如果 A 和 C 也需要直接互通，就要另外建立 Peering。
因此，Peering 很適合少量、關係固定的 VPC，但當 Network Topology 越來越複雜，管理的 Connection 與 Route 也會隨之增加。
假設公司逐漸出現：
Development
Production
Shared Services
Security
如果這些 Network 之間有大量互通需求，逐對建立 Peering 會開始增加管理負擔。
這時可以評估 AWS Transit Gateway（TGW）。
架構會從 Point-to-Point(以下為示意圖範例)：
變成 Hub-and-Spoke(以下為示意圖範例)：
每個 VPC 透過 Attachment（連接） 接到 Transit Gateway，再由 Routing 決定 Traffic 要送往哪個 Network。
這時需要理解兩層 Route Table：
VPC Route Table
→ 決定封包要不要送進 TGW
TGW Route Table
→ 決定封包進入 TGW 後，要從哪個 Attachment 出去
例如：
Production VPC Route Table
10.30.0.0/16
→ Transit Gateway
TGW 收到封包後，再依自己的 Route Table 找到 Shared Services 對應的 Attachment。
TGW Route Table 還會看到兩個常見概念：
透過不同的 TGW Route Table，可以進一步做到 Network Segmentation（網路隔離）。
例如：
Development → Shared Services ✓
Production → Shared Services ✓
Development ↔ Production ✕
也就是 Development 與 Production 都能使用共用服務，但彼此不需要直接互通。
因此 Transit Gateway 的價值不只是「少建幾條 Peering」，更重要的是：
把多個 VPC 的 Routing 與網路隔離集中管理。
所以是否需要 TGW，不能單純只看 VPC 數量，更要看：
VPC 數量
+
Connectivity Topology
+
網路隔離需求
+
未來擴充方式
前面兩種方式都在處理 Network-to-Network Connectivity。
但假設今天的需求只是：
讓合作廠商呼叫公司的 Order API。
Consumer 不需要：
那就不一定需要把兩個 Network 接起來。
這時可以評估 AWS PrivateLink。
本篇先使用常見的 NLB-backed Endpoint Service 說明：
Provider 透過 Network Load Balancer 建立 Endpoint Service，Consumer 則在自己的 VPC 中建立 Interface Endpoint 連接該服務。
PrivateLink 最重要的差異是：
Peering / TGW
→ 連 Network
PrivateLink
→ 連 Service
Consumer 得到的是 Service Endpoint，而不是 Provider VPC 的整體 Network Reachability。
也因為不是直接在兩個 VPC 之間交換一般 Routing，PrivateLink 可以用在 Provider 與 Consumer CIDR 重疊的情境。
不過，PrivateLink 解決的是 Private Connectivity，API 本身仍然需要自己的 Authentication 與 Authorization。
可以整理成：
| 項目 | VPC Peering | Transit Gateway | AWS PrivateLink |
|---|---|---|---|
| 主要用途 | 兩個 VPC 直接互通 | 多個 Network 集中 Routing | 提供指定 Service |
| 架構 | Point-to-Point | Hub-and-Spoke | Provider / Consumer |
| 連線範圍 | Network | Network | Service |
| Transitive Routing | 不支援 | 支援 | 不以 Routing 為目的 |
| CIDR 重疊 | 不支援 | 一般 Routing 仍需處理衝突 | 可處理 Provider / Consumer 重疊情境 |
| 適合情境 | 少量 VPC、多項 Resource 互通 | 多 VPC、集中 Routing / Segmentation | API、內部服務分享 |
選型思路可以簡化成：
實際 Architecture 也可能同時使用 TGW 與 PrivateLink。
例如公司內部的 Development、Production 與 Shared Services 透過 TGW 集中管理，而對外部合作廠商只透過 PrivateLink 提供一個 Order API。
它們不是互相取代，而是在解決不同範圍的 Connectivity Requirement。
今天處理的是 AWS 內部不同 VPC 之間的 Connectivity。
但企業環境中的 Network 不一定都在 AWS，公司辦公室、Data Center 或其他 On-premises Network，也可能需要存取 AWS 中的 Private Resource。
下一篇會把 Network Boundary 再往外延伸，看看 AWS Site-to-Site VPN 與 Direct Connect 如何把企業內部網路連到 AWS，以及兩種方式在連線路徑、導入成本與使用情境上的差異。
iThome鐵人賽
看影片追技術