大規模 Transit Gateway 與混合網路架構

SAP-C02 的 Transit Gateway 與混合雲網路主題概覽

Transit Gateway 與混合雲網路是 SAP-C02 中權重最高的網路主題，在 75 題計分題中會出現 8 到 12 題，在我們的考試遙測數據中熱度評分高達 0.90。當考題情境提到「50 個 VPC」、「兩個 AWS Region」、「地端資料中心」、「重疊 CIDR」、「集中出口」、「流量稽核」、「共用服務」，或「Dev/Prod 隔離」時，正確答案幾乎都涉及 Transit Gateway 與混合雲網路元件的協同運作。SAP-C02 不是在測試你是否聽過 Transit Gateway——它測試的是你能否設計同時滿足頻寬、延遲、韌性、分段和成本約束的 Transit Gateway 混合雲架構。

AWS 的混合雲網路涵蓋封包在地端資料中心、代管機房、其他雲端，以及 AWS VPC 之間所有可能的傳輸路徑。Transit Gateway 與混合雲網路的範圍包括：AWS Transit Gateway 本身（Region 級中樞）、AWS Direct Connect（專屬私人光纖）、AWS Site-to-Site VPN（IPSec over 公共網際網路）、AWS Direct Connect SiteLink（透過 AWS 骨幹進行地端對地端傳輸）、Virtual Private Gateway（舊式單一 VPC 連接）、Direct Connect Gateway（多 Region Private VIF 匯聚器）、Transit VIF（Transit Gateway 與 Direct Connect 配對）、Transit Gateway 跨 Region Peering、Transit Gateway Connect（SD-WAN 整合）、Multicast、Appliance Mode，以及 Gateway Load Balancer Inspection 模式。整體掌握這些元件——而非單獨學習——大約三分之一的 SAP-C02 網路題目將會變成機械式作答。

本筆記以 Pro 深度撰寫，涵蓋所有 attachment 類型、所有路由表行為、所有 Direct Connect 韌性等級及其精確 SLA 百分比、重疊 CIDR 修復模式、集中出口設計藍圖、GWLB Inspection VPC、受管工作負載的分段設計，以及「50 VPC 組織搭配 Dev/Prod 隔離」的完整情境演練。我們也提供決策矩陣、非對稱路由除錯流程，以及一整套資深工程師仍會答錯的 SAP-C02 式陷阱題。

白話文解釋 Transit Gateway 與混合雲網路

Transit Gateway 與混合雲網路充斥著大量術語，但一旦對應到日常系統，底層心智模型其實相當直觀。以下三個類比在進入路由表、BGP 和 Inspection Pipeline 之前，先為 Transit Gateway 與混合雲網路概念建立直覺。

類比一：高速公路交流道（Transit Gateway 作為樞紐）

把每個 VPC 想像成一個城鎮，把每條 Site-to-Site VPN 或 Direct Connect 連線想像成從外縣市來的省道。在 Transit Gateway 出現之前，你必須在每對城鎮之間各開一條專用道路（VPC Peering）。十個城鎮需要 45 條道路，五十個城鎮需要 1,225 條道路——根本無法維護。Transit Gateway 就是一座高速公路交流道，座落在所有城鎮的中心點。每個城鎮只需開一條匝道上交流道，每條長途路線（VPN、Direct Connect）也在交流道匯入，交流道再把車流分配到正確的出口匝道。Transit Gateway 路由表就是交流道的路標指示板：「來自 Dev 城鎮的車輛只能駛往 Shared-Services；來自 Prod 城鎮的車輛可駛往任何出口。」Transit Gateway Peering 就是連接另一座城市的跨城快速道路——兩座交流道之間有一條專屬的高速幹線行駛於 AWS 骨幹上，完全不需要繞行一般省道。Transit Gateway Connect 是一家貸士（SD-WAN 設備商），插入交流道後用自己的票務系統（GRE 隧道與 BGP）提供連線，你不必自己管理一條條 VPN 隧道。

類比二：電力輸配電網（Direct Connect 韌性等級）

AWS Direct Connect 就像供應你資料中心的電力輸配電網。單地點、單連線的 Direct Connect 是一條來自一座變電站的電纜——電纜被挖斷或變電站跳脫，電力全失。AWS 提供 99.9% SLA 的保障，聽起來不錯，但 0.1% 換算下來是每年約八小時的停電。高韌性模型（99.99% SLA） 等於兩條電纜來自同一都會區的兩座不同變電站——施工隊挖斷某條街道也不會讓你的大樓停電。最大韌性模型（99.99% SLA） 則是四條電纜分佈於兩個不同都會區的兩座變電站——即使發生區域性電網故障，你仍有電可用。Link Aggregation Group（LAG）是把四條細電纜綑成一條粗幹線，讓你拉出更大電流；Bidirectional Forwarding Detection（BFD）是快速跳脫的無熔絲開關，在電纜故障後一秒內跳脫，而非等待三十秒讓慢速保險絲（BGP hold timer）才反應。SiteLink 是電力公司把你多餘的電網容量出售給鄰棟大樓——你的兩個辦公室透過 AWS 骨幹互通，而非透過在地配電網繞路。

類比三：辦公大樓樓層規劃（分段與 Inspection VPC）

把你的多 VPC AWS 架構想像成一棟企業辦公大樓。每個 VPC 是一個樓層。Dev、Staging、Prod、Shared-Services 各自佔一層。Transit Gateway 路由表是電梯裡的門禁感應矩陣：Dev 感應卡只能停在 Dev 層與 Shared-Services 層；Prod 感應卡只能停在 Prod 層與 Shared-Services 層；兩者都無法按下對方的樓層按鈕。搭載 Gateway Load Balancer 的 Inspection VPC 是收發室兼保全樓層，所有對外的包裹都必須先到這一層——GENEVE 隧道把每個信封包起來，保全（第三方防火牆設備）對內容進行掃描，合格的信封才會被轉交繼續遞送。Appliance Mode 是一條規定：「負責檢查你去程信封的保全，也必須負責檢查回程的回覆」，確保同一個連線不會被兩位無法共享記錄的保全分頭處理（對稱流量）。集中出口 VPC 是整棟大樓唯一的裝卸貨場——所有樓層的對外網際網路流量都在這裡匯合，整棟樓只需一組 NAT Gateway 和一個防火牆群，而非每層樓各自複製一套。

有了高速公路交流道、電力輸配電網，以及辦公大樓樓層規劃這三個類比作為基礎，Transit Gateway 與混合雲網路的情境題就變成辨識對應的類比，再順著其邏輯推導即可。

Transit Gateway Attachments — 六種必知類型

每一個 Transit Gateway 與混合雲網路設計都從 attachments 開始。Transit Gateway 是一個 Region 級物件；你把輻條（spokes）接到它上面，每個 attachment 都有一個類型。SAP-C02 會考你每種 attachment 類型的取捨與限制，通常描述一個工作負載後問哪種 attachment 或組合是正確的。

VPC Attachment

VPC attachment 會在輻條 VPC 內的每個 Availability Zone 各建立一個 Elastic Network Interface。Transit Gateway 接著把路由推送到該子網路的路由表（或你手動新增）。從 VPC 出發前往另一個輻條的任何 CIDR 的流量，都會流向 Transit Gateway ENI，穿越中樞，再進入目的地。VPC attachment 是 Transit Gateway 與混合雲網路設計中最常用的類型。你應該在 VPC 使用的每個 AZ 都建立 attachment——若缺少某個 AZ 的 attachment，該 AZ 中的工作負載在單 AZ 部署期間將失去 Transit Gateway 連通性。

VPN Attachment

VPN attachment 讓 Site-to-Site VPN 直接終止在 Transit Gateway 上，而非舊式的 Virtual Private Gateway。系統會自動佈建兩條 IPSec 隧道以提供韌性。強烈建議使用 BGP（動態路由）而非靜態路由，讓故障切換自動完成。VPN attachment 可以加速——流量抵達最近的 AWS edge Point-of-Presence 後，改走 AWS 骨幹進入 Region，大幅降低遙遠地域 Customer Gateway 的抖動。Accelerated VPN 費用較高且非所有 Region 都支援，但它是「Customer Gateway 在非洲、工作負載在 us-east-1、VPN 延遲不穩定」情境的預設答案。

Direct Connect Gateway Attachment（透過 Transit VIF）

Direct Connect 無法直接連接到 Transit Gateway。拓樸為：Direct Connect 實體連線 -> Transit VIF -> Direct Connect Gateway -> Transit Gateway。單一 Direct Connect Gateway 最多可與 三個 Transit Gateway（跨最多三個 Region）配對，讓一組 Direct Connect 埠口實現多 Region 混合雲網路。每條 Direct Connect 連線限用一個 Transit VIF——這是 SAP-C02 的常見陷阱，因為考生常以為 VIF 數量不受限。

Transit Gateway Peering Attachment

不同 Region（或同一 Region 的不同帳號）的兩個 Transit Gateway 可以互相 Peer。跨 Region Transit Gateway Peering 走 AWS 全球骨幹、在 AWS 硬體層自動加密、只支援靜態路由（兩個 Transit Gateway 之間沒有 BGP），並可在不架設跨 Region VPN 隧道的情況下實現多 Region Transit Gateway 與混合雲網路設計。同 Region 跨帳號 Peering 同樣有效，常見於企業合併與收購場景。

Transit Gateway Connect Attachment

Connect attachment 用於在 VPC 內執行的 SD-WAN 設備和第三方網路虛擬設備。設備對 Transit Gateway 終止 GRE 隧道並透過 BGP 交換路由。Connect attachment 每條 GRE 隧道最高提供 5 Gbps，每個 Connect attachment 總計最高 20 Gbps，遠超 Site-to-Site VPN 的上限。若情境描述「Cisco Meraki SD-WAN」或「VeloCloud 設備需要高頻寬 BGP」，Transit Gateway Connect 就是正確答案。

Transit Gateway Multicast Domain（Attachment 延伸功能）

Multicast 不是傳統的 attachment 類型，而是建立在 VPC attachment 之上的功能。Transit Gateway 可以扮演 Multicast Router，讓一個來源把封包發送給跨多個附加 VPC 的多個接收端。使用場景較窄——金融市場資料饋流、舊式企業應用程式、IPTV——但 SAP-C02 曾考過，因為其他 AWS 服務都沒有在 VPC 之間提供原生 Multicast 的能力。

Transit Gateway 路由表、Association 與 Propagation

Transit Gateway 路由表是將中樞轉化為分段引擎的控制平面。每個 Transit Gateway attachment 恰好與一個路由表有一個 association——這個 association 決定 attachment 在決定封包要送往哪裡時，會查閱哪張路由表的路由。Propagation 是反向操作：一個 attachment 可以把自己的 CIDR 傳播到多張路由表，讓與這些表關聯的任何 attachment 都能抵達這些 CIDR。Association 是「我從哪裡讀取路由」；Propagation 是「我向哪裡廣告我的路由」。

靜態路由 vs 傳播路由

傳播路由是自動學習的（來自 VPC attachment 的 CIDR，或來自 VPN 或 Direct Connect attachment 上的 BGP）。靜態路由是手動輸入的。對於相同前綴，靜態路由優先於傳播路由（更具體或等長皆然）。靜態路由對於封鎖特定前綴（路由至 blackhole 目標）以及覆蓋 BGP（當你必須強制流量通過 Inspection VPC 時）至關重要。

隔離 vs 共用路由表模式

Transit Gateway 與混合雲網路分段設計的標準作法是每個域（domain）使用一張路由表：

• Prod 路由表：Prod VPC attachment 關聯此處。Prod 傳播至 Prod 和 Shared-Services。
• Dev 路由表：Dev VPC attachment 關聯此處。Dev 傳播至 Dev 和 Shared-Services。
• Shared-Services 路由表：Shared-Services VPC attachment 關聯此處。Shared-Services 傳播至 Prod、Dev，以及自身。
• On-prem 路由表：Direct Connect Gateway 和 VPN attachment 關聯此處。它們把地端 CIDR 傳播至 Prod 和 Shared-Services，但不傳播至 Dev。

結果：Prod 無法抵達 Dev，Dev 無法抵達 Prod，兩者都能抵達 Shared-Services，地端可抵達 Prod 但無法抵達 Dev。這項分段不需要任何 Security Group 規則或 NACL——它靠的是路由表中路由的缺席來強制執行。

Blackhole 路由

Transit Gateway 路由表中的 Blackhole 路由會默默丟棄符合前綴的流量。Blackhole 用於預防意外的連通性（例如，在 Dev 路由表中明確 Blackhole Prod CIDR，使得未來的設定錯誤無法讓 Dev 路由至 Prod），以及在事故應對期間吸收類 DDoS 流量。

AWS Direct Connect 深度解析 — 實體、邏輯與韌性

Direct Connect 是 Transit Gateway 與混合雲網路中的私人光纖半部。SAP-C02 從四個層面深入考察 Direct Connect：實體連線、邏輯 VIF、Direct Connect Gateway，以及韌性等級。

Dedicated Connection vs Hosted Connection

Dedicated Connection 是在 Direct Connect 機房為你分配的完整實體埠口（1 Gbps、10 Gbps 或 100 Gbps）。你擁有埠口、直接支付埠口時費，並可在上面建立最多 50 個 VIF。Hosted Connection 是合作夥伴實體埠口的邏輯切片，可用的頻寬從 50 Mbps 到 10 Gbps 不等。Hosted Connection 的佈建速度更快（數小時到數天，相較於數週到數個月），只帶一個 VIF，並透過合作夥伴計費。當 SAP-C02 情境說「需要在一週內上線 500 Mbps」，Hosted Connection 是正確答案；「需要 100 Gbps 且已有跨接電纜」則指向 Dedicated。

Virtual Interfaces (VIFs) — 三種類型

• Private VIF：透過 Virtual Private Gateway 抵達一個 Amazon VPC，或透過 Direct Connect Gateway 匯聚跨 Region 的多個 VPC。Private VIF 傳輸 RFC1918 流量。
• Public VIF：透過 AWS 骨幹抵達本 Region 及全球每個 Region 所有 AWS 公共服務端點（S3、DynamoDB、KMS、公共 API），但不抵達公共網際網路。Public VIF 使用公共 AS 號碼並向 AWS 廣告你的公共前綴。SiteLink 需要 Public VIF。
• Transit VIF：抵達與最多三個 Transit Gateway 關聯的 Direct Connect Gateway。每條 Direct Connect 連線限用一個 Transit VIF——這是硬性限制。

Link Aggregation Group（LAG）

LAG 把同一 Direct Connect 機房中最多四條相同頻寬的 Dedicated Connection 透過 LACP 綑綁成單一邏輯連線。LAG 提升吞吐量（2x、3x 或 4x）並提供成員級韌性（斷一條電纜，仍保有 N-1 條）。LAG 不可跨機房——那是高韌性模型的職責，見下方說明。

Bidirectional Forwarding Detection（BFD）

BFD 是疊加在 BGP 上的次秒級連線存活協定。若無 BFD，BGP 依賴預設 90 秒的 hold timer，意味著連線故障後流量最多被黑洞吸收 90 秒 BGP 才偵測到。啟用 BFD 後，故障偵測降至約一秒。AWS 在 AWS 端預設啟用 BFD；你必須在客戶路由器上自行啟用。在所有正式環境的 Direct Connect 與 VPN attachment 上啟用 BFD——SAP-C02 對於「收斂時間為 90 秒，請縮短」的正確答案永遠是「啟用 BFD」。

Direct Connect 韌性模型 — 精確 SLA

AWS 發佈了 Direct Connect 與混合雲網路韌性的三個參考模型：

從 99.9% 到 99.99% 意味著每年允許的停機時間從約 8 小時降至約 52 分鐘。最大韌性是唯一能存活 Direct Connect 機房層級事件（火災、停電、都會區光纖切斷）的模型。受管行業（金融、醫療）預設採用最大韌性。

Direct Connect Gateway — 多 Region 匯聚器

Direct Connect Gateway 是一個全域 AWS 物件（不綁定特定 Region），位於 Direct Connect VIF 與一個或多個 Virtual Private Gateway 或 Transit Gateway 之間。單一 Direct Connect Gateway 支援全球每個 AWS Region 的 VGW 關聯，並支援最多三個 Region 的 Transit Gateway 關聯。SAP-C02 常見的設計是：

位於 us-east-1 Ashburn 的一條 Direct Connect 連線 -> Transit VIF -> Direct Connect Gateway -> us-east-1 的 Transit Gateway + eu-west-1 的 Transit Gateway（透過跨 Region DX Gateway 關聯）。

這讓位於 Ashburn 的一對光纖連線，利用 AWS 骨幹進行跨 Region 跳轉，就能抵達多個 Region 的 VPC。不需要 VPN 隧道，也不需要第二套 Direct Connect 佈建。

AWS Direct Connect SiteLink

SiteLink 是透過 AWS 骨幹進行地端對地端的功能。兩個 Direct Connect 機房（例如倫敦和新加坡）可以透過 AWS 全球網路交換流量，流量完全不需要接觸任何 AWS VPC。SiteLink 替代多站點企業的私人 MPLS，通常成本遠低於 MPLS。SiteLink 需要 Public VIF 或 Transit VIF——不支援 Private VIF——並按 SiteLink 固定費加資料傳輸計費。當情境說「東京辦公室需要與法蘭克福辦公室通訊，兩地都已有 AWS Direct Connect」，答案就是 SiteLink。

AWS Site-to-Site VPN — 靜態、BGP 與加速模式

Site-to-Site VPN 是 Transit Gateway 與混合雲網路中的 IPSec over 網際網路半部。AWS 提供的每條 VPN 連線都設有兩條隧道，終止在同一 Region 的兩個不同 Availability Zone——兩條隧道同時啟用，你的 Customer Gateway（CGW）應該對兩條隧道做負載平衡或主動使用。

靜態路由 vs BGP

靜態路由 VPN 需要你在 AWS 端手動輸入每個遠端 CIDR，並在 CGW 端手動輸入每個 AWS CIDR。隧道故障後不會自動切換——CGW 必須偵測隧道斷線後才手動切換流量。BGP VPN 透過每條隧道動態交換路由，並根據 BGP keep-alive（或 BFD）自動切換。正式環境的 Transit Gateway 與混合雲網路設計一律選用 BGP。 靜態路由僅適用於不支援 BGP 的舊式 CGW。

Customer Gateway（CGW）

Customer Gateway 是 AWS 端用來描述你的地端路由器的物件——記錄公共 IP、BGP ASN（或「靜態」）以及選用的憑證。CGW 物件不會設定你的實體路由器；你必須自行將 AWS 產生的設定套用到你的實體或虛擬路由器（Cisco ASA、Juniper SRX、Palo Alto、pfSense 等）。

Accelerated Site-to-Site VPN

Accelerated VPN 讓 VPN 連接到 AWS Global Accelerator，使 IPSec 隧道在最近的 AWS 邊緣節點終止，再走 AWS 骨幹進入 Region。對於非洲、南美洲、東南亞或大洋洲的客戶，Accelerated VPN 通常能將往返延遲減半，並消除壅塞傳輸路徑造成的抖動。需要 VPN 附加至 Transit Gateway（不支援 Virtual Private Gateway），並會產生 Global Accelerator 費用。

隧道吞吐量上限

單條 IPSec 隧道吞吐量上限約為 1.25 Gbps。透過 Transit Gateway VPN attachment 的 Equal-Cost Multipath（ECMP）可以彙整多條 VPN 連線來擴充，實務上最高可達約 50 Gbps。超過此上限請改用 Direct Connect 或 Transit Gateway Connect。

拓樸模式 — Hub-and-Spoke vs Mesh vs 混合

全網格（VPC Peering）

N 個 VPC 需要 N(N-1)/2 個 Peering*。N=50 時需要 1,225 個 Peering，每個 VPC 的路由表中都要有對應的每一筆路由。全網格僅在 N 很小（約 10 以下）、拓樸靜態、且需要絕對最低延遲（無中轉跳躍）時合理。VPC Peering 是非遞移的，因此網格是唯一全靠 Peering 運作的選項。

Hub-and-Spoke（Transit Gateway）

Transit Gateway 把網格壓縮為：N 個 attachment，而非 N*(N-1)/2 個 Peering。每個 VPC 只需一條路由指向 Transit Gateway 的輻條 CIDR 範圍，路由工作由 Transit Gateway 承擔。Hub-and-Spoke 增加單跳延遲（Region 內通常低於一毫秒），但使分段、記錄和費用管理集中化。這是任何超出少數幾個 VPC 的 Transit Gateway 與混合雲網路拓樸的預設選擇。

部分網格搭配 Transit Gateway

對於兩三對延遲敏感的 VPC，可結合 Transit Gateway 與針對性 VPC Peering。網格 Peering 的 VPC 之間走直接路由；其他所有流量走 Transit Gateway。在 VPC 路由表中，更具體的前綴優先，因此 Peering 前綴設計要比 Transit Gateway 前綴更窄。

Cloud WAN（相鄰模式）

AWS Cloud WAN 是較新的托管 WAN 服務，以單一全域政策文件抽象化 Transit Gateway、Direct Connect 和 VPN。Cloud WAN 在 SAP-C02 中屬於「認識並區分」層級。對於跨越超過約 5 個 Region 的多 Region、多帳號 Transit Gateway 與混合雲網路設計，Cloud WAN 通常優於手動串聯 Transit Gateway 跨 Region Peering。

Shared Services VPC 模式

每個企業 Transit Gateway 與混合雲網路架構都有一個 Shared Services VPC，承載所有其他 VPC 共用的資源——Active Directory 網域控制器、內部 DNS 解析器（Route 53 Resolver endpoints）、套件鏡像、監控收集器、PKI 服務、授權伺服器。模式如下：

1. 建立 Shared Services VPC。
2. 將其附加至 Transit Gateway。
3. 將其 attachment 關聯至 Shared-Services 路由表。
4. 把 Shared Services 的 CIDR 傳播至其他所有路由表（Prod、Dev、Sandbox、On-prem）。
5. 把其他每個 attachment 的 CIDR 傳播至 Shared-Services 路由表，讓 Shared Services 可以主動發起回應流量。
6. 在 Shared Services VPC 內使用 Route 53 Resolver 的 inbound/outbound endpoints，讓地端可以解析 AWS 私有 DNS，反之亦然。

這讓所有工作負載 VPC 都能抵達 Shared Services，而不需要網格連線，並集中化 DNS、身份識別與可觀測性——這是 Transit Gateway 與混合雲網路在成本和安全性上的重大收益。

集中出口 VPC 模式

每個擁有自己 NAT Gateway 的 VPC 都需要支付 NAT Gateway 的每小時費用加上每 GB 處理費。50 個 VPC 各自執行 2 個 NAT Gateway 做 AZ 冗餘，等於 100 個 NAT Gateway 全天候計費。集中出口模式的整合方法：

1. 建立一個專用出口 VPC，配置 NAT Gateway（每個 AZ 各一或兩個）。
2. 將出口 VPC 附加至 Transit Gateway。
3. 在每個輻條 VPC 的路由表中，將 0.0.0.0/0 指向 Transit Gateway。
4. 在輻條使用的 Transit Gateway 路由表中，新增靜態路由 0.0.0.0/0 -> 出口 VPC attachment。
5. 在出口 VPC 的 VPC 路由表中，0.0.0.0/0 指向 NAT Gateway；從網際網路返回的流量走 NAT -> Transit Gateway -> 原始輻條。

節省效果顯著：整個組織只需一組 NAT Gateway，而非 N 組。請注意 NAT Gateway 吞吐量上限（每個 NAT Gateway 45 Gbps）——若總出口流量超過此上限，請橫向擴展新增 NAT Gateway。

Inspection VPC 與 Gateway Load Balancer

受管工作負載（PCI-DSS、HIPAA、金融服務）通常要求每個封包都必須通過防火牆設備稽核——Palo Alto、Fortinet、Check Point、Cisco，或自訂 IDS。Transit Gateway 與混合雲網路的設計藍圖是搭載 Gateway Load Balancer（GWLB）的 Inspection VPC。

Gateway Load Balancer（GWLB）

GWLB 是一個 Layer 3/4 負載平衡器，運作於 IP 層，使用 GENEVE 協定（UDP 6081） 把原始封包——完整不變地——隧道傳輸到一組第三方虛擬防火牆設備。設備稽核封包後做出通過/丟棄決策，允許通過的流量再透過隧道送回。由於 GENEVE 保留了原始 5-tuple 和有效負載，設備看到的內容與「串聯式」實體防火牆完全相同。

設計藍圖

1. 建立含有 GWLB endpoints（每個 AZ 各一個）和 GWLB 後端防火牆 EC2 設備群的 Inspection VPC。
2. 將 Inspection VPC 附加至 Transit Gateway，並啟用 Appliance Mode。
3. 在輻條 Transit Gateway 路由表中，將 0.0.0.0/0（或東西向前綴，或兩者）的下一跳指向 Inspection VPC attachment。
4. 在 Inspection VPC 中，GWLB endpoints 接收流量，透過 GENEVE 隧道送至防火牆設備群，取得通過決定後，再透過 Transit Gateway 將流量向前傳遞。
5. 選擇性地串聯 Inspection VPC -> 出口 VPC，讓所有對外網際網路流量先稽核再集中 NAT。

結果：任何兩個輻條之間（或對外到網際網路）的每個封包都會通過防火牆設備群。分段由路由和設備規則共同強制執行。這是 Transit Gateway 與混合雲網路應對「PCI 工作負載在 AWS，安全團隊要求有狀態防火牆稽核」的標準答案。

重疊 CIDR 修復

Transit Gateway 不會在兩個廣告重疊 CIDR 的 attachment 之間路由——其中一個會被丟棄或造成無法預期的路由行為。重疊 CIDR 常見於企業合併、收購、搬遷上雲，以及「每個 VPC 都用 10.0.0.0/16」的不良預設。SAP-C02 有專門針對此問題的題型。修復選項，依優先順序排列：

1. 重新規劃一方 IP（最佳但昂貴且耗時——需要應用層協調，通常需要停機）。
2. 在橋接 VPC 中使用 Private NAT Gateway，將重疊的來源/目的 CIDR 對應至唯一的代理 CIDR。Transit Gateway 在橋接 VPC 與雙方之間使用唯一代理 CIDR 路由。
3. PrivateLink（VPC Endpoint Services）——如果只有少數幾個服務需要跨越重疊區域，透過 PrivateLink 發布。PrivateLink 對 CIDR 無感知，因為它在服務端點層級運作，而非 IP 層。
4. 在 Inspection VPC 中透過第三方防火牆進行 NAT——對來源和目的地做 NAT，讓兩方都看到唯一的 IP。
5. 最後手段：只在 Transit Gateway 上路由非重疊子前綴，接受部分連通性（鮮少可接受）。

Transit Gateway 跨 Region Peering

當工作負載跨越兩個或多個 AWS Region 時，Transit Gateway Peering 是首選的 Transit Gateway 與混合雲網路方法。

特性

• 走 AWS 全球骨幹（非公共網際網路）。
• 在 AWS 硬體層自動加密（AES-256）。
• 跨 Peering 只支援靜態路由——兩個 Transit Gateway 之間沒有 BGP。
• 跨 Region 資料傳輸按 GB 計費（請查閱各 Region 對的當前定價）。
• 延遲約等於跨 Region AWS 骨幹延遲（例如 us-east-1 <-> eu-west-1 約 70-75 ms）。

設計模式

每個 Region 一個 Transit Gateway；每個 Region 的工作負載連接至當地 Transit Gateway；兩個 Transit Gateway 相互 Peer。地端連線可在一個 Region 終止，再透過 Peering 抵達另一個 Region，但這會集中跨 Region 流量——對於高吞吐量的多 Region 地端存取，請在兩個 Region 各部署 Direct Connect，並使用與兩個 Transit Gateway 都關聯的 Direct Connect Gateway。

Transit Gateway Multicast

Multicast 是較少被討論的 Transit Gateway 與混合雲網路能力，但 SAP-C02 確實有考。Transit Gateway Multicast 讓你建立一個跨多個附加 VPC 的 Multicast Domain，透過靜態 IGMP 式成員資格或動態 IGMPv2 註冊來源與接收端。使用場景：

• 金融市場資料發布：報價來源 Multicast 至數十個分析消費端。
• 舊式企業應用程式：某些 ERP、交易和廣播平台需要 Multicast。
• AWS 架構內的 IPTV 或串流分發。

關鍵限制：Transit Gateway 上的 Multicast 需要 Nitro 系列執行個體，不跨 Transit Gateway Peering（僅限 Region 內），且流量無法傳送至 VPN 或 Direct Connect。當題目是「在單一 Region 內跨 VPC 進行 Multicast 且不重新架構」，Transit Gateway Multicast 就是答案。

Transit Gateway Connect（SD-WAN 整合）

Transit Gateway Connect 是 SD-WAN 的橋接器。你的 SD-WAN 虛擬設備（Cisco、VMware/VeloCloud、Aruba Silver Peak、Aviatrix、Fortinet、Versa 等）在轉接 VPC 的 EC2 上執行，對 Transit Gateway 終止 GRE 隧道，並透過 BGP 交換路由。相較於 VPN attachment 的優勢：

• 每個 Connect attachment 最高 20 Gbps 總計（相較於每條 VPN 隧道約 1.25 Gbps）。
• GRE 加 BGP——設備自行處理加密（或走 Direct Connect），不需要 IPSec 額外負擔。
• 來自設備控制器的原生 SD-WAN 政策——不需要雙重設定。

SAP-C02 常見情境：「企業在 200 個分支機構執行 Cisco SD-WAN，希望整合 AWS 但不更換 SD-WAN。」答案是 Transit Gateway Connect（若同時需要分支機構透過 AWS 互通，還需加上 SiteLink）。

情境模式 — SAP-C02 如何考 Transit Gateway 與混合雲網路

SAP-C02 題目遵循可辨識的模式。反覆練習，讓你在 30 秒內就能辨識模式。

模式一 — 「五個或更多 VPC 需要互相通訊」

關鍵詞：「十個 VPC」、「多帳號」、「Peering 的複雜度」。 正確答案：Transit Gateway 搭配 RAM 共享。VPC Peering 是干擾項（非遞移、網格爆炸）。

模式二 — 「降低多個 VPC 的 NAT Gateway 費用」

關鍵詞：「每個 VPC 都有自己的 NAT Gateway」、「優化出口成本」。 正確答案：集中出口 VPC 搭配 Transit Gateway 並啟用 Appliance Mode。總計兩或三個 NAT Gateway，而非 N 個。

模式三 — 「PCI/HIPAA 合規，需要有狀態稽核」

關鍵詞：「有狀態防火牆」、「第三方設備」、「稽核東西向流量」。 正確答案：搭載 Gateway Load Balancer 的 Inspection VPC，Transit Gateway 將所有流量路由通過它，啟用 Appliance Mode，設備放在 GWLB 後端的 Auto Scaling Group 中。

模式四 — 「兩個 Region，混合雲，最小化延遲與複雜度」

關鍵詞：「us-east-1 和 eu-west-1」、「兩地都有地端環境」。 正確答案：每個 Region 一個 Transit Gateway + Transit Gateway Peering + 每個 Region 各一套 Direct Connect + Direct Connect Gateway 與每個 Transit Gateway 的關聯。

模式五 — 「來自被收購公司的重疊 10.0.0.0/16」

關鍵詞：「重疊 CIDR」、「短期內無法重新規劃 IP」。 正確答案：PrivateLink 用於特定服務或橋接 VPC 中的 Private NAT Gateway。永遠不要「直接附加至 Transit Gateway」。

模式六 — 「Customer Gateway 在非洲，至 us-east-1 的延遲不穩定」

關鍵詞：「高抖動」、「無法預測的 VPN 延遲」、「客戶在偏遠地域」。 正確答案：Accelerated Site-to-Site VPN——流量進入最近的 AWS 邊緣後走骨幹。需要 Transit Gateway attachment（非 VGW）。

模式七 — 「故障切換需要 90 秒」

關鍵詞：「故障切換太慢」、「BGP 預設計時器」。 正確答案：在客戶路由器上啟用 BFD。將偵測時間降至約 1 秒。

模式八 — 「地端站點希望透過 AWS 互相通訊」

關鍵詞：「兩個辦公室，都有 Direct Connect，取代 MPLS」。 正確答案：在 Public 或 Transit VIF 上使用 AWS Direct Connect SiteLink。

模式九 — 「SD-WAN 設備，需要高頻寬 BGP 連入 AWS」

關鍵詞：「Cisco SD-WAN」、「VeloCloud」、「需要超過 1.25 Gbps」。 正確答案：Transit Gateway Connect 搭配 GRE 和 BGP。

模式十 — 「跨三個 VPC 進行 Multicast 股票報價」

關鍵詞：「Multicast」、「金融資料饋流」。 正確答案：Transit Gateway Multicast Domain 搭配 Nitro 執行個體。

標準情境 — 50 VPC 組織搭配集中出口與 Dev/Prod 隔離

這是 Transit Gateway 與混合雲網路的 SAP-C02 參考情境。請背熟完整架構。

需求

• 50 個 VPC 分佈於 8 個 AWS 帳號，全部在 us-east-1。
• 工作負載分段為 Prod（20 個 VPC）、Dev（20 個 VPC）、Shared Services（1 個 VPC）、Security/Inspection（1 個 VPC）、Egress（1 個 VPC）、DR 預留（7 個 VPC）。
• Prod 和 Dev 必須在網路層完全隔離（稽核需求）。
• Shared Services VPC 向所有 VPC 提供 Active Directory、內部 DNS 和監控。
• 地端資料中心透過最大韌性 Direct Connect 連接，並選擇性以 VPN 作為冷備援。
• 所有對外網際網路流量必須透過單一出口點以支援 SaaS 服務商的 IP 允許清單。
• 所有 VPC 之間的東西向流量必須通過有狀態防火牆稽核（PCI-DSS 要求）。
• 未來需要擴展至 eu-west-1 做 DR；重用此設計。

設計方案

1. 在 us-east-1 部署一個 Transit Gateway，透過 AWS Resource Access Manager（RAM）跨所有 8 個帳號共用。關閉預設路由表關聯和預設傳播——我們將自行明確管理兩者。

2. Transit Gateway 路由表（五張）：

   • rt-prod：Prod VPC attachment 關聯此處。
   • rt-dev：Dev VPC attachment 關聯此處。
   • rt-shared：Shared Services VPC attachment 關聯此處。
   • rt-onprem：Direct Connect Gateway attachment 和 VPN attachment 關聯此處。
   • rt-inspection-egress：Inspection VPC 和 Egress VPC attachment 關聯此處。

3. 傳播矩陣：

   • Prod attachment 傳播至 rt-shared、rt-onprem、rt-inspection-egress。
   • Dev attachment 傳播至 rt-shared、rt-inspection-egress（不傳播至 rt-onprem——稽核禁止地端存取 Dev）。
   • Shared Services attachment 傳播至 rt-prod、rt-dev、rt-onprem。
   • On-prem attachment 將地端 CIDR 傳播至 rt-prod、rt-shared（不傳播至 rt-dev）。
   • Inspection 和 Egress 以靜態路由（非透過傳播）將 0.0.0.0/0 傳入 rt-prod、rt-dev。

4. 集中出口靜態路由：

   • rt-prod 和 rt-dev：0.0.0.0/0 -> Inspection VPC attachment。
   • Inspection VPC 路由表：0.0.0.0/0 -> Egress VPC attachment（串聯稽核再出口），或更簡單的設計中將 Inspection 和 Egress 合為一個 VPC。
   • Egress VPC 的 VPC 路由表：0.0.0.0/0 -> NAT Gateway；返回路徑走 TGW。

5. Appliance Mode：在 Inspection VPC attachment 和 Egress VPC attachment 上啟用——對有狀態流量不可省略。

6. Direct Connect：最大韌性模型。Ashburn 都會區兩個 Direct Connect 機房，每個機房兩條 Dedicated Connection（10 Gbps），每對以 LAG 綑綁。每條連線上的 Transit VIF 終止於單一 Direct Connect Gateway。Direct Connect Gateway 與 us-east-1 Transit Gateway 關聯。所有 VIF 啟用 BFD。另有兩條冷備援 VPN attachment（位於不同 CGW）也附加至 Transit Gateway 並關聯至 rt-onprem，透過調整 BGP MED 讓 DX 優先。

7. Blackhole 路由：在 rt-prod 中為每個 Dev VPC CIDR 新增靜態 Blackhole 路由（縱深防禦）。在 rt-dev 中對稱操作。

8. Shared Services DNS：在 Shared Services VPC 中部署 Route 53 Resolver inbound 和 outbound endpoints。Outbound 透過 Direct Connect 將 corp.example.com 轉發至地端 DNS。Inbound 接受地端對 AWS 私有 Hosted Zone 的查詢。

9. 未來 eu-west-1 DR：在 eu-west-1 部署第二個 Transit Gateway，採用相同的路由表結構。對兩個 Transit Gateway 進行 Peer。將現有的 Direct Connect Gateway 也與 eu-west-1 Transit Gateway 關聯（一個 DX Gateway，兩個 Transit Gateway 關聯——在三關聯限制內）。跨 Region 資料複寫（RDS、S3 CRR）走 Peering。

為何此設計能贏得考試

• 分段在 Transit Gateway 路由表中強制執行——在一處可稽核，獨立於 Security Group。
• 集中出口將 NAT 費用從約 100 個 NAT Gateway 壓縮至約 3 個。
• 搭載 GWLB 的 Inspection VPC 滿足 PCI-DSS 有狀態防火牆要求。
• Appliance Mode 防止非對稱路由造成的事故。
• 最大韌性 Direct Connect 達到 99.99% SLA。
• BFD 提供約 1 秒的切換速度。
• Direct Connect Gateway 無需新光纖即可擴展至第二個 Region。
• Transit Gateway Peering 用於 DR 複寫，無需 VPN。
• RAM 跨 8 個帳號集中管理 Transit Gateway。

決策矩陣 — 選用哪個 Transit Gateway 與混合雲網路原語？

診斷流程 — Transit Gateway 與混合雲網路故障排除

當正式環境的 Transit Gateway 與混合雲網路問題發生時（或 SAP-C02 情境描述連通性故障案例），請按以下順序進行排查。

第一步 — Attachment 是否健康？

查看 Transit Gateway 主控台。每個 attachment 應顯示 available。VPN attachment 若一條隧道 up 一條 down，仍可運作但失去冗餘——修復它，但繼續排查。

第二步 — Attachment 是否與預期的路由表關聯？

Association 是一對一的。與錯誤路由表關聯的 attachment 會讀取到非預期的路由（或沒有路由）。查看每個 Transit Gateway 路由表的「Associations」頁籤。

第三步 — 目的地 CIDR 是否已傳播或以靜態方式存在？

在關聯的路由表中，是否有目的地 CIDR 的條目？若無，則（a）未啟用來自目的地 attachment 的傳播，或（b）需要靜態路由。記住：更具體的前綴優先；同前綴長度時靜態路由優先於傳播路由。

第四步 — 對稱傳播是否存在？

雙向流量需要回程路徑有自己的傳播。來源可以抵達目的地，但目的地的路由表也必須有來源的 CIDR。這是典型的「半通」錯誤。

第五步 — 輻條 VPC 路由表：Transit Gateway 是否為下一跳？

VPC 路由表（不是 Transit Gateway 路由表）必須將目的地 CIDR 送往 Transit Gateway attachment（每個 AZ 的 ENI）。此處缺少路由會導致封包永遠到不了 Transit Gateway。

第六步 — Security Group 與 NACL

來源執行個體的 Security Group 允許對外；目的地允許來自來源 CIDR 的傳入。NACL 是無狀態的——兩個方向都必須允許。這是 CLF-C02 等級的陷阱，但在 SAP-C02 中仍常見。

第七步 — 有狀態設備的 Appliance Mode

若流量通過 Inspection 或 Egress VPC，確認這些 attachment 已啟用 Appliance Mode。非對稱的 AZ 選擇會產生「半通」流量——ICMP 成功但 TCP 握手失敗或隨機中斷。

第八步 — 重疊 CIDR

兩個廣告相同或重疊 CIDR 的 attachment 會造成靜默丟包或無法預期的路由。執行 describe-transit-gateway-route-tables 並檢查。

第九步 — Direct Connect BGP 工作階段

在客戶路由器上執行 show ip bgp summary。工作階段是否為 Established？若卡在 Active 或 Idle，請確認 ASN、MD5 密碼和 VLAN tag。BFD 狀態應為 up。

第十步 — VPC Flow Logs

在來源、目的地和所有中轉子網路上啟用 VPC Flow Logs。篩選 REJECT vs ACCEPT。Security Group 上的 REJECT 會精確顯示哪個封包被丟棄及原因。另外啟用 Transit Gateway Flow Logs（是的，它們獨立存在）以取得端對端可見性。

真實世界的成本與擴展考量

Transit Gateway 與混合雲網路的費用會快速累積。主要費用槓桿：

Transit Gateway 定價組成

• 每小時 Attachment 費用，每個 attachment，每個 AZ（VPC attachment）——us-east-1 每個 attachment-AZ 約 $0.05/小時。
• 每 GB 資料處理費，通過 Transit Gateway 的資料——us-east-1 約 $0.02/GB。
• 跨 Region Peering 資料傳輸——按各 Region 對的每 GB 費率計算。

50 個 VPC attachment 各跨 3 個 AZ，光是 attachment-hours 每月約 $5,400 美元（不含資料處理費）。這是重要的成本考量——對少數 VPC 使用 VPC Peering 或 PrivateLink 而非 Transit Gateway 的設計，可以節省數千美元。

Direct Connect 定價組成

• Dedicated Connection 的埠口時費：依速度計費，US 地點 1 Gbps 約 $0.30/小時，10 Gbps 約 $2.25/小時。
• 透過 Direct Connect 的資料傳出約 $0.02/GB，相較於 us-east-1 網際網路出口約 $0.09/GB——對出口量大的工作負載節省顯著。
• 每月出口量超過約 50 TB 時，Direct Connect 的投資報酬率通常很快達到損益平衡，視速度等級而定。

NAT Gateway 上限

NAT Gateway 上限為 45 Gbps 和每個目的 IP/埠約 55,000 個並發連線。對於推超此上限的集中出口設計，請在出口 VPC 每個 AZ 部署多個 NAT Gateway 並以 ECMP 分流，或改以 Network Load Balancer 後端的 EC2 NAT 設備群取代。

SAP-C02 Transit Gateway 與混合雲網路常見陷阱

整合陷阱清單——以下每一項都曾讓有經驗的考生在 SAP-C02 上栽跟頭。

1. VPC Peering 是非遞移的。 A <-> B、B <-> C 不代表 A <-> C。Transit Gateway 才是答案。
2. Direct Connect 預設不加密。 需補加 MACsec 或在其上跑 IPSec。
3. 每條 Direct Connect 連線限用 1 個 Transit VIF。 請妥善規劃。
4. Direct Connect Gateway 上限 3 個 Transit Gateway 關聯。 需要更多 Region 時改用 Cloud WAN 或多個 DX Gateway。
5. 集中出口和 Inspection VPC attachment 必須啟用 Appliance Mode——缺少此設定會導致有狀態流量故障。
6. 重疊 CIDR 不會自動解決——請使用 PrivateLink 或 Private NAT Gateway。
7. 靜態路由優先於傳播路由（相同前綴長度）——容易意外覆蓋。
8. Transit Gateway Peering 只支援靜態路由——兩個 Transit Gateway 之間沒有 BGP。
9. Site-to-Site VPN 每條隧道上限約 1.25 Gbps——需要更多頻寬請用 ECMP 或 Transit Gateway Connect。
10. BFD 在客戶端預設關閉——你必須在自己的路由器上啟用它，才能獲得次秒級切換。
11. Dev/Test Direct Connect SLA 是 99.9%，不是 99.99%——只有高韌性和最大韌性才能達到 99.99%。
12. Accelerated VPN 需要 Transit Gateway，不支援 Virtual Private Gateway。
13. Transit Gateway Multicast 不跨跨 Region Peering——僅限 Region 內。
14. Route 53 Resolver endpoints 是 Zonal 的——請在 Shared Services VPC 的每個 AZ 各部署一個以確保冗餘。
15. 集中出口節省的前提是 Appliance Mode + 單一出口 VPC——每個 AZ 段各自複製出口設計會抵消節省效果。

常見問題

Q1 — 何時應選 Transit Gateway 而非 VPC Peering？

當你有 2 到 5 個 VPC、拓樸靜態、需要絕對最低延遲（無中轉跳躍），且不預期大幅擴展時，選 VPC Peering。一旦你有 6 個或更多 VPC、跨多個 AWS 帳號、需要遞移路由至地端，或想要集中分段和記錄時，選 Transit Gateway 與混合雲網路。成本損益平衡大約在 10 個 VPC；低於此數，Peering 通常在每月費用上佔優。超過此數，Transit Gateway 的營運簡便性更具壓倒性優勢。

Q2 — Direct Connect Dedicated vs Hosted，如何決定？

從三個維度判斷：頻寬、佈建時間和 VIF 數量。當你需要 1 Gbps、10 Gbps 或 100 Gbps，可等待數週跨接電纜，且需要一個埠口上的多個 VIF（最多 50 個）時，選 Dedicated。當你需要特定頻寬（50 Mbps、200 Mbps、500 Mbps、1 Gbps），希望透過合作夥伴現有基礎設施快速上線，可接受每條 Hosted Connection 一個 VIF，且不需要 LAG 時，選 Hosted。SAP-C02 情境中說「需要下週上線」的，幾乎都指向 Hosted Connection 或 Site-to-Site VPN，而非 Dedicated。

Q3 — 我的 Transit Gateway 與混合雲網路設計是否需要到處啟用 Appliance Mode？

不需要——只需在 Transit Gateway attachment 的輻條 VPC 中含有必須看到流量雙向的有狀態設備時才啟用。也就是 Inspection VPC attachment（防火牆、IDS）、集中出口 VPC attachment（NAT Gateway 對新連線是有狀態的），以及任何第三方負載平衡設備 VPC attachment。一般工作負載 VPC（應用程式伺服器、資料庫）不需要 Appliance Mode。不必要地啟用 Appliance Mode 會將流量流鎖定在單一 AZ 的 Transit Gateway ENI 上，降低跨 AZ 負載分散——因此請謹慎使用。

Q4 — 在合併情境中，如何在不重新規劃 IP 的情況下處理重疊 CIDR？

依據被收購公司的應用程式重要性排序。對於少數需要跨越重疊區域的特定服務，透過 AWS PrivateLink 發布每個服務——該服務在消費端 VPC 中以本地唯一 IP 呈現為 Endpoint，因此 CIDR 重疊與否不重要。對於更廣泛的連通性需求，部署一個含有 Private NAT Gateway 的橋接 VPC，將重疊的來源和目的地 CIDR 轉換為唯一的代理範圍；透過橋接 VPC 和 Transit Gateway 在雙方之間路由。長期規劃 IP 重新規劃遷移，通常逐一應用程式處理，搭配 DNS 切換和每個應用程式的短暫維護窗口。

Q5 — Direct Connect Gateway 和 Transit Gateway 有什麼不同——我兩個都需要嗎？

兩者解決不同的問題，在多 Region Transit Gateway 與混合雲網路設計中通常兩者都需要。Direct Connect Gateway 是全域匯聚器，讓單一 Direct Connect 連線能跨多個 AWS Region 抵達 Virtual Private Gateway 或 Transit Gateway。它不是資料平面中樞——它純粹為了在 Region 間多路復用混合流量而存在。Transit Gateway 是Region 級資料平面中樞，在單一 Region 內連接 VPC、VPN、Direct Connect Gateway、其他 Transit Gateway 和 Connect peer。在標準多 Region 設計中，Direct Connect 連接到 Direct Connect Gateway，Direct Connect Gateway 與每個 Region 各一個 Transit Gateway 關聯。

Q6 — Transit Gateway 與混合雲網路如何整合 DNS？

在 Shared Services VPC 中放置 Route 53 Resolver inbound 和 outbound endpoints。Outbound endpoints 透過 Direct Connect 或 VPN 路徑將特定網域（corp.example.com）轉發至地端 DNS 伺服器——地端 DNS 伺服器接收到的查詢就如同來自 Shared Services VPC 的 ENI。Inbound endpoints 讓地端 DNS 伺服器可以將 AWS 私有 Hosted Zone 查詢轉發至 VPC。結合透過 RAM 跨所有工作負載 VPC 共享的 Route 53 Resolver 規則，在整個 Transit Gateway 與混合雲網路架構中創造無縫的混合 DNS 體驗——地端名稱和 AWS 私有名稱隨處可解析，且不會產生轉發迴圈。

Q7 — 我可以使用 Transit Gateway 對地端資料中心執行 Multicast 嗎？

不可以。Transit Gateway Multicast 是 Region 本地且僅限 VPC。Multicast 封包不會穿越 VPN attachment、Direct Connect attachment 或跨 Region Peering。若需要地端至 AWS 的 Multicast，你需要在自己的路由器或 SD-WAN 設備上執行具有 Multicast 感知能力的 Overlay（PIM 型），而非使用原生 Transit Gateway Multicast。若 SAP-C02 題目包含「Multicast 至地端」，答案通常是「原生不支援——請使用 Overlay」或「透過 Transit Gateway Connect 使用第三方 SD-WAN 設備」。

Q8 — 如何最小化大型 Transit Gateway 與混合雲網路部署的每月成本？

四個槓桿，依影響力排序。第一，集中出口——單一集中出口 VPC 通常能將每月 NAT Gateway 時費和處理費比每 VPC NAT 的模式壓縮 80% 以上。第二，對跨帳號服務存取適時採用 PrivateLink——PrivateLink 流量按 endpoint 費率計費，有時完全避免 Transit Gateway 資料處理費。第三，將出口量大的工作負載推到 Direct Connect 上——每 GB 費率約為網際網路出口費率的四分之一，每月出口量超過約 50 TB 時很快就能回本。第四，稽核 Transit Gateway attachment——未使用的 attachment 仍然計費；退役的 attachment 請及時解除。

Q9 — 何時應選 AWS Cloud WAN 而非 Transit Gateway 做混合雲網路？

當你的 Transit Gateway 與混合雲網路架構跨越許多 Region（五個或更多）、你希望用單一政策文件描述全球分段而非手動串聯 Transit Gateway Peering 和每 Region 路由表，且你需要與 SD-WAN 合作夥伴和全球路由屬性原生整合時，Cloud WAN 是正確選擇。Cloud WAN 內部使用 Transit Gateway，但以全域網路物件抽象化它們。對於小型（一或兩個 Region）部署，直接使用 Transit Gateway 仍然更簡單且更便宜。對於 2026 年代的多 Region 企業，Cloud WAN 越來越成為預設選擇。

Q10 — SiteLink 能取代我的 MPLS 供應商嗎？如何估算頻寬？

當兩個站點都已有 Direct Connect 或可以採購時，SiteLink 可以取代 MPLS 做站點間連通性。它透過 AWS 全球骨幹傳輸站點間流量——通常比公共網際網路路徑延遲更低且更穩定，在相同頻寬下通常比傳統 Tier-1 MPLS 便宜。以 95 百分位測量目前的 MPLS 使用量來估算 SiteLink 頻寬需求，然後在每個站點佈建能覆蓋該使用量加預留空間的 Direct Connect 頻寬。SiteLink 定價為每個啟用 VIF 的固定每小時費用加資料傳輸費；與你的 MPLS 每月固定費用相比，多站點企業通常可以看到 30-60% 的節省。在驗證 SiteLink 能承受尖峰負載之前，保留一條備用路徑（傳統 ISP 或小型 MPLS 電路）。

Transit Gateway 與混合雲網路最終備考清單

在參加 SAP-C02 之前，確認你能從記憶中完成以下每一項：

• 說出全部六種 Transit Gateway attachment 類型，以及每種的一個區別性限制。
• 繪製 Prod/Dev/Shared/On-prem 分段的 Association-vs-Propagation 矩陣。
• 背誦三種 Direct Connect 韌性模型及其精確 SLA。
• 解釋為何集中出口和 Inspection VPC 必須啟用 Appliance Mode。
• 列出重疊 CIDR 的三種修復模式，依優先順序排列。
• 繪製「50 VPC + 集中出口 + Inspection」標準設計圖。
• 區分 Direct Connect Gateway（全域匯聚器）與 Transit Gateway（Region 級中樞）。
• 解釋何時使用 Accelerated VPN、Transit Gateway Connect 和 SiteLink。
• 在五個排查步驟內診斷非對稱路由錯誤。
• 估算 50 個 VPC 在集中出口與每 VPC NAT 之間的費用差距。

若以上每一項都了然於胸，SAP-C02 上的 Transit Gateway 與混合雲網路題目將感覺像是模式辨識，而非問題解決——這正是 Pro 深度必須達到的熟練程度。