AWS Certified Advanced Networking — Specialty (ANS-C01) 考試的網域 3.3 要求考生對 EC2 網路效能內核具備極高的熟悉度，這是其他任何 AWS 認證所不要求的。你必須了解哪些執行個體類型支援哪一代網路介面、HPC 工作負載何時需要 EFA 而非 ENA、為什麼規範化的 9001 位元組巨型框架 (Jumbo frames) 在 VPC 內部運作良好但在網際網路閘道 (IGW) 處會失效、置放群組 (Placement group) 實際上限制了什麼，以及許多實務限制 — 單一串流上限、基準 vs 突發頻寬、PMTUD 黑洞以及 CPU 固定 (CPU-pinning) 陷阱 — 這些都解釋了為什麼實測吞吐量通常只有行銷文案承諾的一半。本主題將全面梳理整個效能堆疊，並重點關注 Specialty 考試中最常出現的陷阱情境。
我們涵蓋了四代 EC2 網路介面 (vNIC、ENI、ENA、EFA)；EFA 搭配 SRD 傳輸協議與 libfabric 函式庫使用的作業系統繞過 (OS-bypass) 模式；三種置放群組類型 (叢集、分割、分散) 及其隔離機制；跨越 VPC 對等連接、IGW、VPN 與 Direct Connect 的精確巨型框架故事；每個網路工程師終將遇到的路徑 MTU 偵測 (PMTUD) 黑洞問題；以及考試熱衷測試的單一串流與多串流頻寬區別。自始至終，焦點都集中在考試情境可能測試的配置選擇，以及驗證為何某個選擇是正確的，而另外三個看起來很像的選項則是錯誤的。
為什麼網路效能是 ANS-C01 的一等公民主題
ANS-C01 任務 3.3 為「針對效能、可靠性和成本效益優化 AWS 網路」，其技能點明確指出了「選擇合適的網路介面以獲得最佳效能 (例如：彈性網路介面、Elastic Network Adapter [ENA]、Elastic Fabric Adapter [EFA])」以及「在不同連線類型中配置巨型框架支援」。單單這兩個技能點就會產生 3 到 5 個考試題目 — 而且這些題目並不抽象。考試會編寫一段 200 字的情境，描述一個數值模擬叢集需要在 64 個節點間具備緊密的 All-reduce 效能，詢問應使用哪種網路配置，並提供四個表面上看起來很像的答案：c5n.18xlarge 上的 ENA 搭配叢集置放群組；c5n.18xlarge 上的 EFA 搭配叢集置放群組；m5.large 上的 EFA 搭配叢集置放群組；hpc6a.48xlarge 上的 ENA 搭配分割置放群組。這其中有三個答案會因為具體、可知的理由而錯誤。
任務 3.3 的另一半考點是巨型框架 (Jumbo frames)。9001 MTU 是 VPC 內部的預設值，但一旦封包跨越網際網路閘道 (IGW)、Site-to-Site VPN 或未經配置的 Direct Connect，路徑 MTU 就會降至 1500 (VPN 則為 1438) — 如果應用程式或核心未正確處理 PMTUD，大型封包將被靜默丟棄。ANS-C01 將此框架化為：「兩個特定端點間的 TCP 吞吐量意外偏低；最可能的原因是什麼？」正確答案通常是 PMTUD 失敗，隱藏在 MSS 鉗制 (Clamping)、停用 SACK 以及未啟用巨型框架等干擾項中。了解哪個邊界保留巨型框架、哪個會截斷，是一項回報率極高的記憶任務。
白話文解釋 EC2 網路效能 — ENA、EFA、巨型框架
效能堆疊是分層的：NIC 硬體 (ENA vs EFA) → 物理位置約束 (置放群組) → 框架大小選擇 (MTU 1500 vs 9001) → 吞吐量形態 (單一串流 vs 多串流)。以下三個類比有助於理解其結構。
類比一：物流倉庫
將 EC2 執行個體想像成一個配送倉庫。ENI 是普通裝卸貨位，配備標準尺寸的貨車位 (1 Gbps 管道上的 1500 位元組框架)。ENA 是同一個倉庫的升級版多貨位裝卸台 — 貨車一樣，但並行的貨位更多，且位於更寬的道路上 (10/25/100 Gbps)，具備電子調度 (SR-IOV) 功能，因此貨車無需排隊。EFA 是建在倉庫旁的專用貨運鐵路終端 — 完全繞過公共道路 (作業系統繞過)，在自己的軌道上運行 (SRD 協議)，僅在你擁有能從鐵路獲益的特定貨物類型 (HPC MPI/NCCL) 時才有用。巨型框架是雙倍長度的 18 輪大貨車，而非標準的 12 英尺貨車 — 每次運輸量是後者的六倍，但僅限在 AWS VPC 內部的高速公路上合法行駛；一旦進入公共道路網絡 (IGW、VPN、網際網路)，它們必須在裝卸台分解成標準貨車 (分段) 或被拒絕通行 (PMTUD 黑洞)。叢集置放群組是一項規則，要求你所有的倉庫必須位於同一個園區 (同一個物理機架，同一個網路主幹)，這樣鐵路貨運和高效率的裝卸台對接才成為可能。分散置放群組則是相反的規則，要求任何兩個倉庫不得共用同一個園區 — 保證一個園區發生火災不會同時摧毀兩個倉庫。
類比二：手術室
醫院的手術室網路是微縮版的 EC2 網路堆疊。ENI 是通往其他部門的標準醫院電話線。ENA 是具備多個並行頻道且更清晰的升級版纖維對講機。EFA 是外科醫生間的直連熱線，完全繞過交換機，僅在兩位醫生協同操作同一位病人 (HPC 緊密耦合任務) 時使用。SRD 是熱線使用的特定協議 — 支援亂序交付並在應用層重組，延遲比順序交付的 TCP 更低。巨型框架是同一醫院側翼相鄰手術室之間的大宗設備運輸 — 當走廊寬敞 (VPC 內部) 時效率極高，但當包裹必須通過前門安檢前往另一家醫院 (IGW 邊界) 時則無法通行。置放群組是排程規則：叢集 = 同一翼、同一層 (低延遲)；分散 = 不同建築 (故障隔離)；分割 = 按區段分組 (機架級隔離)。
類比三：賽車場
EC2 執行個體是一輛賽車。ENI 是量產版引擎。ENA 是具備多個進氣門 (SR-IOV 隊列) 和直接噴射 (Nitro 卡分載) 的原廠調教高效能引擎。EFA 是一級方程式 (F1) 賽車引擎 — 為 HPC 競賽條件量身定制，需要特殊燃料 (libfabric 執行環境)，僅限在專用賽道 (叢集置放群組) 上行駛，且不適合日常駕駛。叢集置放群組是規則，要求所有賽車從同一個維修道出發，以便獲得最低的賽車間延遲。分割置放群組是規則，確保沒有兩輛賽車共用同一個燃料槽 — 一個燃料管事故只會影響一部分賽車。分散置放群組是規則，賽車在不同日子停在不同的車庫，這是最強的故障隔離保證，但沒有延遲優勢。巨型框架是更寬的輪胎，在賽道內 (VPC 內部) 提供更強的抓地力，但賽車不能穿著它們離開賽道 (跨 IGW，MTU 截斷)。
對於 HPC 與緊密耦合的分散式訓練問題，賽車場 + F1 引擎心理模型能清晰地捕捉 EFA 的特徵。對於多區域複寫與大型物件傳輸，物流倉庫 + 巨型貨車模型對應 MTU 9001 vs 1500 的權衡。對於高可用性 (HA) 與容錯情境，賽車場置放群組模型 (同維修道 vs 不同車庫) 能精確對應叢集與分散。參考資料：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html
EC2 網路介面世代：ENI、ENA、EFA
EC2 已經歷了四代網路介面；考試期望你識別其中的差異並正確選擇。
vNIC (舊版半虛擬化)
原始基於 Xen 的虛擬 NIC。每個執行個體的最高吞吐量約為 1 Gbps。見於 m1, m2, c1, t1, m3 (部分), c3 (部分), r3 (部分)。在 2026 年的考試中，vNIC 不會作為正確答案出現 — 這些執行個體系列已過時。
ENI (彈性網路介面)
VPC 抽象層中的標準虛擬網路介面。一個 ENI 具有主要 IP、選用的次要 IP、MAC 地址、安全性群組、來源/目的地檢查設定，且可以從一個執行個體分離並重新附加到另一個。ENI 是一種抽象 — 每個運行的 EC2 執行個體至少有一個 ENI。效能特性取決於執行個體的底層硬體。
ENA (Elastic Network Adapter)
ENA 是在支援 SR-IOV (單一根 I/O 虛擬化) 的 Nitro 和 pre-Nitro 執行個體上運行的增強型網路驅動程式。與 vNIC 相比，ENA 提供更高的 PPS (每秒封包數)、更低的抖動以及更低的延遲。它是所有現代執行個體類型的預設選項：c5/c5n/c6i/c6in/c7i/c7g, m5/m5n/m6i/m7i/m7g, r5/r5n/r6i/r7i, p3/p4/p5, hpc6a/hpc7a 等等。ENA 頻寬隨執行個體大小擴展：c5.large 最高可達 10 Gbps 突發 (基準頻寬低得多)，c5n.18xlarge 可達 100 Gbps，c6in.metal 可達 200 Gbps，而 p5.48xlarge 通往 GPU NIC 的頻寬可達 3200 Gbps。
現代核心 (Amazon Linux, Ubuntu 18.04+, RHEL 7.5+) 已內建 Linux ENA 驅動程式；對於較舊的作業系統，你可能需要從 kernel.org 安裝 ena 模組。可透過 ethtool -i eth0 並尋找 driver: ena 來驗證。
EFA (Elastic Fabric Adapter)
EFA 是 ENA 的超集，增加了用於 HPC 的作業系統繞過 (OS-bypass) 傳輸模式。EFA 在執行個體上同時呈現為 ena 介面 (用於正常 TCP/IP) 與 efa 介面 (用於使用 AWS Scalable Reliable Datagram (SRD) 協議的繞過模式傳輸)。HPC 函式庫 — libfabric、MPI 實作 (Intel MPI, Open MPI, MPICH, MVAPICH)、NCCL (NVIDIA 集體通訊函式庫) — 連結到 libfabric 並使用 EFA 繞過路徑進行節點間的 MPI/集體通訊，實現比 TCP 更低的延遲與更高的 All-reduce 吞吐量。
EFA 不是 ENA 的無縫替代品 — 應用程式必須顯式使用 libfabric 或相容的執行環境。標準 TCP/IP 應用程式無法從附加 EFA 中獲得任何好處；它們會繼續使用 ENA 介面。EFA 透過在啟動執行個體時附加具備 EFA 能力的 ENI 來啟用，僅支援特定執行個體類型：c5n.18xlarge/9xlarge, c6in.32xlarge/16xlarge, m5n/m5dn (部分大小), r5n (部分), p3dn.24xlarge, p4d.24xlarge, p5.48xlarge, hpc6a.48xlarge, hpc7a, hpc7g 以及少數其他類型。在考試中推薦 EFA 前，請務必查閱官方 EFA 支援列表。
SRD (Scalable Reliable Datagram)
SRD 是 EFA 繞過路徑底層的 AWS 客製化傳輸協議。與 TCP 相比，SRD：(a) 支援亂序交付並在應用/函式庫層進行重組，消除了前頭阻塞 (Head-of-line blocking)；(b) 同時使用多個 AWS 內部路徑進行多路徑路由，對不同流量進行不同的雜湊以分散負載；(c) 對於緊密耦合的 HPC 工作負載，具備比 TCP 更低的延遲。SRD 對應用程式是不可見的 — 它們看到的是 libfabric API；SRD 是底層的線路格式。使用案例包括 HPC MPI All-reduce、分散式深度學習梯度同步以及某些即時模擬協議。
一個常見的 ANS-C01 干擾項：「我們為所有 64 個節點附加了 EFA，但吞吐量沒有提升」。答案是應用程式正在使用標準 TCP — 它看到的是 ENA 介面，而不是 EFA 繞過路徑。只有當應用程式針對 libfabric (或使用 libfabric 的執行環境，如 Intel MPI, Open MPI, NCCL) 構建時，EFA 才會發揮作用。對於純 TCP 工作負載 — 網頁伺服器、資料庫、S3 傳輸 — EFA 沒有任何好處；正確答案應是在 ENA 頻寬、多串流並行與執行個體大小上進行優化。參考資料：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html
置放群組：叢集、分割、分散
置放群組 (Placement group) 是對單一可用區域 (AZ) 內 EC2 執行個體物理位置的邏輯約束。分為三種類型，每種優化不同的目標。
叢集置放群組 (Cluster placement group)
叢集置放群組中的所有執行個體都放置在單一 AZ 內的同一個物理機架與同一個網路主幹 (Spine) 上。結果：獲得最低的執行個體間延遲 (亞微秒級來回時間)、最高的執行個體間頻寬 (完整的執行個體 NIC 頻寬，在 c6in/c7i 上高達 100+ Gbps，在 p5 上高達 3200 Gbps)。這是 HPC 與 EFA 工作負載的必要條件 — EFA 的緊密耦合優勢只有在節點位於同一個主幹上時才能體現。
限制：容量取決於機架，因此啟動大型叢集置放群組可能會遇到「InsufficientCapacity」錯誤；建議在單次 API 呼叫中使用相同的 AMI 與執行個體類型啟動所有執行個體，並避免停止/啟動，因為這可能會將執行個體重新放置到不同的機架。
分割置放群組 (Partition placement group)
執行個體被劃分為邏輯分割 (每個 AZ 最多 7 個，可配置)，每個分割位於獨立的底層硬體 (不同的機架、不同的網路主幹) 上。分割內的所有執行個體共享機架級命運 (一個機架故障會導致它們全部宕機)；不同分割間的執行個體則是隔離的。用於分散式資料庫 (Cassandra, HDFS, Kafka)，資料跨分割複寫，應用程式可以容忍單一分割故障。應用程式透過 partition_number 啟動參數控制分割分配。
分散置放群組 (Spread placement group)
執行個體放置在不同的底層硬體上，沒有兩個執行個體共用同一個機架。每個 AZ 最多 7 個執行個體。用於對高可用性要求極高的工作負載，確保每個執行個體都位於自己的機架上 (小規模叢集、控制平面組件)。這是最強的故障隔離保證，但規模最小且沒有延遲優勢。
置放群組與 AZ 行為
置放群組的作用範圍是 AZ — 叢集置放群組定義上是單一 AZ 的。對於跨 AZ 的 HPC，你在每個 AZ 啟動一個叢集置放群組；跨 AZ 流量使用正常的 VPC 路由 (伴隨約 1ms 的跨 AZ 延遲代價，而非亞微秒級)。對於無延遲要求的多 AZ 高可用性，在每個 AZ 使用分散置放群組。
- ENI：VPC 中虛擬網路介面的抽象 (每個執行個體至少有一個)。
- ENA：使用 SR-IOV 的增強型網路驅動程式；現代預設選項。
- EFA：ENA 的超集，透過 libfabric 與 SRD 實現作業系統繞過；HPC 專用。
- SR-IOV：單一根 I/O 虛擬化，硬體級 NIC 共享。
- SRD：AWS Scalable Reliable Datagram，EFA 的線路傳輸協議。
- libfabric：開源 HPC 織網 API；使用 EFA 繞過路徑所必需。
- MPI：訊息傳遞介面 (Message Passing Interface)；HPC 並行程式設計執行環境。
- NCCL：NVIDIA 集體通訊函式庫；針對 GPU All-reduce 優化。
- 叢集置放群組：同機架/主幹，最低延遲，EFA 必備。
- 分割置放群組：每個分割獨立機架，最多 7 個，分散式資料庫模式。
- 分散置放群組：每個執行個體獨立機架，每個 AZ 最多 7 個，關鍵 HA 專用。
- 參考資料：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
巨型框架：MTU 9001 與其生存邊界
巨型框架 (Jumbo frame) 是大於標準 1500 位元組 MTU 的乙太網路框架。AWS 在 VPC 內部支援 9001 位元組 (MTU 9001) 的巨型框架，但僅限於特定的路徑類型。跨越錯誤的邊界會導致封包被分段 (變慢，有時會被中間防火牆封鎖) 或被靜默丟棄 (PMTUD 黑洞)。
MTU 9001 運作的場景
- 在同一個 VPC 內部 — 位於同一個子網路的執行個體，或透過 VPC 路由表在 VPC 內部路由的流量，原生支援 9001 位元組框架。
- VPC 對等連接 — 根據 2018 年的更新，同區域與跨區域對等連接均支援 9001 位元組框架。請透過 VPC 對等連接的
enable jumbo frames屬性 (現為預設值) 驗證。 - Transit Gateway VPC 連接 — 在連接的 VPC 之間支援 9001。
- Direct Connect — 如果 Direct Connect 連線已啟用巨型框架 (連線端可配置；兩端必須一致)，則支援 9001。
- 叢集置放群組流量 — 9001 是標準配置。
MTU 9001 不運作的場景
- 網際網路閘道 (IGW) — 穿過 IGW 的框架限制為 1500 位元組。更大的框架會被丟棄 (IGW 不進行分段)。
- Site-to-Site VPN — IPsec 隧道封裝開銷意味著有效的內部 MTU 約為 1438 位元組 (隨加密演算法變化)；更大的框架必須分段或丟棄。
- NAT 閘道 — 穿過 NAT 閘道傳向網際網路的框架限制為 1500 位元組。
- Direct Connect 上的 VPN (透過公有/傳輸 VIF 的 VPN) — 即使在啟用了巨型框架的 DX 連線上，IPsec 開銷也會使有效 MTU 降至 1438。
- 跨區域 VPC 對等連接 — 對於跨越區域邊界的流量，最高僅支援 1500 位元組 (區域內流量為 9001)。
PMTUD 與黑洞問題
路徑 MTU 偵測 (PMTUD) 是 TCP 端點用來發現兩端之間路徑上最小 MTU 的機制。當路由器因為下一跳 MTU 更小且 IPv4 「不分段」(DF) 位元已設定而無法轉發封包時，路由器會發回一個 ICMP Type 3 Code 4 (「需要分段但設定了 DF 位元」) 回應，要求發送端縮小封包。發送端的 TCP 堆疊會據此調降 TCP MSS 並重傳。
PMTUD 黑洞發生在 ICMP Type 3 Code 4 訊息被靜默丟棄時 — 可能是因為過於嚴格的防火牆、不允許 ICMP 的安全性群組或封鎖 ICMP 的客戶端網路防火牆。發送端繼續發送 9001 位元組的封包，路徑將其丟棄，沒有 ICMP 回饋，TCP 反覆重傳同樣巨大的封包直到連線逾時。從應用程式角度看，小封包 (控制訊息) 運作正常；大封包 (資料、檔案傳輸) 則會卡住。
解決方案：在傳出設備上進行 TCP MSS 鉗制 (Clamping)，攔截 TCP SYN 封包並將 MSS 選項重寫為已知的安全值 (例如為 VPN 設定 1380 位元組，以考慮 IPsec 開銷)。大多數現代客戶端閘道設備都支援 MSS 鉗制。AWS Site-to-Site VPN 會為 IPsec 隧道自動執行 MSS 鉗制；在開啟巨型框架的 Direct Connect 上，客戶端路由器必須為任何流向非巨型路徑的流量鉗制 MSS。
ANS-C01 中最常考的巨型框架陷阱：情境描述啟用了巨型框架的 EC2 執行個體與外部 SaaS 端點間透過網際網路進行高吞吐量 TCP 傳輸，但吞吐量遠低於預期。原因在於 IGW 丟棄了 9001 位元組框架；路徑上某處過濾了 PMTUD ICMP；應用程式陷入黑洞。解決方法是停用傳出介面上的巨型框架、配置 MSS 鉗制，或者接受所有穿過 IGW 的流量使用 1500 MTU。在 VPC 內部，巨型框架暢行無阻；一旦跨越 IGW，巨型框架必死無疑。參考資料：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html
單一串流 vs 多串流頻寬
一個微妙的考試陷阱：執行個體頻寬通常是以彙總值宣傳的 (例如「c5n.18xlarge 具備 100 Gbps」)，但受限於底層 Nitro Hypervisor 的每流量流表項以及 TCP 連線發送/確認視窗的內在串行化，單個 TCP 串流 (Flow) 的上限要小得多。
單一串流上限
- 同一個 AZ、同一個置放群組內：標準 ENA 上單個 TCP 串流通常限制在 10 Gbps。配合叢集置放群組與完整執行個體頻寬，對於超大型執行個體，單一串流可接近 25 Gbps，但很少超過。
- 跨 AZ (區域內)：標準 ENA 上單個 TCP 串流通常限制在 5 Gbps。
- 採用 SRD 的 EFA 可以將單個應用程式串流分發到多個內部路徑上，有效繞過單一串流 TCP 上限 — 這也是 EFA 對 HPC 如此重要的原因之一。
多串流擴展
要利用完整的執行個體頻寬，應用程式必須開啟多個並行串流 — 例如，使用 10 個並行 TCP 連線，每個連線承載部分資料。像 iperf3 -P 10 這樣的工具可以驗證這一點。S3 分段上傳預設使用並行的 HTTP 連線。另一方面，資料庫複寫通常在單個連線上運行，容易碰到單一串流上限。
設計啟示
- 叢集置放群組 + EFA + libfabric 用於 HPC All-reduce — 完全繞過 TCP。
- 使用多個並行 TCP 連線進行大宗資料傳輸 (S3, 複寫, EBS 快照複製)。
- 選擇更大的執行個體類型以獲得更高的每串流上限 — c6in.32xlarge 的單一串流上限高於 c6i.large。
- 對頻寬關鍵路徑避免跨 AZ — 跨 AZ 單一串流會降至 5 Gbps。
Direct Connect 與框架大小
Direct Connect 專用連線支援在每個虛擬介面 (VIF) 配置 1500 或 9001 MTU。該設定是按 VIF 進行的，且 AWS 端與在地路由器端必須匹配。在 DX 上使用巨型框架可顯著提升大宗傳輸的吞吐量 — 例如從在地到 S3 的 EBS 快照複製、大型物件上傳以及私有網路上的資料庫複寫。
啟用方法：在建立 VIF 時將 MTU 設定為 9001 (預設為 1500)；在在地路由器上，將 L2 鏈路 MTU 配置為 9001 (或更高，以考慮 VLAN 標籤開銷 — 物理介面上通常為 9100)。在地路徑中所有中間交換機也必須支援巨型框架 — 路徑中只要有一個 1500 MTU 的交換機就會導致與 IGW 邊界同樣的 PMTUD 黑洞。
通往多個 Transit Gateway 的 Direct Connect Gateway (DXGW) 路徑在 AWS 內部段支援 8500 位元組 MTU；面向客戶的 VIF 可以是 9001，但流向 TGW 連接的 VPC 的流量上限為 8500。這個細微的限制是 ANS-C01 中最深層的巨型框架區分點之一。
- 巨型 MTU (Jumbo MTU)：VPC 內部、VPC 對等連接、TGW VPC 連接、Direct Connect (若啟用) 上為 9001 位元組。
- DXGW 到 TGW 路徑：最大 8500 MTU (低於 9001)。
- IGW MTU：1500 位元組；巨型框架會被丟棄。
- Site-to-Site VPN 有效 MTU：1438 (扣除 IPsec 開銷後)。
- NAT 閘道 MTU：傳向網際網路時為 1500。
- 同 AZ 同 PG 的單個 TCP 串流上限：約 10 Gbps (標準 ENA)。
- 跨 AZ 單個 TCP 串流上限：約 5 Gbps。
- EFA + SRD：多路徑化的單一應用程式串流；僅 HPC 獲益。
- 叢集置放群組 (Cluster PG)：單一 AZ、同機架/主幹、最低延遲。
- 分割置放群組 (Partition PG)：每個 AZ 最多 7 個分割，分割間機架隔離。
- 分散置放群組 (Spread PG)：每個 AZ 最多 7 個執行個體，每個執行個體獨立機架。
- 支援 EFA 的執行個體：c5n.18xl, c6in.32xl, m5n/m5dn (部分), p3dn.24xl, p4d.24xl, p5.48xl, hpc6a.48xl, hpc7a, hpc7g — 考前請核對列表。
- PMTUD ICMP：Type 3 Code 4 (「需要分段且 DF 已設定」)；被封鎖 = 黑洞。
- MSS 鉗制：在 SYN 中重寫 TCP MSS 選項為安全值；PMTUD 黑洞的緩解措施。
- 參考資料：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html
效能模式：HPC 叢集、大宗傳輸、分散式資料庫
HPC 緊密耦合叢集
需求：最低的節節點間延遲、最高的 All-reduce 頻寬，通常彙總頻寬需達每秒數百 GB。解決方案：從支援 EFA 的列表中選擇執行個體類型 (通常是 hpc6a.48xlarge, hpc7a, c6in.32xlarge, 或用於 GPU 的 p5.48xlarge)；附加具備 EFA 能力的 ENI；放置在單一 AZ 的叢集置放群組中；使用針對 libfabric 編譯的 MPI (Open MPI, Intel MPI) 或 NCCL (用於 GPU)；確保 9001 MTU；關閉 CPU C-states 並配置 NUMA 感知放置以獲得可預測的延遲。這是規範化的 HPC 架構。
到 S3 的大宗資料傳輸
需求：區域內從 EC2 到 S3 的最大吞吐量。解決方案：使用具備並行分段的 S3 分段上傳 (Multipart upload) (AWS CLI 預設為 8 個並行上傳，可透過 aws configure set default.s3.max_concurrent_requests 100 配置)；跨區域使用 加速傳輸 (Transfer Acceleration) (基於 CloudFront)；使用 S3 閘道端點 以避免 NAT 閘道資料處理費並保留在 AWS 骨幹網 (免費)；選擇具備足夠頻寬供多串流並行的執行個體類型 (通常為 c6in.4xlarge 或更大)。
分散式資料庫 (Cassandra, HDFS, Kafka)
需求：跨機架複寫以實現故障隔離，網路可預測以控制複寫延遲。解決方案：使用分割置放群組，每個 Cassandra 節點環或 HDFS 機架對應一個分割；執行個體大小需足夠支撐單一串流上限 (單連線複寫可能是瓶頸)；叢集內使用巨型框架以提升複寫效率；在 CloudWatch 中監控每執行個體的 NetworkOut 與複寫延遲指標。
跨區域複寫 (DR)
需求：具備合理成本且高效地跨 AWS 區域進行大宗資料傳輸。解決方案：使用 跨區域 VPC 對等連接 (邊界處雖然限制為 1500 MTU，但開銷極小)；使用 AWS 骨幹網 路徑 (資料傳輸定價優於網際網路)；對於極大量的每日傳輸，考慮使用 AWS DataSync 或針對一次性遷移使用 AWS Snowcone/Snowball。
一個常見的 ANS-C01 干擾項模式：將叢集 PG 與 EFA 拆開。考試會提供「m5.large 上的 EFA 搭配叢集 PG」或「hpc6a 上的 ENA 搭配叢集 PG」作為干擾項。正確答案幾乎總是結合了：(a) 支援 EFA 的執行個體類型、(b) 附加了 EFA 能力的 ENI、(c) 叢集置放群組、(d) 使用 libfabric 的應用程式 (MPI/NCCL)。缺少任何一項都會導致效能低於優化值，因而成為錯誤答案。參考資料：https://aws.amazon.com/hpc/efa/
常見陷阱總結 — 網域 3.3
考試在網路效能方面最常編寫的陷阱。
陷阱 1：EFA 提升所有網路效能
錯。只有當應用程式使用 libfabric (MPI, NCCL) 時，EFA 才會產生效益。標準 TCP 應用程式將繼續使用 ENA 介面，看不到任何好處。
陷阱 2：巨型框架在 AWS 任何地方都有效
錯。巨型框架 (9001) 僅在 VPC 內部、跨 VPC 對等連接、TGW 連接、Direct Connect (若啟用) 上有效。巨型框架無法跨越 IGW (1500)、VPN (1438)、NAT 閘道 (1500) 或 DXGW 到 TGW 路徑 (8500 上限)。
陷阱 3：單個 TCP 串流可以使用完整的執行個體頻寬
錯。標準 ENA 上單個 TCP 串流限制在同 AZ 約 10 Gbps，跨 AZ 約 5 Gbps。要達到全速，必須使用多串流並行。
陷阱 4：叢集置放群組跨越多個 AZ
錯。叢集 PG 定義上是單一 AZ 的。對於多 AZ 的 HPC，應在每個 AZ 使用一個叢集 PG，並接受跨 AZ 流量的延遲。
陷阱 5：分散置放群組可以包含無限多執行個體
錯。分散 PG 在每個 AZ 限制為 7 個執行個體。對於更大規模的分散，請使用多個分散 PG 或分割 PG。
陷阱 6：現代 AMI 需要特殊設定才能使用 ENA
錯。ENA 驅動程式已內建於現代 Linux 核心 (Amazon Linux, Ubuntu 18.04+, RHEL 7.5+)。只有舊版 AMI 才需要顯式安裝驅動程式。
陷阱 7：啟用巨型框架會自動提升吞吐量
錯。如果 PMTUD 無法端到端運作，或者應用程式產生的寫入操作不夠大，巨型框架可能毫無幫助，甚至因黑洞丟包導致連線中斷。務必在部署前測試。
陷阱 8：EFA 是免費且常開的
錯。EFA 作為功能是免費的 (無額外小時費)，但它是啟動執行個體時手動選用的，且僅適用於特定的執行個體類型。
陷阱 9：只要允許了 ICMP，PMTUD 就一定能運作
錯。PMTUD 需要特定的 ICMP Type 3 Code 4 訊息能夠穿過整個回程路徑。許多客戶端防火牆完全封鎖 ICMP 或封鎖特定子類型，導致 PMTUD 靜默失效。
陷阱 10：叢集 PG 保證在同一個物理機器上
錯。叢集 PG 將執行個體放置在同一個機架與主幹上，但它們位於不同的主機上。雖然延遲效益在亞微秒級，但執行個體並不共享核心或硬體。
陷阱 11：SRD 透過 Socket API 暴露給應用程式
錯。SRD 是 libfabric 下方的線路傳輸。應用程式使用的是 libfabric API；SRD 是不可見的。
陷阱 12：分割置放群組提供執行個體級別的隔離
錯。分割 PG 提供的是分割級別的隔離 — 同一分割內的所有執行個體共享機架命運。執行個體級別的隔離需要使用分散 PG。
決策矩陣 — ANS-C01 每個目標對應的效能組件
| 效能目標 | 主要組件 | 備註 |
|---|---|---|
| 緊密耦合的 HPC、亞微秒延遲 | EFA + 叢集 PG + libfabric MPI/NCCL | 四者缺一不可。 |
| 同 AZ 最大彙總吞吐量 | 多串流並行 + 叢集 PG + 巨型框架 | 多串流是關鍵；單一串流上限約 10 Gbps。 |
| 分散式資料庫機架隔離 | 分割置放群組 | 每個 AZ 最多 7 個分割。 |
| 小型 HA 叢集、最大隔離 | 分散置放群組 | 每個 AZ 最多 7 個執行個體。 |
| 區域內從 EC2 到 S3 的大宗傳輸 | S3 閘道端點 + 分段上傳 | 免費、無 NAT、並行串流。 |
| 跨區域從 EC2 到 S3 的大宗傳輸 | S3 加速傳輸 (Transfer Acceleration) | 透過 CloudFront 邊緣 PoP 上傳。 |
| 兩個 VPC 之間的 9001 MTU | VPC 對等連接或 TGW 連接 + 同區域 | 跨區域對等連接在邊界處上限為 1500。 |
| 混合鏈路上的 9001 MTU | 啟用巨型框架的 Direct Connect | VIF 與在地路由器必須一致。 |
| 單個 TCP 串流 > 10 Gbps | 完全繞過 TCP 的 EFA | TCP 單一串流受限；SRD 支援多路徑。 |
| 診斷吞吐量低於預期的問題 | 測試 PMTUD + 檢查單串流 vs 多串流 + Flow Logs | 通常是 PMTUD 或單串流上限問題。 |
| 避免 HPC 中的跨 AZ 流量成本 | 單 AZ 的叢集 PG | 叢集是單 AZ 的；跨 AZ 需付全額傳輸費。 |
| GPU All-reduce | EFA + p4d/p5 執行個體上的 NCCL + 叢集 PG | NCCL 使用 libfabric。 |
FAQ — 網路效能、ENA、EFA、巨型框架
Q1：EFA 到底何時有幫助，何時只是干擾？
EFA 僅針對 HPC 與緊密耦合的分散式運算工作負載 提供可衡量的效能提升 — 如 MPI All-reduce、GPU 叢集上的 NCCL 集體操作、某些即時模擬執行環境 — 這些應用程式顯式地調用 libfabric 來驅動作業系統繞過的資料路徑。對於純 TCP 應用程式 (網頁伺服器、REST API、S3 傳輸、使用 TCP 的資料庫複寫、檔案複製)，EFA 提供零效益，因為應用程式從未觸及 libfabric；它只看到 ENA 介面並使用標準 TCP/IP。ANS-C01 經常編寫情境，誘使考生為「最大效能」推薦 EFA — 除非工作負載是 HPC，否則這是錯的。正確的判斷標準是：「我的工程師是否針對 libfabric、MPI 或 NCCL 進行編譯？」 — 如果不是，EFA 就無關緊要，正確答案應是在更大規模執行個體上使用 ENA 配合多串流並行。
Q2：我在 VPC 內部啟用了巨型框架，現在到網際網路的部分流量卡住了 — 為什麼？
這是經典的 PMTUD 黑洞。在 VPC 內部，你的執行個體發送 9001 位元組框架。當流量跨越網際網路閘道時，IGW 將 MTU 限制在 1500 — 大於 1500 且設定了 DF 位元的框架應該觸發發回給發送端的 ICMP Type 3 Code 4 (「需要分段且 DF 已設定」) 訊息，發送端隨後會調降 TCP MSS。黑洞形成的原因是該 ICMP 回應被丟棄了 — 可能是你的安全性群組不允許 ICMP、上游 ISP 防火牆封鎖了 ICMP，或是路徑上的中間路由器所致。發送端不斷重傳 9001 位元組的封包，沒有封包能穿過，連線因而卡死。修正方法：(a) 在用於網際網路流量的傳出介面上停用巨型框架；(b) 在傳出設備上配置 TCP MSS 鉗制 (通常設為 1380 位元組，以考慮 IP+TCP 開銷)；(c) 確保端到端允許 ICMP Type 3 Code 4。AWS Site-to-Site VPN 會自動執行 MSS 鉗制；在直接網際網路傳出時，OS 級別的修正是 iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu。
Q3：如何為最大 All-reduce 效能規劃 HPC 叢集規模？
四步驟秘訣：(1) 從支援 EFA 的列表中選擇正確的執行個體類型 — 通用 HPC 選 hpc7a.96xlarge (200 Gbps)，運算密集型選 c6in.32xlarge (200 Gbps)，GPU All-reduce 選 p5.48xlarge (通往 GPU NIC 的頻寬達 3200 Gbps)。(2) 啟動時附加具備 EFA 能力的 ENI — 在啟動規範中傳遞 InterfaceType=efa；通常每個執行個體一個 EFA ENI 是標準做法。(3) 放置在單一 AZ 的叢集置放群組中 — 單次 API 呼叫啟動所有執行個體以最大化容量放置；避免停止/啟動以防重新放置到不同機架。(4) 針對 libfabric 構建應用程式 — 大多數 Open MPI 4.x+、Intel MPI 2019+ 和 NCCL 2.10+ 的分發版都原生支援 libfabric；透過 ompi_info | grep libfabric 驗證，並確保環境變數中設定了 FI_PROVIDER=efa。在運行生產工作負載前，先使用 mpirun -np N ./osu_allreduce (俄亥俄州立大學微基準測試) 進行驗證。針對「如何優化 HPC 節點間通訊」的考試答案正是這套堆疊。
Q4：同一個 VPC 內兩個執行個體間的 TCP 吞吐量遠低於宣傳的執行個體頻寬 — 為什麼？
三個可能原因，按發生頻率排序：(1) 單一串流上限 — 無論宣傳的彙總頻寬多大，標準 ENA 上單個 TCP 連線在同 AZ 被限制在約 10 Gbps (跨 AZ 為 5 Gbps)。請使用 iperf3 -P 10 (10 個並行串流) 進行驗證 — 如果並行測試顯示了全速頻寬，那麼瓶頸就是單一串流上限，解決方法是應用程式級別的並行化。(2) 跨 AZ 流量 — 如果兩個執行個體位於不同 AZ，單一串流上限會減半，且會有不可避免的額外延遲 (約 1ms，而非亞微秒級)。解決方法是使用叢集置放群組將延遲敏感的工作負載放置在同一個 AZ。(3) CPU 瓶頸 — 在極高的封包速率下 (數億 PPS)，核心網路堆疊可能會使單個 CPU 核心飽和；解決方法是配置 RPS (接收封包引導)、使用具備更多核心的大型執行個體類型，或者切換到繞過 CPU 的 EFA。ANS-C01 期望你在得出「網路壞了」的結論前，先進行多串流與跨 AZ 的測試。
Q5：我應該為我的 MongoDB 叢集使用分割置放群組還是分散置放群組？
取決於叢集大小與 HA 模型。當你擁有多於 7 個節點且應用程式具備機架感知複寫功能時，使用分割 PG — 通常是 Cassandra, HDFS, Kafka 或 ScyllaDB 這些能理解分割拓撲並跨分割複寫的應用程式。擁有最多 7 個次要節點的 MongoDB 複寫集兩者皆可；若複寫集大於 7 個節點 (不常見)，則需要分割。對於小型叢集 (每 AZ ≤ 7 個執行個體) 且每個執行個體必須位於其物理機架上的情況，使用分散 PG — 這常見於 MongoDB 主要節點加少數次要節點、etcd 仲裁成員、ZooKeeper 組合或其他小規模 N 的控制平面組件。權衡點在於規模 (分散受限) 與粒度 (分散隔離到執行個體，分割隔離到分割)。對於多 AZ MongoDB，你通常會結合：在各個 AZ 內部使用分散 PG 來放置當地複寫成員，並在 AZ 之間進行 MongoDB 複寫集複寫。
Q6：如何在 Direct Connect 上配置巨型框架，什麼情況下會出問題？
三個協調點：(1) AWS 端：建立虛擬介面 (私有 VIF, 公有 VIF 或傳輸 VIF) 時，將 MTU 設定為 9001 (預設為 1500)。對於現有 VIF，你可以更新 MTU 但必須與在地端協調。(2) 在地路由器：配置 L2 鏈路 MTU 為 9001 (或更高，以容納 VLAN 標籤開銷 — 物理介面上通常為 9100)。在地路徑中，客戶端路由器與工作負載 VLAN 之間的所有中間交換機也必須支援 9001+ MTU。(3) 路徑一致性：路徑中只要有一個 1500 MTU 的交換機，就會重現 PMTUD 黑洞。從發送端使用 ping -M do -s 8972 進行測試 (8972 = 9000 - 28 位元組 IP/ICMP 開銷)；如果 8972 成功但 9000 失敗，則 MTU 在某處受限。重要的 DXGW 到 TGW 提醒：透過 Direct Connect Gateway 到 Transit Gateway 的流量最高僅支援 8500 MTU，而非 9001 — 這是 ANS-C01 偶爾測試的細微限制。
Q7：SR-IOV、DPDK 與 EFA 之間有什麼區別？
SR-IOV (單一根 I/O 虛擬化) 是一種硬體級 NIC 共享技術 — 一個物理 NIC 呈現多個虛擬功能 (VF)，每個 VF 對客體作業系統而言就像一個專用 NIC。Nitro 上的 ENA 使用的就是 SR-IOV。DPDK (資料平面開發套件) 是一個使用者空間網路函式庫，它繞過核心網路堆疊以處理高 PPS 工作負載 — 常見於 NFV (網路功能虛擬化) 設備；在 EC2 上支援透過 DPDK 模式下的 ENA 驅動程式使用。EFA (Elastic Fabric Adapter) 是 AWS 專為 HPC 設計的作業系統繞過介面卡，採用 SRD 作為其線路傳輸，並向應用程式暴露 libfabric API。這三者處於不同層次：SR-IOV 是 Hypervisor 等級的，DPDK 是針對通用 NFV 的使用者空間網路堆疊繞過，EFA 是專為 MPI/NCCL 設計的 HPC 繞過。ANS-C01 期望你將 EFA 視為 HPC 選項，而非 DPDK；關於 DPDK 的問題通常圍繞「高 PPS 網路設備」而非 HPC 展開。
Q8：我的安全團隊想要完全停用 ICMP — 這對效能有什麼後果？
在路徑的任何邊界停用 ICMP 會破壞 PMTUD，這意味著 VPC 內部的巨型框架無法安全地穿過任何 MTU 縮小的邊界。具體故障模式：(a) 當封包超過 1500 位元組時，從 VPC 到網際網路的流量會靜默卡死；(b) 當封包超過 1438 位元組時，Site-to-Site VPN 上的流量會卡死；(c) 在巨型/非巨型混合路徑上的 Direct Connect 流量會在縮小點卡死。緩解措施：(1) 在傳出設備執行 MSS 鉗制，主動在 SYN 時約束 TCP MSS，使封包永不超過路徑 MTU；AWS Site-to-Site VPN 會自動執行此操作。(2) 在面向非巨型路徑的介面上停用巨型框架，接受 1500 MTU。(3) 允許 PMTUD 所需的特定 ICMP 子類型 — Type 3 Code 4 (「需要分段且 DF 已設定」) 與 Type 3 Code 3 (「連接埠不可達」) — 而非允許所有 ICMP。安全最佳實踐中的「預設拒絕 ICMP」政策會產生意想不到的效能後果，設計時需多加考慮。
Q9：為什麼叢集置放群組會因 InsufficientCapacity 失敗，如何避免？
叢集置放群組要求所有執行個體位於同一個物理機架與主幹上。隨著叢集擴大，AWS 在單一機架上可能沒有足夠的空間供大型執行個體使用 — 特別是像 hpc6a.48xlarge 這樣擁有 192 個 vCPU 的巨型機器，一個機架只能容納幾台。緩解措施：(1) 在 RunInstances 中帶入數量參數，在單次 API 呼叫中啟動所有執行個體 — AWS 在看到完整請求時會優化機架分配；一台一台啟動的分配效果差得多。(2) 提前使用 容量預留 (Capacity Reservations) — 在特定 AZ 的叢集 PG 中預留 N 台 hpc6a.48xlarge，啟動時即可保證容量。(3) 避免停止/啟動循環 — 執行個體停止並重啟後，AWS 可能會將其重新放置在不同機架上，破壞叢集 PG 保證。對於 HPC 工作負載，應將執行個體視為不可變的；若需重啟，請直接替換而非重啟。(4) 對於超大型叢集 (>100 台大型執行個體)，應接受叢集 PG 可能放不下的事實，拆分成多個叢集 PG (伴隨一定的 PG 間延遲) 或改用分割 PG。
Q10：針對運行混合工作負載的多 AZ Kubernetes 叢集，正確的置放群組策略是什麼？
標準模式：(1) 控制平面 — etcd 與 Kubernetes API Server 複本在每個 AZ 使用分散置放群組，確保機架級故障隔離；etcd 對單一機架故障同時帶走兩個複本的情況非常敏感。(2) 資料平面背景工作節點 — 大多數 Pod 運行在無置放群組的節點上 (預設置放)；叢集排程器透過拓撲分散約束來處理節點間的分散。(3) HPC 工作負載 (HPC 運算子、ML 訓練) — 專用的背景工作節點組位於叢集置放群組中，配備支援 EFA 的執行個體 (hpc6a.48xlarge, p5.48xlarge)；叢集自動擴充器僅在此處標記節點以排程 HPC Pod。(4) 有狀態工作負載 (使用 EBS 的 StatefulSet Pod) — 通常預設置放；對於分散式資料庫 (Cassandra, Kafka)，按區域劃分分割置放群組並搭配穩定的節點標籤。核心洞察：置放群組是基礎設施級別的約束，Kubernetes 排程置放是工作負載級別的；它們透過將節點組映射到 PG 類型來實現結合。ANS-C01 可能不會深入探討 Kubernetes 細節，但底層的 PG 模式完全一致。
進階閱讀與相關營運模式
- Linux 上的 ENA 增強型網路
- Elastic Fabric Adapter
- 置放群組
- 網路最大傳輸單元 (MTU)
- EC2 執行個體網路頻寬
- Direct Connect 上的巨型框架
- 跨 VPC 對等連接的巨型框架
- 用於 HPC 的 Elastic Fabric Adapter
- AWS ANS-C01 考試指南
理解網路效能內核後，ANS-C01 自然的下一個營運層級是：用於診斷吞吐量問題與驗證意圖的 VPC 流程日誌與 Reachability Analyzer；用於追蹤 NAT GW 支出與 TGW 資料處理費的網路監控與成本優化；用於 BGP 路由限制、彙總以及 Direct Connect 容錯移轉測試的混合連線維護；以及用於專用跨連接線路速率加密故事的 Direct Connect VIF 類型與 MACsec。