在 AWS 的虛擬私有雲（VPC）中，資料的傳遞就像車輛在城市中行駛，需要清楚的指引與通道。這些指引就是「路由表Route Table」，而這些通道就是「閘道器Gateway」。

路由表（Route Table）－資料的 GPS 導航

什麼是路由表？

路由表是 AWS VPC 的核心元件，用來定義「不同 IP 流量應該走哪一條路」。
每個子網（Subnet）至少會綁定一個路由表。
路由表中的每一條規則（route）都是「目標位址 + 下一跳（target）」。

常見路由規則範例：

閘道器（Gateway）－資料出入的門口

AWS 中有多種 Gateway，它們負責資料的實際「出入口」，以下是詳細介紹：

1. Internet Gateway（IGW）

功能：讓公有子網（Public Subnet）內的資源可以直接連到網際網路。
搭配：EC2 + 公有 IP + 路由表指向 IGW。
使用場景： 架設 Web 伺服器、API Gateway、公網服務等。

2. NAT Gateway

功能：讓私有子網（Private Subnet）的資源可以「對外發出請求」，但外部無法主動進入。
搭配：私網 EC2、路由表指向 NAT Gateway。
使用場景： 安全更新作業系統、下載套件。
私網 EC2 存取第三方 API（如 GitHub、Docker Hub）。

3. S3 Gateway Endpoint

功能：讓 VPC 內的資源可以透過 AWS 內部網路存取 S3，不經過 NAT 或 IGW。
安全性高、流量成本低。
使用場景： EC2 上傳或下載 S3 檔案。
Lambda、ECS、EMR 存取 S3 資料湖。

4. 其他常見 Gateway

架構小補充:

vpc 與 vpc 串接在實際應用中是滿常見的場景，比較大的系統需要跟其他系統做對接，通常會是在另外一個VPC，或者是另外一個 AWS Account，又因為資安的考量，不希望流量透過internet的方式進行溝通，就會採用perring 或是 tgw 的方式進行對接。會在之後的文章更細節的講解。

一、VPC Peering

適用情境 VPC 數量少，拓樸簡單 (點對點連線)
需要低延遲、無需複雜路由轉送
常見於同區域 (Intra-Region) 或跨區域 (Inter-Region) 的少量 VPC 互連
特性 無單點故障 (直接 VPC 對 VPC)
不支援轉送 (transitive routing) → 無法透過 A ↔ B ↔ C 的方式讓流量互通
建立與維護成本低，但隨 VPC 數量增加，管理難度提升 (Peering Mesh 問題)
限制 不支援重疊的 CIDR
流量僅限於 Peering 雙方，需在 Route Table 中手動設定

二、Transit Gateway (TGW)

適用情境 需要集中管理多個 VPC 互聯
涉及跨區域、大規模網路拓樸
需要整合與 On-Premises (透過 VPN 或 Direct Connect)
特性 Hub-and-Spoke 架構，降低 Mesh 管理複雜度
支援 Transitive Routing，可讓不同 VPC 或 VPN 互通
可跨帳號共享 (透過 AWS RAM)
適合大型、企業級網路架構
限制 成本較高 (依流量與附件數計費)
相對 VPC Peering，延遲略高

三、設計考量補充

小規模 VPC 整合 → VPC Peering 例如：只有 2–3 個 VPC 需要互通，且不涉及跨帳號或跨區域的複雜場景。
大規模、多區域或需要混合雲 → TGW 例如：企業有 10+ VPC，還需要與 On-Premises VPN/Direct Connect 整合，建議採用 TGW。
混合架構 初期先使用 VPC Peering，待網路拓樸變複雜後再逐步過渡到 TGW。

結論：

若環境單純、VPC 數量少 → 使用 VPC Peering。
若規模龐大、需集中管理或與 On-Premises 整合 → 使用 Transit Gateway。