Transit Gateway — 路由表、Attachments 與 Connect

Transit Gateway (TGW) 在 ANS-C01 考試中是多 VPC 網路架構的核心。雖然 SAA-C03 考試合將 TGW 視為「連接 VPC 的東西」，但 Advanced Networking Specialty (進階網路專家) 考試則會問：「給定一個具備三個 VPC 連接、兩個 VPN 連接、一個 DX Transit VIF 連接，以及一個到另一個區域 TGW 對等互連連接的 TGW——請設計路由表以執行 prod/non-prod 隔離，確保狀態檢查是對稱的，並透過共用的 NAT VPC 提供集中式出口，同時透過 Resource Access Manager 在 12 個 AWS 帳號中共用 TGW」。這是一個涉及多個連接、多個路由表和多個帳號的設計問題，是 ANS-C01 的核心考點。

本主題涵蓋了 Transit Gateway 的完整原始元件：連接 (attachments) (VPC、VPN、Direct Connect、對等互連、Connect)、具備關聯 (associations) 與傳播 (propagations) 功能的路由表、用於檢查 VPC 對稱流量的設備模式 (appliance mode)、用於 SD-WAN 整合並具備 GRE+BGP 的 TGW Connect、多點傳送 (multicast) 網域、跨區域對等互連 (僅限靜態，無 BGP)、用於跨帳號共用的 AWS Resource Access Manager，以及規範性的集中式出口和檢查 VPC 模式。對應至任務說明 2.2 (跨多個 AWS 帳號、區域和 VPC 實作路由與連線性)。

為什麼 Transit Gateway 是領域 2 多 VPC 架構的重心

領域 2 (佔考試 26%) 和領域 1 的任務 1.6 都高度依賴 TGW。現代 AWS 多 VPC 架構是是以 TGW 為中心的星狀拓撲 (hub-and-spoke)，ANS-C01 期望你能設計每個面向：哪些分支 (spoke) 應放入哪個 TGW 路由表、何時啟用設備模式、何時使用 TGW Connect 與 Site-to-Site VPN 進行 SD-WAN 整合、何時對等互連優於 TGW (出於成本考量)，以及如何跨區域擴展。預計會有 5-7 題關於 TGW 設定的情境題。

本主題的框架是透過路由表進行分段 (segmentation)。一個 TGW 具備一個或多個路由表；每個連接都精確地與一個 TGW 路由表關聯 (控制其查閱表)，並將其自身的路由傳播到一個或多個 TGW 路由表 (控制其他連接對它的可見性)。透過建立多個路由表 (prod、non-prod、shared、inspection) 並仔細選擇關聯與傳播，你可以在不依賴子網路層級安全性的情況下，執行誰可以存取誰的政策。設定錯誤的傳播是設計中最常見的 bug——考試會直接對此進行測試。

白話文解釋 Transit Gateway

TGW 是一種傳輸架構，將幾個原始元件 (連接、路由表、關聯、傳播、設備模式) 結合成微妙的多 VPC 拓撲。三個類比可以幫助理解這些移動零件。

類比一 — 具備大廳與登機口的樞紐機場

將 Transit Gateway 想像成一個樞紐機場。每個 VPC、VPN 或 DX 連線都是該機場的一個登機口。連接 (Attachments) 是停在登機口的飛機。機場有多個大廳 (TGW 路由表)：生產大廳、非生產大廳、共用服務大廳、檢查大廳。每個登機口都精確地與一個大廳關聯——這決定了該登機口的乘客所看到的航站地圖。每個登機口會將其目的地城市傳播到一個或多個大廳的航站地圖上——這決定了哪些乘客可以找到這個登機口作為目的地。設備模式 (Appliance mode) 是規定：「在兩個大廳之間轉機的乘客必須始終經過同一個安檢站，無論是去程還是回程」——如果沒有這個規定，乘客可能在向東走時通過了安檢，但在向西走時繞過了安檢。TGW 對等互連是另一個區域的姐妹機場——航班可以在它們之間飛行，但只能依照預先公佈的直飛航線 (靜態)，而不是透過動態調度 (無 BGP)。AWS RAM 則是航空公司聯盟，讓你的姐妹航空公司可以使用你的登機口而無需擁有整個機場。

類比二 — 郵件分揀配送中心

TGW 是一個連接數十個郵局 (VPC) 和外部郵件承運商 (VPN、DX) 的區域郵件分揀中心。連接是將郵件送入中心的傳送帶。路由表是分揀箱，每個箱子都貼有目的地標籤。每條傳送帶都與一個分揀箱關聯——當郵件從傳送帶上下來時，會根據該箱子的標籤進行分揀。每條傳送帶會將其自身的目的地標籤傳播到一個或多個分揀箱中——以便其他傳送帶的郵件可以路由到它。設備模式是規定：「需要檢查的郵件必須始終在進出時由同一個建築物中的同一個 X 光掃描機檢查」——防止透過非對稱路由繞過檢查。多點傳送網域則是中心處理的廣播新聞訂閱名單——進來一個包裹，許多訂閱者都會收到副本。

類比三 — 擁有多條線路的城市地鐵系統

TGW 是多條線路匯集的地鐵樞紐站。連接是不同的線路 (紅線、藍線、綠線、快線)。路由表是月台上顯示的線路圖。每條線路都精確地與一個月台地圖關聯。每條線路會將其終點站傳播到一個或多個月台地圖上。在樞紐站搭乘紅線的乘客查閱紅線月台地圖上的「X 站」；如果 X 站位在另一條線路傳播的站點中，乘客就進行轉乘並繼續前進。設備模式是規定：「如果你轉乘到『檢查線』，你必須在去程和回程都經過同一條『檢查線』」——這樣檢查員才能在出發和返回時都看到你。黑洞路由則是月台地圖中「此站永久關閉——禁止路由」的條目，防止回退到較不精確的路由。

Transit Gateway 架構 — 核心原始元件

Transit Gateway 是一個區域性的多 AZ 網路閘道服務，讓你透過單一託管的傳輸架構連接 VPC、VPN 連線、Direct Connect 連線和其他 TGW。AWS 預設限制一個 TGW 最多擁有 5000 個連接和 20 個具備關聯+傳播功能的路由表。

連接 (Attachments) — 連線類型

TGW 支援五種連接類型：

• VPC 連接 — 將 VPC 連接到 TGW。需要在選定子網路中每個 AZ 建立一個 ENI。
• VPN 連接 — 終止 Site-to-Site VPN。每個 VPN 兩個 IPsec 隧道，支援 BGP 或靜態路由。
• Direct Connect 連接 — 透過關聯至 Direct Connect Gateway 的 Transit VIF 進行連線。
• TGW 對等互連連接 — 連接相同或不同區域的兩個 TGW；僅限靜態路由。
• TGW Connect 連接 — 在現有的 VPC 或 DX 連接之上建立 GRE+BGP 疊加連接，用於 SD-WAN。

每個連接都有自己的 ID，可以加上標籤，可以與一個 TGW 路由表關聯，並可以將路由傳播到一個或多個 TGW 路由表。

路由表 — 分段

一個 TGW 可以有多個路由表。每個路由表保存著路由 (目的地 CIDR + 目標連接)，這些路由可以透過傳播 (從傳播到該路由表的連接自動填入) 或靜態 (手動新增，在相同前綴長度下優先於傳播) 來產生。

關聯 (Association) — 連接使用哪個路由表進行查閱

一個連接在同一時間精確地與一個 TGW 路由表關聯。當封包從此連接到達 TGW 時，TGW 會查閱關聯的路由表以尋找目的地連接。

傳播 (Propagation) — 連接的路由出現在哪些路由表中

一個連接會將其路由 (它通報的前綴) 傳播到一個或多個 TGW 路由表。VPC 連接傳播其 CIDR；VPN/DX 連接傳播 BGP 通報的前綴；對等互連連接若你在路由表中手動新增靜態路由，則會傳播這些路由。

解耦特性

將關聯 (我在哪裡查閱路由) 與傳播 (我的路由在哪裡顯示) 解耦是 TGW 設計的核心槓桿。透過仔細選擇關聯與傳播，你可以實作分段：生產 VPC 關聯到 prod RT 並傳播到 prod + shared，非生產 VPC 關聯到 non-prod RT 並傳播到 non-prod + shared，檢查 VPC 則關聯到所有 RT 並傳播到所有地方。

VPC 連接 — 子網路、AZ 選擇與 ENI

VPC 連接將 VPC 連接到 TGW。TGW 在客戶選擇的每個子網路中建立一個 ENI (通常每個 AZ 一個子網路以實現高可用性)。這些 ENI 是 VPC 與 TGW 骨幹之間的資料路徑。

子網路選擇

你在每個 AZ 中選擇一個子網路供 TGW 佈建其 ENI。所選子網路應為 TGW 專用子網路 (小型子網路，不放置其他工作負載)，並將 0.0.0.0/0 路由到 TGW 以供 spoke 流量使用。生產級設計建議每個 AZ 使用 /28 子網路專門用於 TGW ENI。

AZ 可用性

TGW VPC 連接在所選 AZ 之間具備高可用性——如果一個 AZ 故障，流量會流經存活 AZ 的 ENI。然而，對於目的地為 spoke 中特定 AZ (例如 AZ-a 中的資料庫) 的流量，AZ-a 中的 TGW ENI 必須可用，流量才能在不經過跨 AZ 跳轉的情況下到達該 AZ。請務必選擇 spoke 使用的所有 AZ。

多帳號 VPC 連接

VPC 連接要求 VPC 與 TGW 位於同一個帳號，或透過 AWS RAM 共用。當 TGW 共用時，spoke 帳號在其端建立連接；中央網路帳號接受 (或自動接受) 該連接。

Spoke VPC 路由表

Spoke VPC 的子網路路由表包含：local + <其他 spoke CIDR 或 0.0.0.0/0> → tgw-xxxx。最簡單的 spoke 路由是 0.0.0.0/0 → tgw-xxxx，將所有非本地流量發送到 TGW 進行路由決策。

設備模式 — 狀態檢查必備功能

設備模式 (Appliance mode) 是每個 VPC 連接的設定，強制 TGW 將流程的雙向流量保持在同一個 AZ 的同一個 TGW 連接 ENI 上。這對於部署在檢查 VPC 中的狀態防火牆 (Network Firewall、Palo Alto VM-Series、Check Point、Fortinet) 至關重要。

為什麼需要設備模式

如果沒有設備模式，TGW 會針對每個 AZ 做出各別的流量路由決策。從 AZ-1 中的 spoke A 到 spoke B 的流量可能透過 AZ-1 的 TGW ENI 進入檢查 VPC，由 AZ-1 的防火牆執行個體檢查，然後透過 AZ-1 ENI 離開前往 spoke B。來自 spoke B 的回程封包可能透過 AZ-2 的 TGW ENI 進入 (因為 TGW 為回程路徑選擇了 AZ-2)，被 AZ-2 的防火牆檢查——但該防火牆沒有原始 SYN 的記錄——並將其作為未經請求的封包丟棄。

啟用設備模式會將整個流程的 TGW 路徑固定到一個 AZ ENI。該 AZ 的防火牆會看到雙向流量，狀態追蹤就能正常運作。

設定設備模式

在建立 VPC 連接時設定，或稍後透過 modify-transit-gateway-vpc-attachment API 修改。此設定僅套用於檢查 VPC 的連接；spoke 連接不需要。AWS 建議為任何託管狀態網路功能的 VPC 啟用設備模式。

設備模式與跨 AZ 流量

設備模式不影響 spoke 選擇從哪個 AZ 發送。流程從源 spoke 經過檢查 VPC 到達目的 spoke 都保持在同一個 AZ。設備模式本身不會增加跨 AZ 資料傳輸費用——跨 AZ 行為取決於 spoke 執行個體和目的地執行個體所在的 AZ。

TGW 路由表模式 — 透過關聯與傳播實現分段

最常見的 TGW 設計模式是多段隔離——防止生產 (prod) 和非生產 (non-prod) VPC 互相存取，同時兩者都能存取共用服務。

三段模式 (Three-segment pattern)

建立三個 TGW 路由表：prod-rt、non-prod-rt、shared-rt。

• 生產 (Prod) VPC 連接：與 prod-rt 關聯，傳播到 prod-rt 和 shared-rt。
• 非生產 (Non-prod) VPC 連接：與 non-prod-rt 關聯，傳播到 non-prod-rt 和 shared-rt。
• 共用服務 (Shared services) VPC 連接：與 shared-rt 關聯，傳播到 prod-rt、non-prod-rt 和 shared-rt。

結果：prod 可以存取 prod 和 shared；non-prod 可以存取 non-prod 和 shared；shared 可以存取所有人；prod 無法存取 non-prod，因為 non-prod 的 CIDR 沒有傳播到 prod-rt。

加入檢查機制

要強制所有流量經過檢查 VPC，請更改 spoke 關聯：prod VPC 和 non-prod VPC 都關聯到 inspection-rt，該 RT 具有 0.0.0.0/0 → 檢查-VPC-連接。檢查 VPC 路由經過 Network Firewall，然後回到 TGW 轉發到目的 spoke。檢查 VPC 的連接與一個檢查後 RT (post-inspection-rt) 關聯，該 RT 傳播到所有 spoke RT 並從所有 spoke 接收傳播。

透過黑洞路由實現顯式隔離

在 prod-rt 中，針對 non-prod CIDR 範圍新增一個靜態黑洞路由。即使傳播不小心將 non-prod 路由新增到了 prod-rt，在相同前綴長度下，靜態路由會勝過傳播路由，流量會被丟棄。這是縱深防禦的分段策略。

預設路由表

TGW 預設 RT (TGW 建立時產生) 是新連接的預設關聯 RT 和預設傳播 RT。對於生產環境設計，請在 TGW 層級停用預設關聯與預設傳播，以免連接自動加入非預期的 RT——強制維運人員顯式選擇。

TGW Connect — 基於 GRE 疊加 + BGP 的 SD-WAN 整合

TGW Connect 是一種特殊的連接類型，在現有的 VPC 或 DX 連接之上建立 GRE 隧道 + BGP 疊加。它專為 SD-WAN 設備整合設計，例如在 VPC 中執行第三方設備 (Aviatrix、Cisco SD-WAN、Palo Alto、Versa) 並需要與 TGW 進行 BGP 路由交換。

TGW Connect 的運作方式

TGW Connect 連接建立在底層的 VPC 連接或 DX 連接之上。Connect 連接每個 Connect 對等體提供最多 4 個 BGP 對等體，每個對等體都在 TGW Connect 對等體 (TGW IP) 與客戶 SD-WAN 設備 IP 之間的 GRE 隧道上運作。每個 BGP 對等體可以通報前綴；TGW 會在它們之間進行 ECMP。

為什麼使用 GRE + BGP 而非 VPN

GRE 的開銷低於 IPsec (無加密、無 IKE 握手)，且 TGW Connect 可以飽和 VPC 頻寬 (每個對等體高達 5 Gbps，4 個對等體共 20 Gbps)——遠高於 Site-to-Site VPN (~1.25 Gbps)。結合用於動態路由的 BGP，TGW Connect 是 AWS 原生解決方案，用以回答：「我有 SD-WAN 雲端入口；如何與我的 AWS 網路整合？」

使用案例

• VPC 中的 SD-WAN 設備需要與 TGW 進行 BGP 路由交換。
• 透過多個 BGP 對等體的 ECMP 實現高頻寬聚合。
• 加密可選 (如果需要，在 SD-WAN 設備層級進行加密)。

限制

• Connect 連接需要底層的 VPC 或 DX 傳輸連接。
• 加密是客戶的責任 (GRE 本身不加密)。
• 僅限 BGP — Connect 不支援靜態路由。

Transit Gateway 上的多點傳送 (Multicast)

TGW 多點傳送允許跨 VPC 的 IP 多點傳送流量通過 TGW。使用案例包含影片串流、金融市場數據饋送、多接收者遙測以及依賴多點傳送的舊式應用程式。

多點傳送網域 (Multicast domain)

在 TGW 上設定多點傳送網域。將 VPC 連接新增至該網域，這些 VPC 中的 ENI 透過 IGMP (網際網路群組管理協定) 或靜態註冊成為多點傳送成員。

IGMP vs 靜態成員身份

IGMP (v2) 允許 EC2 執行個體透過發送 IGMP 成員報告動態加入多點傳送群組。TGW 會監聽 (snoop) IGMP 並更新多點傳送轉發表。靜態成員身份則透過 API 直接註冊 ENI——對於穩定的工作負載更簡單，但沒有動態加入/離開功能。

多點傳送使用案例

• 金融市場數據 — 許多訂閱者高效地接收相同的數據饋送。
• 影片串流 — 單一來源，許多接收者，不會造成每個接收者的頻寬放大。
• 服務發現 — 依賴多點傳送的舊式發現協定。
• 股票交易平台 — 低延遲、單一來源多接收者的模式。

限制

• TGW 多點傳送僅限區域性 — 無法跨區域傳送。
• 跨 VPC 多點傳送要求來源和目的 VPC 都在該多點傳送網域中。
• 每個來源 ENI 的輸送量有限制 (視執行個體類型而定)。

跨區域 TGW 對等互連 — 僅限靜態，無 BGP

TGW 對等互連 (TGW peering) 連接相同或不同區域的兩個 TGW。跨區域對等互連使用 AWS 骨幹網路 — 經加密、低延遲、不經過網際網路。

僅限靜態路由

TGW 對等互連連接不支援 BGP。對等 TGW 之間的所有路由必須在每一側的 TGW 路由表中作為靜態條目存在。這是 ANS-C01 考試中關於 TGW 對等互連最常考的陷阱。

設定步驟

從 TGW-1 到 TGW-2 建立對等互連連接 (可透過 RAM 跨區域和帳號運作)。在 TGW-2 端接受對等互連。在每個 TGW 相關的 RT 中新增靜態路由：<遠端區域 VPC CIDR> → 對等互連連接 ID。兩側都需要顯式的靜態路由。

使用案例

• 多區域災難復原 (DR) — 透過私有的 TGW 對 TGW 連線在區域間複製工作負載。
• 多區域應用程式 — 具備區域性 VPC 的全球服務。
• 法規合規 — 區域數據駐留與選擇性的跨區域存取。

替代方案

• Cloud WAN — AWS 託管的 WAN，具備基於政策的跨區域路由，支援 BGP，是複雜多區域場景下 TGW 對等互連的替代方案。
• Direct Connect Gateway — 適用於本地連線到多個區域的混合場景，DXGW + Transit VIF 有時比 TGW 對等互連更簡單。

Direct Connect Gateway 與 TGW 整合

Direct Connect Gateway (DXGW) 讓單一 Direct Connect 連線終止到多個 AWS 區域的多個 VPC。結合 TGW 時，DXGW + Transit VIF + TGW 讓客戶能透過一個 DX 連線存取每個區域中的每個 VPC (受配額限制)。

Transit VIF + DXGW + TGW

架構：Direct Connect 連線具有一個關聯至 DXGW 的 Transit VIF。DXGW 與一個或多個 TGW 關聯。每個 TGW 都有 VPC 連接。來自本地的封包：

1. 透過 DX 連線進入 AWS。
2. 由 Transit VIF 路由到 DXGW。
3. DXGW 根據關聯轉發到適當的 TGW。
4. TGW 路由到目標 VPC 連接。

這可以與分段的 TGW 路由表設計無縫結合——本地流量根據其落在主機 TGW 上的位置進入正確的分段。

限制

• 每個 DXGW 最多 20 個 VPC (可提高)。
• 每個 DXGW 最多 20 個 TGW (可提高)。
• 每個 TGW 可以與 20 個 DXGW 關聯。
• 允許的前綴 (Allowed prefixes)：每個 TGW-DXGW 關聯都有一個允許前綴清單 (TGW 透過此 DXGW 向本地通報的前綴)。這就是你控制哪些 VPC CIDR 對本地可見的方式。

TGW 對等互連不經過 DXGW

跨區域的 TGW 連線需要 TGW 對等互連，而非 DXGW。DXGW 用於本地 ↔ AWS 的多區域連線；TGW 對等互連用於 AWS 內部的多區域連線。

AWS RAM — 跨帳號 TGW 共用

AWS Resource Access Manager (RAM) 在 AWS Organization 內共用 TGW 資源。標準模式：中央網路帳號擁有 TGW；成員帳號 (工作負載帳號) 將其 VPC 連接到共用的 TGW。

共用模型

• 資源共用 — 一個 RAM 結構，捆綁資源 (TGW、子網路等) 並列出允許使用它們的主體 (帳號、OU、組織)。
• 共用 TGW — 網路帳號建立資源共用，包含 TGW，並授予成員帳號存取權限。
• 成員帳號行為 — 一旦共用，成員帳號可以從其 VPC 建立到 TGW 的連接。TGW 本身仍由網路帳號擁有和管理。

自動接受 (Auto-acceptance)

預設情況下，建立連接需要中央帳號手動接受每個連接。可以針對每個 TGW 或每個共用資源啟用自動接受，當中央網路團隊信任成員帳號自行決定連接時，這非常有用。

成員帳號不能做的事

成員帳號可以建立 VPC 連接並檢視 TGW，但不能：

• 修改 TGW 路由表 (僅擁有帳號可以)。
• 修改其他帳號的連接。
• 刪除 TGW。

這種分離是中央網路治理模型的關鍵：工作負載團隊擁有其 VPC 和連接；中央網路團隊擁有傳輸架構。

透過 TGW 實現集中式出口 (Egress) 模式

集中式出口模式使用一個連接到 TGW 的共用出口 VPC，其中包含 NAT GW + IGW，因此所有 spoke VPC 共用一組 NAT GW (每個 AZ 一個) 來進行出站網際網路存取。

架構

• 出口 VPC：公有子網路包含 IGW + NAT GW (每個 AZ 一個)；私有子網路包含 TGW 連接。
• Spoke VPC：TGW 連接，預設路由 0.0.0.0/0 → tgw-xxx。
• TGW 路由表：每個 spoke RT 都有 0.0.0.0/0 → 出口-VPC-連接。出口 VPC 的連接 RT 具備來自 spoke CIDR 的傳播，用於回程流量。

成本效益

不使用集中式出口：每個 spoke 需要在每個 AZ 擁有自己的 NAT GW。如果有 10 個 spoke 和 3 個 AZ，則需要 30 個 NAT GW。 使用集中式出口：總共只需要 3 個 NAT GW (位於出口 VPC)。NAT GW 的每小時費用和每 GB 流量費用隨 NAT 數量線性增加，因此合併可以節省大量成本——代價是略微增加跨 AZ 資料傳輸費用 (TGW + NAT GW + IGW 路徑)。

過濾機制

出口 VPC 是放置 AWS Network Firewall 或第三方出口防火牆的自然位置，用於檢查出站流量——網域允許清單、惡意軟體 C2 阻斷、滲漏防止。所有 spoke 流量都流經這單一瓶頸。

限制

• 跨 AZ 資料傳輸成本：來自 AZ-1 的 spoke 流量到達 AZ-2 的 NAT GW 會產生跨 AZ 費用。透過將出口 VPC 的 AZ 與 spoke AZ 對齊並在 TGW 中設定 AZ 親和性 (設備模式有幫助) 來減輕此問題。
• 如果不是多 AZ 部署，則存在單點故障。請務必在出口 VPC 的每個 AZ 部署 NAT GW。

搭配 Network Firewall 的檢查 VPC 模式

檢查 VPC 模式將 AWS Network Firewall (或透過 GWLB 的第三方狀態防火牆) 放置在專用 VPC 中，所有 spoke 間和出站流量都透過 TGW 路由經過它。

架構

• 檢查 VPC：子網路包含 Network Firewall 端點 (每個 AZ 一個)；TGW 連接啟用設備模式。
• Spoke VPC：TGW 連接，預設路由 0.0.0.0/0 → tgw-xxx。
• TGW 路由表：
  • Spoke RT：0.0.0.0/0 → 檢查-VPC-連接，<其他 spoke CIDR> → 檢查-VPC-連接。
  • 檢查 RT：接收來自 spoke CIDR 的傳播，允許檢查後的流量轉發到目的 spoke。

為什麼設備模式是強制性的

狀態防火牆要求對稱流程。如果沒有設備模式，回程流量可能透過不同的 AZ TGW ENI 進入檢查 VPC，並撞上一個從未見過 SYN 的防火牆執行個體——連線會中斷。設備模式固定了流程。

結合集中式出口

對於生產環境設計，將檢查 VPC 與集中式出口結合：spoke → TGW → 檢查 VPC → TGW → 出口 VPC → NAT → IGW。出站流量先經檢查再進行 NAT；入站回程流量透過設備模式對稱地接受檢查。

TGW Network Manager — 可見性與拓撲

Transit Gateway Network Manager 是一個區域性服務，用於註冊 TGW 並提供：

• 拓撲視圖 — TGW 連接、路由表和連線的圖形化表示。
• 路由分析器 (Route Analyzer) — 模擬連接之間的路徑以驗證路由意圖。
• CloudWatch 指標與事件 — 頻寬使用率、丟包率、連接狀態變更。
• EventBridge 整合 — 對拓撲變更、連接失敗做出反應。

對於多帳號組織，註冊一個全球網路 (Global Network)，該網路聚合了來自多個帳號/區域的 TGW，以實現統一的可見性。

常見陷阱複習 — Transit Gateway 在 ANS-C01

陷阱 1：TGW 對等互連支援 BGP

錯誤。TGW 對等互連僅限靜態路由。若要實現基於 BGP 的多區域路由，請使用 Cloud WAN。

陷阱 2：設備模式僅在跨區域流量時需要

錯誤。對於在多 AZ 檢查 VPC 中進行的任何狀態檢查，設備模式都是必需的——否則本地區域的跨 AZ 流程會中斷。

陷阱 3：預設路由表能很好地涵蓋所有連接

對於生產環境而言是錯誤的。應停用預設關聯與傳播，強制進行顯式的連接設定，以防止非預期的跨段洩漏。

陷阱 4：TGW Connect 使用 IPsec

錯誤。TGW Connect 在底層 VPC/DX 連接之上使用 GRE (不加密)。加密是客戶的責任。

陷阱 5：VPC 連接僅需要一個子網路

技術上可行但非最佳實務。應在每個 AZ 選擇一個子網路以實現高可用性。單子網路連接會失去與 spoke 中其他 AZ 的連線性。

陷阱 6：TGW 支援跨區域的多點傳送

錯誤。TGW 多點傳送僅限區域性。不支援跨區域多點傳送。

陷阱 7：DXGW 執行區域間的 TGW 對等互連

錯誤。DXGW 用於本地 ↔ AWS 的多區域連線。TGW 對等互連用於 AWS 內部的跨區域連線。

陷阱 8：成員帳號可以修改共用的 TGW 路由表

錯誤。只有擁有帳號可以修改 TGW 路由表。成員帳號只能建立 VPC 連接。

FAQ — Transit Gateway 路由與連接

Q1：TGW 上的關聯 (association) 與傳播 (propagation) 有什麼區別？

關聯決定了連接用於出站查閱的 TGW 路由表。每個連接精確地與一個路由表關聯——當流量從該連接到達時，TGW 會查閱關聯的 RT 以尋找目的地。傳播決定了連接的路由 (通報的前綴) 會進入哪些 TGW 路由表。一個連接可以傳播到多個 RT。案例實作：生產 VPC 連接與 prod-rt 關聯 (因此其出站流量查閱 prod-rt)，並將其 CIDR 傳播到 prod-rt 和 shared-rt (因此生產和共用連接都能找到它)。關聯與傳播的解耦是 TGW 設計的核心。

Q2：為什麼檢查 VPC 需要設備模式？如何啟用它？

設備模式強制流程的雙向流量通過同一個 AZ 的同一個 TGW 連接 ENI。如果沒有它，TGW 會針對每個 AZ 做出決策，可能導致請求通過 AZ-1 的 ENI 而回應通過 AZ-2 的 ENI。檢查 VPC 中的狀態防火牆因為在 AZ-2 上沒有原始 SYN 記錄，會丟棄回應。在建立 VPC 連接時或透過 modify-transit-gateway-vpc-attachment --options "ApplianceModeSupport=enable" 啟用。此設定僅套用於檢查 VPC 的連接——spoke 不需要。務必為任何託管 Network Firewall、Palo Alto VM-Series、Check Point、Fortinet 或任何狀態網路功能的 VPC 啟用設備模式。忘記設備模式是 ANS-C01 考試中「跨 AZ 流程間歇性連線中斷」排錯題最高頻的誘因。

Q3：何時應使用 TGW Connect 而非 Site-to-Site VPN 進行 SD-WAN 整合？

當 SD-WAN 設備位於 VPC 中，且你需要與 TGW 進行高頻寬 BGP 路由連線時，請使用 TGW Connect。Connect 每個 BGP 對等體提供高達 5 Gbps (4 個對等體 ECMP 共 20 Gbps)，遠高於 VPN 的 ~1.25 Gbps。Connect 使用 GRE (開銷低於 IPsec)，並假設 SD-WAN 設備在自身層級處理加密。當直接連接本地硬體 (路由器或防火牆) 到 AWS 而不使用 SD-WAN 設備，或者你需要單一 AWS 託管原始元件提供端對端 IPsec 加密時，請使用 Site-to-Site VPN。針對「VPC 中的 SD-WAN 設備，需要 10 Gbps 到 TGW 且具備 BGP」的情境，答案是 TGW Connect；「分支機構路由器需要 IPsec 到 AWS」則是 Site-to-Site VPN。

Q4：如何跨 20 個 AWS 帳號共用 TGW 並防止非預期的連接？

使用 AWS Resource Access Manager (RAM) 共用 TGW。中央網路帳號建立一個包含 TGW 的資源共用，並授予特定帳號、組織單位 (OU) 或整個 AWS Organization 存取權限。成員帳號隨後可以從其自身的 VPC 建立到共用 TGW 的 VPC 連接。為了防止非預期連接：(a) 停用自動接受，以便中央帳號必須核准每個連接；(b) 在 TGW 層級停用預設關聯與預設傳播，使新連接預設不屬於任何路由表——中央帳號顯式指派關聯；(c) 使用 AWS Config 規則與 EventBridge 在建立新連接時發出警示。結果是：只有中央網路團隊核准並設定的連接才會擁有連線性。

Q5：如何透過單一 TGW 對 prod 和 non-prod 流量進行分段？

建立兩個 TGW 路由表：prod-rt 和 non-prod-rt。生產 VPC 連接與 prod-rt 關聯並傳播到 prod-rt + shared-rt。非生產 VPC 連接與 non-prod-rt 關聯並傳播到 non-prod-rt + shared-rt。共用服務 VPC 連接與 shared-rt 關聯並傳播到所有三個。結果：prod 可以存取 prod 和 shared 但不能存取 non-prod (因為 non-prod CIDR 不在 prod-rt 中)；non-prod 對稱。為了更保險，在 prod-rt 中新增 non-prod CIDR 的靜態黑洞路由，反之亦然，這樣即使傳播設定錯誤，相同長度的黑洞路由也會勝出。結合 AWS Config 規則來偵測未經授權的傳播變更。

Q6：如果我沒有在檢查 VPC 連接上啟用設備模式會發生什麼事？

跨 AZ 流程會非對稱地在 TGW ENI 之間分開。流程的請求通過 AZ-1 的檢查設備執行個體 A；回應則通過 AZ-2 的執行個體 B。狀態防火牆 (Network Firewall、Palo Alto、Check Point、Fortinet) 要求流程的雙向流量都經過同一個執行個體以維持連線狀態。回應封包撞上一個沒有匹配連線記錄的設備，會被丟棄。症狀：連線在單一 AZ 內起初成功，但在跨 AZ 流程中會間歇性中斷；排錯顯示防火牆對原本有效的回程流量發出 TCP RST。修復：在檢查 VPC 的 TGW 連接上啟用設備模式——這是一個不增加額外成本的一次性設定變更，且能解決這一整類 bug。

Q7：TGW 對等互連與 VPC 對等互連有何不同？何時該使用哪一個？

VPC 對等互連 (VPC peering) 是兩 VPC 之間直接的點對點連線，同區域內資料傳輸免費 (跨區域有費用)，支援每 VPC 最多 125 個活動連線，但不支援傳遞路由 (transitive routing) — spoke A 與 hub 對等且 hub 與 spoke B 對等，並不代表 A 可以連到 B。TGW 對等互連連接兩個 TGW (相同或不同區域)，僅支援靜態路由 (無 BGP)，並透過每個 TGW 的 spoke 提供多區域多 VPC 連線性。對於不需要傳遞路由且成本是首要考量的簡單兩 VPC 連線，請使用 VPC 對等互連。當你有需要跨區域的多 VPC TGW 部署 (例如 DR 複製、全球服務架構) 時，請使用 TGW 對等互連。TGW 對等互連的跨區域資料傳輸按每 GB 計費；同區域 TGW 對等互連也有 TGW 每 GB 處理費——有時比低流量場景下的 VPC 對等互連更貴。

Q8: 考試中我應該知道哪些關於 TGW 的限制？

考試相關的預設值：每個 TGW 5000 個連接 (可提高)、每個 TGW 20 個路由表 (可提高)、每個 TGW 路由表 10000 條路由、VPN 連接支援 50 個 ECMP 路徑、每個 DXGW 支援 20 個 VPC (可提高)、每個 DXGW 支援 20 個 TGW (可提高)。每 VIF 前綴限制：專用 VIF 從客戶端接收 100 個前綴，公有 VIF 接收 1000 個。頻寬：TGW Connect 提供最高 20 Gbps 聚合頻寬；Site-to-Site VPN 每隧道 ~1.25 Gbps；Direct Connect 原生 1/10/100 Gbps。考試會測試「超過路由限制」和「最大 ECMP 路徑」的情境——請辨認出「在通報 102 個前綴後 BGP 工作階段中斷」的症狀即為專用 VIF 的 100 前綴限制。

Q9：何時該選擇 Cloud WAN 而非 Transit Gateway 對等互連來處理多區域？

AWS Cloud WAN 是較新的 AWS 託管 WAN 服務 (2022 年推出)，提供基於政策的路由、原生跨區域分段以及區域間的 BGP——這些功能 TGW 對等互連都不具備。適用情況：(a) 需要基於 BGP 的多區域路由，而靜態 TGW 對等互連在維運上很痛苦；(b) 需要跨多個區域進行基於政策的分段，且使用宣告式設定；(c) 在多區域規模下與 SD-WAN 提供商 (Aviatrix、Cisco SD-WAN、Palo Alto Prisma) 整合；(d) 從頭開始構建現代多區域架構，沒有 TGW 對等互連的歷史包袱。適用 TGW 對等互連的情況：現有的 TGW 部署中新增對等互連很直接、單對多區域 (一區連一區)，或者 Cloud WAN 的溢價不具合理性。目前考試中 TGW 對等互連出現頻率高於 Cloud WAN，但 Cloud WAN 的重要性正在增加，可能會出現在較新的題目中。

Q10：如何使用 TGW 實現集中式出口同時強制執行檢查？

結合這兩種模式：spoke VPC 路由 0.0.0.0/0 → TGW。Spoke 的 TGW 路由表指向檢查 VPC 連接。檢查 VPC 具有 Network Firewall (或透過 GWLB 的第三方狀態防火牆) 並啟用了設備模式。檢查後，檢查 VPC 將流量再次路由回 TGW，針對檢查後的出口流量使用另一個 TGW 路由表，指向出口 VPC 連接。出口 VPC 具有 NAT GW + IGW 以實現實際的網際網路出口。回程流量對稱流動：IGW → 出口 VPC → TGW → 檢查 VPC (由於設備模式，在回程路徑上也受檢查) → TGW → spoke VPC。這種組合模式是 AWS 安全參考架構 (SRA) 的規範配置：每個出站封包都經過集中 VPC 進行檢查和 NAT，提供單一介面的政策執行和具成本效益的 NAT 合併。提到「集中式檢查與出口」的 ANS-C01 題目通常預期這種組合設計。

延伸閱讀與相關維運模式

• AWS Transit Gateway User Guide
• Transit Gateway Route Tables
• Transit Gateway Connect Attachments
• Transit Gateway Appliance Scenario
• Transit Gateway Multicast Overview
• Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
• AWS ANS-C01 Exam Guide

一旦 Transit Gateway 架構就緒，ANS-C01 上的下一個自然維運層級為：VPC 路由原始元件，用於 spoke 路由表如何將流量導向 TGW；BGP 屬性操作，用於在 DX 和 VPN 連接間進行混合流量工程；Direct Connect VIF 類型，用於混合連接；以及 PrivateLink，用於提供服務層級的連線性，作為單向服務公開的 TGW 補充。

• VPC 路由 — 最長前綴匹配、傳播與黑洞路由 — ANS-C01 備考筆記
• BGP 設定 — AS-Path Prepending、MED、社群與 BFD — ANS-C01 備考筆記
• Direct Connect — VIF 類型、LAG、MACsec 與 BGP 設計 — ANS-C01 備考筆記
• PrivateLink, VPC 端點與端點政策 — ANS-C01 備考筆記