高效能與可擴展網路架構

什麼是 AWS 高效能網路架構

AWS 高效能網路架構是將 EC2 網路基礎元件（ENA、EFA、Placement Groups）、邊緣加速服務（CloudFront、Global Accelerator）、Hub-and-Spoke 連線（Transit Gateway）、專用混合連結（Direct Connect）以及私有服務暴露（AWS PrivateLink）整合起來的組合方案，以達到最低 latency、最大 throughput，並在高負載下維持穩定可預測的表現。SAA-C03 任務說明 3.4 要求考生「決定高效能且／或可擴展的網路架構」——也就是說，每個情境都需要你從正確的層級選擇正確的工具。高效能網路架構從來不是靠單一神奇服務達成的；而是透過將執行個體層的封包處理、VPC 內部的位置策略、VPC 間的路由、邊緣快取，以及混合頻寬，與實際流量模式精確對齊，才能實現。

在 SAA-C03 中，高效能網路架構這個主題約佔 Domain 3 1,920 題中的 270 題，且與 Domain 1（VPC 安全性）和 Domain 4（網路成本）的概念高度重疊。考試獎勵能夠用一句話區分 CloudFront 與 Global Accelerator、說明 Cluster Placement Groups 為何優於 Spread Placement Groups 用於 HPC、精準描述 ENA 與 EFA 在基準之上帶來了什麼，以及能說出 Transit Gateway 取代 VPC Peering 的情境的考生。高效能網路架構也是大多數「低 latency 應選哪個服務」問題的主場，因此建立清晰的心智地圖，在許多相關問題上都能收益。

本筆記從 NIC 向上逐層解析高效能網路架構堆疊：ENA 與 EFA 的 Enhanced Networking、EC2 Placement Group 策略、CloudFront 快取政策與 Origin Shield、CloudFront 與 Global Accelerator 的選擇決策、大規模 Transit Gateway（路由、Multicast、Peering）、Direct Connect 連線類型、LAG 與 SiteLink、用於低 latency 私有服務存取的 AWS PrivateLink，以及貫穿每一層的頻寬規劃。每個段落都回扣「這如何改變考試當天的 latency 或 throughput」——因為高效能網路架構的題目，始終由 latency、throughput、jitter 或固定 IP 需求決定，而非流行術語。

高效能網路架構的生活化解釋

高效能網路架構聽起來很學術，但三個日常類比能讓你在考試壓力下也能迅速推理。

類比一——辦桌廚房（ENA、EFA 與 Placement Groups）

想像一個忙碌的辦桌廚房。標準 EC2 虛擬網路卡就像一個獨自跑菜的師傅，從灶台把每道菜端到每張桌——午餐客少時沒問題，但十二桌同時點菜時，這位師傅就成了瓶頸。啟用 ENA（Elastic Network Adapter） 就像換上一位推著送菜車的老手：同一個廚房、同樣的桌數，但因為送菜路徑最佳化，吞吐量大幅提升、每道菜的開銷也降低了。EFA（Elastic Fabric Adapter） 更進一步——直接裝設一條廚房專用傳菜道，讓廚師可以繞過外場、直接在各工作站之間傳遞，這正是 MPI 工作負載用微秒級 latency 互相通訊所需要的。Cluster Placement Groups 就像把所有前置工作站擺在同一張長台上，刀具、油料和鍋具都伸手可及；Spread Placement Groups 刻意讓每位廚師在不同工作站，一個地方出意外不會壞了整場；Partition Placement Groups 則把廚房分成幾組工作台，某一組出問題不影響其他組。在單一 AZ 內的高效能網路架構，就是為工作負載挑選正確的廚房佈局。

類比二——全球郵政系統（CloudFront、Global Accelerator 與 Transit Gateway）

現在把視野拉到全球尺度。CloudFront 是遍布各地的便利郵局分店：大家都想要的可快取 HTTP 內容（每個人都在等的包裹）預先備貨在客戶附近，只需走兩條街就能取件，而不用等中央倉庫發貨。快取政策就是決定分店能否直接拿出架上現有包裹、還是必須打電話給倉庫的取件規則。Origin Shield 是區域轉運中心，把快取未命中集中起來，讓倉庫每天只需應付一輛卡車，而不是五十輛。AWS Global Accelerator 相較之下，是企業專線服務電話：客戶在世界任何角落撥打同一個固定號碼，電話立刻進入 AWS 私有骨幹網路，並被路由到路徑最短的健康機房——沒有快取、不論協定，就是一條更快的線路。Transit Gateway 是中央郵件分揀中心：每個分公司（VPC）把外寄郵件投入總部，總部讀取路由表後轉發到正確目的地，新分公司加入時不需要和所有現有分公司簽雙邊協議。跨越區域或數千個 VPC 的高效能網路架構，歸根結底就是在「分店快取」、「專線電話」和「中央分揀」之間做選擇。

類比三——大樓水電管路（Direct Connect、SiteLink 與 PrivateLink）

一個地端資料中心連到 AWS，就像一棟公寓大樓接上城市公共設施。Site-to-Site VPN 是把電纜接上公共電網、在自家電表加把鎖——便宜、安裝快，但電壓會浮動。AWS Direct Connect 是從變電站拉一條獨立專線直接進大樓——需要好幾週挖管溝，但用電量是合約保障的，沒人和你共用。Dedicated Connection 是整條專線（1/10/100 Gbps）；Hosted Connection 是租用別人已經拉好的電纜中的一個分支（50 Mbps 到 10 Gbps）。Link Aggregation Groups（LAG） 把最多四條專線綑成一條粗幹線，讓你以 4×10 Gbps 作為一條邏輯管道使用。SiteLink 是公用事業公司推出的新服務，讓你的東京大樓和法蘭克福大樓透過公用骨幹互相調電，不用在中間另外租辦公室——分支之間透過 AWS 私有網路交換流量，完全繞過公共網際網路。AWS PrivateLink 是私有服務走廊，讓你的大樓透過專屬管道接收特定有線電視業者的訊號，而非走共用豎管——單向、低 latency，且對其他住戶完全不可見。混合層的高效能網路架構，就是選擇拉哪條電纜、預留哪條走廊。

以廚房、郵政系統和公寓管路作為心智地圖，SAA-C03 上每一道高效能網路架構的題目，都能化簡為「哪一層用哪個工具」。

EC2 網路效能基礎——ENA、EFA 與基準線

高效能網路架構從執行個體開始。你在 EC2 之上所建構的一切，都繼承了網路卡的 PPS 速率、jitter 和跨 AZ latency——所以選對 Enhanced Networking 驅動程式與 Placement Group，是第一個槓桿，不是最後一個。

ENA 的 Enhanced Networking

Elastic Network Adapter（ENA） 是幾乎所有現代 EC2 執行個體家族（M5 以上、C5 以上、R5 以上、Nitro 架構）的標準高吞吐量虛擬網路卡。ENA 在最大型執行個體上可提供高達 100 Gbps 的聚合吞吐量，利用 SR-IOV 繞過 Hypervisor 封包路徑，並且在所有現行 Amazon Linux、Ubuntu LTS 和 Windows Server AMI 上預先安裝驅動程式。

與舊版 Xen 半虛擬化驅動程式相比，ENA 帶來的優勢：

• 更高的 PPS（封包每秒）——在 c5n 上通常可達 200 至 400 萬 PPS，遠高於舊版的數十萬。
• 更低且更穩定的執行個體間 latency——在同一 AZ 內可達個位數微秒。
• 硬體 Checksum Offload 與多佇列支援，讓單一執行個體的 vCPU 不成為網路卡瓶頸。

在 SAA-C03 中你不需要對 ENA 做效能基準測試；你需要認識到，只要情境提到「高封包速率」、「低 jitter」、「網路密集型 EC2 工作負載」，或是提及 c5n、m5n、m5dn、r5n，答案就涉及使用 ENA 的 Enhanced Networking。

用於 HPC 與 ML 的 Elastic Fabric Adapter（EFA）

EFA 是 ENA 加上 OS 旁通資料路徑。在支援的執行個體上（c5n.18xlarge、p4d.24xlarge、p5、hpc6a、hpc7a 及同類），EFA 增加了 Scalable Reliable Datagram（SRD） 協定，讓 MPI 和 NCCL 流量完全跳過 TCP/IP 堆疊與核心，在同一 Cluster Placement Group 內的執行個體之間達到穩定低於 20 微秒的應用程式對應用程式 latency。

EFA 是正確答案的時機：

• 執行 MPI 的緊密耦合 HPC（計算流體力學、分子動力學、氣象模擬）。
• 8 個節點以上的分散式深度學習訓練（PyTorch DDP、Horovod、NCCL all-reduce）。
• 任何提到 libfabric、MPI、NCCL 或「緊密耦合」的情境。

EFA 不是答案的時機：

• 一般網頁流量、資料庫，或任何使用標準 TCP Socket 的工作——EFA 在此退回標準 ENA 行為，不會有損失，但也沒有增益。
• 跨 AZ 或跨 Region 的流量——EFA 要求執行個體必須在同一 AZ 且同一 Cluster Placement Group 內。

EC2 Placement Groups——Cluster、Spread 與 Partition

Placement Groups 告知 EC2 如何在實體上分配執行個體的相對位置。高效能網路架構使用 Placement Groups，以最大化吞吐量（緊密排列）或最小化關聯故障（分散配置）。三種策略分別是：

1. Cluster Placement Group——所有執行個體放入一個 AZ 內的單一機架或相鄰機架。這能將執行個體間 latency 降到最低，並最大化每個流量的頻寬（執行個體之間每個流最高達 10 Gbps）。最適合 HPC、MPI、金融交易和緊密耦合的 ML 訓練。典型的取捨是：機架級故障會影響整個群組。

2. Spread Placement Group——每個執行個體落在不同的底層硬體機架上，可選擇性跨越多個 AZ。每個 AZ 每個 Spread Group 最多 7 個執行個體。最適合小型關鍵機群（例如少數控制平面節點或 NoSQL Quorum），這些節點絕對不能同時發生故障。7 的硬性上限是 SAA-C03 最愛設的陷阱。

3. Partition Placement Group——將執行個體劃分為每個 AZ 最多 7 個 Partition，每個 Partition 位於獨立的一組機架上。可擴展至數百個執行個體。最適合大型分散式工作負載，例如 HDFS、Cassandra 或 Kafka，這些應用程式可以在整個 Partition 失效時存活，但希望各 Partition 能獨立故障。

執行個體網路頻寬——隱藏的上限

每種 EC2 執行個體類型都有文件記載的基準與突發網路頻寬。小型執行個體（t3.small、m5.large）擁有類似 EBS 的突發額度；較大的規格（m5.24xlarge、c5n.18xlarge、c7gn.16xlarge）則提供有保障的吞吐量，最高達 100 Gbps。考試題目中常見兩個陷阱：

• 單一流量上限：即使在 100 Gbps 執行個體上，單一 TCP 流量在大多數情況下也上限為 5 Gbps（Cluster Placement Group 內為 10 Gbps）。要擴大吞吐量，需要多個平行流量。
• 跨 AZ 與跨 Region 限制：AZ 間流量耗費頻寬並增加 latency（在同一 Region 內約 1–2 ms）。跨 Region 頻寬沒有硬性上限，但需支付資料傳輸費用，且會增加數十毫秒的 latency。

若情境要求「兩個 EC2 執行個體之間的最大吞吐量」，答案是：同一 AZ + Cluster Placement Group + ENA 或 EFA + 網路頻寬 25 Gbps 以上的執行個體類型 + 多個平行流量。

CloudFront 深入解析——降低 Latency 的邊緣快取

Amazon CloudFront 是 AWS 的 CDN，也是任何涉及「降低全球使用者 latency」且內容為可快取 HTTP/HTTPS 的情境的第一選擇。高效能網路架構將 CloudFront 視為四層快取：瀏覽器、邊緣快取、Regional Edge Cache 和 Origin Shield，只有在每一層都未命中時，才向來源端發出請求。

CloudFront Origins 與 Origin Groups

CloudFront Origin 是 CloudFront 在快取未命中時擷取內容的真實來源。支援的 Origin 類型包括：

• Amazon S3 Bucket（搭配 Origin Access Control 將 Bucket 鎖定為僅 CloudFront 可存取）。
• AWS MediaStore 和 MediaPackage，用於影片工作流程。
• Elastic Load Balancers（ALB 或 NLB）作為 EC2、ECS 或 EKS 的前端。
• API Gateway 端點（雖然 API Gateway 本身也有邊緣快取）。
• 任何可公開存取的 HTTP 伺服器，包括地端 Origin 和非 AWS 雲端。

Origin Group 將主要 Origin 與次要 Origin 配對，並設定一組觸發 Origin Failover 的 HTTP 狀態碼（通常為 500、502、503、504 及特定的 4xx）。這是你在邊緣所能實作的最快 DR 模式——Failover 在邊緣以毫秒完成，不需等待 Route 53 TTL 過期。

Cache Behaviors 與路徑模式

Cache Behavior 將路徑模式（例如 /api/* 或 /static/*）對應到特定 Origin，以及一組快取設定。CloudFront 依照路徑的特定程度由高到低評估 Behavior；預設 Behavior（*）是最後的備援。使用 Cache Behaviors 可以：

• 將 /api/* 送往停用快取的 ALB，同時 /static/* 送往 S3 並設定 24 小時 TTL。
• 對不同路徑前綴附加不同的 WAF Web ACL。
• 依路徑設定不同的 Viewer 協定政策（HTTP 重新導向至 HTTPS，或僅允許 HTTPS）。
• 只對特定 Behavior 關聯 Lambda@Edge 或 CloudFront Functions。

Cache Policies、Origin Request Policies 與 Response Headers Policies

現代 CloudFront 將三個過去共用同一設定介面的關切點分開管理：

• Cache Policy——定義快取鍵（哪些 Header、Cookie 和 Query String 是雜湊的一部分）以及 TTL。快取鍵越窄，命中率越高。
• Origin Request Policy——定義 CloudFront 在快取未命中時轉發給 Origin 的內容，與快取鍵無關。你可以轉發比鍵值更多的資訊給 Origin，避免快取鍵爆炸。
• Response Headers Policy——在回應返回 Viewer 途中注入安全性 Header（HSTS、CSP）、CORS Header 和自訂 Header。

AWS 發布了數個受管政策（CachingOptimized、CachingDisabled、CachingOptimizedForUncompressedObjects、AllViewer 等），涵蓋 80% 的使用情境。當你需要針對特定 Header（如 Accept-Language）建立鍵值時，才需要自訂政策。

Origin Shield——區域快取整合器

Origin Shield 是一個可選的額外快取層，置於 CloudFront Regional Edge Caches 與你的 Origin 之間。啟用後，每個邊緣節點的快取未命中都會先匯集到 Origin Shield 所在 Region。優點：

• 大幅降低 Origin 負載：不再是數百個 Regional Edge Cache 各自從 Origin 拉取，只有 Origin Shield 拉取，並將對同一物件的並行請求合併成單一次 Origin 擷取。
• 提高長尾內容的快取命中率，因為請求過於稀疏而無法填充每個 Regional Edge Cache 的情境特別有效。
• 降低 Origin 的出口成本，因為從 Origin 傳出的位元組大幅減少。

Origin Shield 在以下情境特別有價值：

• 直播影片工作流程，數千名觀眾在數秒內請求同一個片段。
• 中等基數的 API，區域邊緣快取的個別命中率偏低。
• 任何出口有嚴格限制的 Origin（小型地端伺服器或 Direct Connect 連結）。

反面是 Origin Shield 的每 GB 費用；對於每個邊緣節點本來命中率就很高的純靜態資產，Origin Shield 有時只會增加成本而沒有實質效益。

CloudFront 安全性與效能整合

高效能網路架構將 CloudFront 視為 latency 工具，同時也是安全性工具：

• AWS Shield Standard 在每個 Distribution 上免費提供，於邊緣封鎖第 3/4 層 DDoS。
• AWS WAF 附加 Web ACL，進行第 7 層過濾（SQL 注入、XSS、速率限制）。
• Field-level encryption 在邊緣加密特定表單欄位（信用卡號），使其在到達特定後端服務前永遠不被解密。
• CloudFront Functions 在每個邊緣節點執行微小的 JavaScript（次毫秒級），用於 URL 重寫、A/B 測試和 Header 操作。
• Lambda@Edge 在 Regional Edge Cache 執行 Node.js 或 Python，處理更豐富的邏輯（身分驗證、圖片縮放）。

AWS Global Accelerator——anycast IP 透過 AWS 骨幹網路

Global Accelerator 是 CloudFront 的非 HTTP 版本。它提供兩個靜態 anycast IPv4 位址（可選擇額外兩個 IPv6），從每個 AWS 邊緣節點發布。客戶端連接這些 IP 後，立即進入 AWS 骨幹網路，並透過私有骨幹路由到特定 Region 中已設定的端點群組——繞過公共網際網路的壅塞路徑，讓大部分旅程走更快的線路。

Global Accelerator 核心組成要素

• Accelerator——最頂層資源，發放兩個靜態 anycast IP。
• Listener——在特定連接埠（或連接埠範圍）上的 TCP 或 UDP，可選擇性設定 Client 親和性黏著。
• Endpoint Group——每個 AWS Region 一個，透過流量撥盤百分比（0–100）控制該 Region 接收多少流量。
• Endpoint——ALB、NLB、EC2 執行個體或 Elastic IP。權重控制 Group 內的分配。

Global Accelerator 勝過公共網際網路的原因

• 邊緣的 anycast IP：無論客戶端的 ISP 路徑為何，封包都能在數十毫秒內進入 AWS。
• 私有骨幹：其餘旅程在 AWS 自有光纖上進行，latency 可預測且 jitter 低。
• 快速 Failover：不健康的端點在 30 秒內從輪詢中移除，流量自動重新路由到下一個最佳 Region。
• 固定 IP 用於允許清單：企業防火牆、遊戲主機和 IoT 閘道常常內嵌 IP——這兩個 anycast IP 在 Accelerator 的整個生命週期內都不會改變。

Global Accelerator 與 CloudFront——標準決策

這是 SAA-C03 高效能網路架構領域最常被測試的區別。使用以下簡短表格，再搭配下方段落：

決策規則：若流量是可快取的 HTTP(S)，從 CloudFront 開始。若流量是 UDP、非 HTTP TCP，或 HTTP 但無法快取且需要固定 IP，選 Global Accelerator。兩者不互斥——大型架構同時執行 CloudFront 處理 /static/*，以及 Global Accelerator 處理即時 WebSocket 或遊戲伺服器機群。

AWS Transit Gateway 大規模應用

AWS Transit Gateway 是一個區域性雲端路由器，連接 VPC、VPN、Direct Connect Gateway 和其他 Region 的對等 Transit Gateway。只要互連的 VPC 數量超過個位數，高效能網路架構就會使用它——VPC Peering 在規模擴大時呈組合式增長（N×(N-1)/2），而 Transit Gateway 則是線性成長。

Transit Gateway 路由與路由表

每個附件（VPC、VPN、DX、Peering）都關聯到一個 Transit Gateway 路由表，但可以傳播路由到多個路由表中。靜態路由和傳播的（動態）路由共存。常見模式：

• 扁平拓撲：單一預設路由表；每個 VPC 都能互相連接。
• 分段拓撲：為正式、開發和共用服務設置不同路由表，以靜態路由控制哪些區段可以互相通訊。
• 共用服務中心：托管 DNS、AD 和 CI/CD 的中央 VPC，正式和開發路由表都路由到它，但彼此不互通。

Transit Gateway Multicast

Transit Gateway 支援跨 VPC 的原生 IP Multicast——適用於需要 Multicast 的傳統企業應用程式（市場資料分發、影片廣播、服務探索）。Multicast 群組在 Transit Gateway 上定義，來源和成員以 ENI 表示；跨 AZ 和跨 VPC 的傳遞由 TGW 處理。這是在 AWS 內部執行 Multicast 的唯一方式；原生 VPC Multicast 並不支援。

Transit Gateway Peering 與跨 Region 流量

不同 Region 的兩個 Transit Gateway 可以透過 AWS 骨幹對等連接，提供傳遞式的多 Region 連接，而無需支付跨 Region 公共網際網路費用或拼湊 VPN。對等 TGW 之間的流量走 AWS 私有網路，依照一般跨 Region 資料傳輸定價計費。Peering 記錄在各自的 TGW 路由表中，以不含 BGP 的路由決策處理。

必記的 Transit Gateway 規模數字

• 每個 Transit Gateway 最多 5,000 個附件。
• 每個 Transit Gateway 路由表最多 10,000 條路由。
• 每個 VPC 附件 50 Gbps（跨流量的聚合）。
• 跨多個 Direct Connect 或 VPN 附件的 Equal-Cost Multi-Path（ECMP），用於頻寬聚合。

AWS Direct Connect——專用連線、LAG 與 SiteLink

Direct Connect 是跨越地端與 AWS 的高效能網路架構的實體層。它提供從客戶路由器（位於 Direct Connect 機房，一個電信中立共置設施）到 AWS 的私有光纖連結，完全繞過公共網際網路。

Dedicated 與 Hosted 連線

• Dedicated Connection：分配給你 AWS 帳戶的實體連接埠（1 Gbps、10 Gbps 或 100 Gbps）。直接向 AWS 申請；佈建需要數週，因為交叉連接必須在共置機房實際接線。
• Hosted Connection：由 AWS Direct Connect Partner 佈建的合作夥伴現有 Direct Connect 連接埠的邏輯切片。速度從 50 Mbps 到 10 Gbps。開通更快（通常數天），且較適合 sub-Gbps 頻寬需求。每個 Hosted Connection 只有一個 VIF。

Virtual Interfaces（VIFs）

在 DX 連線上建立 VIF，每個都以 VLAN 標記：

• Private VIF 透過 Virtual Private Gateway 連接特定 VPC，或透過 Direct Connect Gateway 和 Transit Gateway Transit VIF 連接多個 VPC。
• Public VIF 在不通過網際網路的情況下，透過 DX 連結存取 AWS 公共服務（S3、DynamoDB、API 端點）——適用於合規要求禁止公共出口的情境。
• Transit VIF 連接到關聯 Transit Gateway 的 Direct Connect Gateway，讓單一 DX 連結服務跨多個 Region 的多個 VPC。

Link Aggregation Groups（LAG）

LAG 使用 LACP 將最多四條相同速度的 Dedicated Connection 捆綁成單一邏輯連線。優點：

• 聚合頻寬：4 × 10 Gbps 在邏輯上像 40 Gbps 一樣運作。
• 冗餘性：失去一個實體連接埠會降低容量，但如果符合最低連結閾值，不會中斷 BGP Session。
• 簡化 BGP：每個 LAG 一個 BGP Peer，而非每個連接埠一個。

對於 100 Gbps 工作負載，你可以將多個 100 Gbps 連接埠組成單一 LAG，但大多數客戶用單一 100 Gbps 連接埠就能滿足需求。

SiteLink——透過 AWS 骨幹連接地端至地端

AWS Direct Connect SiteLink 是一個可以在 Private 或 Transit VIF 上啟用的功能旗標。啟用後，兩個 Direct Connect 位置之間的流量，會透過 AWS 全球骨幹而非公共網際網路流動，即使兩端都不是 VPC。使用情境：

• 分支機構間 WAN 替換：東京資料中心和法蘭克福資料中心各自連接 DX，啟用 SiteLink，以 AWS 骨幹 latency 交換流量。
• 備援 WAN：SiteLink 作為 MPLS WAN 成本更低的備援線路。
• 多共置企業：將許多舊有 MPLS 電路整合到少數幾個 DX 連接埠上。

SiteLink 依每個啟用的 VIF 每小時計費，另加一般 DX 資料傳輸費用。它是第一個明確讓客戶將 AWS 骨幹用作 WAN，而不需要接觸任何 VPC 的 AWS 服務。

Direct Connect 彈性建議

AWS 發布了四個彈性等級；SAA-C03 要求你能辨識它們：

1. 開發與測試：在一個位置使用一條連線。
2. 高彈性：在同一 DX 位置連接兩台不同設備各一條連線。
3. 最高彈性：在兩個不同 DX 位置各連接一條連線（使用兩台不同的客戶路由器）。
4. Active/Active 加 VPN 備援，用於 Region 層級的災難容忍。

AWS PrivateLink 的低 Latency 私有服務存取

當高效能網路架構需要在不廣泛使用 VPC Peering 的情況下，將服務暴露給許多消費者時，就會使用 PrivateLink。PrivateLink 使用消費者 VPC 中的 Interface VPC Endpoints（具有私有 IP 的 ENI），透過 AWS 私有網路，連接到生產者 VPC 中的 Network Load Balancer。

PrivateLink 勝出的時機

• SaaS 風格的服務暴露：一個生產者 VPC，數百甚至數千個消費者 VPC，通常跨帳戶。
• 單向服務模型：消費者呼叫生產者；生產者無法主動回呼——有利於安全邊界。
• 無 CIDR 重疊顧慮：兩個 VPC 的 CIDR 重疊時 Peering 會失敗；PrivateLink 不在乎，因為 Interface Endpoint 從消費者的 CIDR 取得 IP。
• 細粒度 IAM：Endpoint 支援端點政策，服務提供者可控制哪些 AWS 帳戶可以連接。

PrivateLink vs VPC Peering vs Transit Gateway 的效能比較

• PrivateLink——多對一服務暴露的最低操作複雜度，NLB 前端，單向，以 ENI 為基礎。
• VPC Peering——雙向，在 VPC 數量少時資料處理成本最低，無法乾淨地擴展至多個消費者，CIDR 不能重疊。
• Transit Gateway——跨多個 VPC 的傳遞式路由，在同一中心支援 DX 和 VPN，彈性最高，但有每附件和每 GB 的處理費用。

對於大規模低 latency 的服務呼叫（數千個微服務消費者連接少數平台服務），PrivateLink 通常是高效能的答案。

原生使用 PrivateLink 的 AWS 服務

許多 AWS 服務（Kinesis、SNS、SQS、Systems Manager、Secrets Manager、ECR 等）都公開了 Interface VPC Endpoints，讓私有子網路無需 NAT Gateway 即可存取。這既提升了安全性，也降低了 NAT 出口成本——是高效能網路架構與成本最佳化網路之間的典型交集。

頻寬考量與容量規劃

高效能網路架構的最後一層是容量規劃——確保路徑上的每個環節都有足夠的餘裕來承受預期負載。

每個流量 vs 聚合頻寬

• 兩個 EC2 執行個體之間的單一 TCP 流量在大多數情況下上限為 5 Gbps，Cluster Placement Group 內為 10 Gbps。
• 聚合頻寬可達執行個體文件記載的額定值（最大型執行個體高達 100 Gbps，部分 Nitro 執行個體達 200 Gbps）。
• 若單一流量是瓶頸，請將應用程式設計為使用多條平行 TCP 連線，例如按鍵值分片或執行多個 Worker 執行緒。

NAT Gateway 與出口吞吐量

NAT Gateway 可擴展至每個 NAT Gateway 100 Gbps（近期從舊版 45 Gbps 提升），但吞吐量仍是考量因素：

• 在每個 AZ 部署一個 NAT Gateway，以避免跨 AZ latency 和跨 AZ 資料傳輸費用。
• 對於非常高出口量的修補或容器映像拉取，考慮針對特定 AWS 服務使用 VPC Interface Endpoints，而非透過 NAT 路由。
• DynamoDB 和 S3 可使用免費的 Gateway Endpoint，完全消除 NAT 流量。

跨 AZ 與跨 Region 頻寬

• 同一 Region 內的跨 AZ 流量通常為 1–2 ms，並以每 GB 雙向計費（同一 AZ 內免費）。
• 跨 Region 流量依地理位置增加數十到數百毫秒，且每 GB 以較高價格計費。
• 若持續的跨 Region 頻寬量可觀，請評估 Transit Gateway 跨 Region Peering（走骨幹，仍依 GB 計費）vs Direct Connect + SiteLink（固定連接埠費用，大量使用時每 GB 更便宜）。

每個 Direct Connect 連線的頻寬

• 1 Gbps / 10 Gbps / 100 Gbps 專用連接埠。
• 單一 LAG 最多四個連接埠。
• Hosted Connection 從 50 Mbps 到 10 Gbps。
• 請記住 DX 頻寬在定價上對每個 VIF 是半雙工的（資料傳輸僅以 DX 費率計出口）。

頻寬規劃檢查清單

對於任何提到吞吐量的 SAA-C03 情境（例如「每天傳輸 20 TB」、「持續 5 Gbps 的串流影片」），依序走過此檢查清單：

1. 來源和目的地為何——同一 AZ、跨 AZ、跨 Region，還是地端？
2. 流量是否可快取？若是，CloudFront 可大幅降低 Origin 頻寬。
3. 流量是否從私有子網路出口？NAT Gateway、Gateway Endpoint 還是 Interface Endpoint？
4. 單一 TCP 流量是否足夠，還是我們需要平行化來突破每個流量的上限？
5. 對於混合架構，VPN（每個 Tunnel 最高 1.25 Gbps，可透過 ECMP 聚合）是否足夠，還是需要 Direct Connect？

高效能網路架構並排決策表

高效能網路架構常見考試陷阱

1. CloudFront vs Global Accelerator 依協定區分——可快取 HTTP → CloudFront。TCP/UDP 或不可快取且需固定 IP → Global Accelerator。
2. Spread Placement Group 每 AZ 7 個執行個體的限制——更大的機群需要 Partition，而非 Spread。
3. Cluster Placement Group 僅限單一 AZ——跨 AZ 會破壞位置保證。
4. EFA 需要同一 Cluster Placement Group 且同一 AZ——否則你在支付 ENA 的費用卻使用了無效的 EFA 函式庫。
5. Direct Connect 不加密——需加上 MACsec 或 DX 上的 IPSec VPN。
6. VPC Peering 不具傳遞性——多個 VPC 需要 Transit Gateway，而非 Peering 網狀結構。
7. Global Accelerator 不快取——靜態內容仍需在前端使用 CloudFront。
8. 單一 TCP 流量上限為 5 Gbps——需要平行流量才能充分利用較大的執行個體。
9. NAT Gateway 是區域性的——每個 AZ 各部署一個以達到高可用性並避免跨 AZ 費用。
10. Origin Shield 是可選的——只有在快取命中率或 Origin 出口是痛點時才啟用。

高效能網路架構 vs VPC 安全性基礎——主題邊界

Task 1.2（VPC 安全性）和 Task 3.4（高效能網路架構）都涉及 VPC，也都涉及負載平衡器。邊界如下：

• 1.2 VPC 安全性主管控制平面決策：Security Groups、NACL、私有子網路設計、加密。
• 3.4 高效能網路架構主管資料平面決策：ENA/EFA、Placement Groups、CloudFront、Global Accelerator、Transit Gateway 吞吐量、Direct Connect 頻寬。

當題目問「什麼保護了流量？」是 1.2。當它問「什麼加速了流量？」是 3.4。偶爾一個服務（例如 PrivateLink）會同時出現在兩個領域；選擇符合任務說明動詞的領域——「保護」或「效能」。

高效能網路架構 vs 成本最佳化網路——主題邊界

Task 4.4（成本最佳化網路）在 Transit Gateway、Direct Connect 和 NAT Gateway 上與 3.4 重疊。邊界很清楚：

• 3.4 高效能關注 latency、throughput、jitter 和固定 IP。
• 4.4 成本最佳化關注每 GB 的費用、附件費用和出口減少。

Cluster Placement Groups 和 EFA 從不出現在 4.4，因為它們純粹是效能槓桿。Gateway Endpoints 同時出現在兩者——它們改善 latency（3.4）並消除 NAT 成本（4.4），這就是為什麼它們在整個考試中都是常見的正確答案。

高效能網路架構練習題模式

預期 SAA-C03 會在以下這些模式中深入考察高效能網路架構：

• 邊緣服務選擇：「全球使用者，可快取的 JSON API」→ CloudFront 搭配 CachingOptimized 政策。
• 協定判斷：「UDP 遊戲流量，遊戲主機防火牆需固定 IP」→ Global Accelerator。
• Placement Group 情境：「32 個節點的 HPC MPI 叢集，需微秒級 latency」→ Cluster Placement Group + EFA。
• Spread 限制陷阱：「11 台關鍵伺服器，不能同時故障」→ Partition（非 Spread，因為 Spread 每 AZ 上限為 7）。
• 多 VPC 規模：「10 個帳戶的 50 個 VPC」→ Transit Gateway + AWS RAM。
• 混合頻寬：「從地端到 AWS 持續 8 Gbps」→ Direct Connect Dedicated 10 Gbps + Private VIF。
• 跨分支 WAN：「東京和法蘭克福辦公室透過 AWS 私有骨幹連接」→ Direct Connect + SiteLink。
• 私有 SaaS 暴露：「不透過 Peering，將內部服務暴露給 300 個消費者 VPC」→ PrivateLink + NLB。

FAQ——高效能網路架構熱門問題

Q1：在高效能網路架構中，什麼時候應該使用 EFA 而非一般 ENA？

當你的工作負載是緊密耦合的、使用 MPI 或 NCCL，並且在同一 Cluster Placement Group 和同一 AZ 的多個 EC2 執行個體上運行時，使用 EFA。EFA 的 OS 旁通 SRD 協定可提供穩定的低於 20 微秒應用程式 latency，這是決定 10 節點 HPC 叢集能否線性擴展、或是否在 MPI all-reduce 開銷下崩潰的關鍵差異。對於其他一切——網頁伺服器、資料庫、TCP 微服務——ENA 已足夠，EFA 不帶來任何效能增益，因為應用程式仍然走正常的核心網路堆疊。請記住 EFA 需要相同 AZ、相同 Cluster Placement Group、支援的執行個體類型（c5n.18xlarge、p4d、p5、hpc6a、hpc7a 等），以及在 AMI 中安裝的 libfabric 使用者空間函式庫。

Q2：在高效能網路架構中，如何在 Cluster、Spread 和 Partition Placement Groups 之間做選擇？

從故障容忍度和 latency 需求出發。Cluster 是 latency 和吞吐量最重要，且整個群組可以容忍機架級關聯故障時的答案（HPC、緊密耦合的 ML 訓練、低 latency 交易）。Spread 是你有七個或更少關鍵執行個體每個 AZ，且這些執行個體絕對不能共享硬體時的答案（NoSQL Quorum 節點、控制平面排程器）。Partition 是你有許多執行個體應在獨立爆炸半徑區域中故障時的答案——HDFS Worker、Kafka Broker、擁有數百個節點的 Cassandra Ring。硬性限制決定了大多數考試問題：Spread 每 AZ 上限 7 個，Partition 每 AZ 上限 7 個 Partition，每個 Partition 內執行個體數量無限，Cluster 為單一 AZ。若情境描述每個 AZ 超過 7 個關鍵執行個體，Spread 就定義上是錯誤答案。

Q3：CloudFront Origin Shield vs 一般 CloudFront Distribution——何時值得支付額外費用？

當你的 Regional Edge Cache 快取命中率低，且 Origin 出口昂貴或頻寬受限時，Origin Shield 就值得。典型適合情境：直播影片（數千名觀眾在數秒內請求同一個片段，Origin Shield 將這些合併成單一 Origin 擷取）、長尾內容庫（類似維基百科，個別邊緣快取很少看到同一個物件兩次）、以及透過 Direct Connect 連接且出口計入有限 DX 連接埠的地端 Origin。對於自然快取命中率就很高的靜態網站（所有人都請求同一個 CSS/JS），Origin Shield 可能增加成本而沒有實質節省——先量測，再啟用。Origin Shield 是按 Origin 啟用的，所以你可以選擇性地只在受益的 Origin 上使用。

Q4：Global Accelerator 還是 CloudFront，用於服務全球行動客戶端的 REST API？

答案取決於回應的可快取性。若回應是可快取的（冪等的 GET、功能旗標、產品目錄），在 API 前端使用 CloudFront——快取命中在邊緣數十毫秒內返回，完全不到達 Origin。若回應是每個使用者專屬且不可快取的（POST、用戶專屬資料、即時訊號），且行動客戶端需要固定 IP 用於企業防火牆或對特定 Region 最低的非快取 latency，選擇 Global Accelerator——它在最近的邊緣節點將 TCP 連線路由到 AWS 骨幹，並在跨 Region 間維持快速 Failover。常見模式是兩者並用：CloudFront 處理可快取路徑，Global Accelerator 處理 WebSocket 端點。

Q5：Transit Gateway、VPC Peering 和 PrivateLink 在大規模高效能網路架構中如何比較？

VPC Peering 是兩三個 VPC、沒有 CIDR 重疊且沒有傳遞需求時的正確選擇——在第一個附件之後免費，且沒有資料處理費用。Transit Gateway 是多個 VPC（通常 4 個以上）、透過 AWS RAM 跨帳戶、傳遞式路由，或在 VPC 附件旁整合 VPN 和 Direct Connect 時的正確選擇。TGW 增加了每附件每小時費用和每 GB 處理費用，但線性擴展輕鬆勝過 Peering 的網狀複雜性。PrivateLink 是你將特定服務暴露給許多消費者時的正確選擇——它是單向的，在生產者 VPC 使用 NLB、在每個消費者 VPC 使用 Interface Endpoint，容忍 CIDR 重疊，可擴展到數千個消費者而不需要修改路由表。在實踐中，大型組織在同一個架構中同時運行三者：Transit Gateway 用於一般多 VPC、Peering 用於幾個特殊情況的 VPC 對，以及 PrivateLink 用於平台服務。

Q6：AWS Direct Connect SiteLink 是 MPLS WAN 的替代品嗎？

對許多企業來說，是的——或至少是一個可信賴的第二選項。SiteLink 讓兩個都有 Direct Connect 的地端站點之間的流量，在 AWS 私有骨幹上流動，而非透過公共網際網路或 MPLS 電路。在大多數地理區域，latency 與 MPLS 相當或更好，而每 Mbps 的成本通常遠低於現有 MPLS 定價。SiteLink 的注意事項：兩端都必須有 Direct Connect，你需要支付每小時每個啟用 SiteLink VIF 的費用加上每 GB 資料傳輸費用，且到備援路徑的 Failover 必須刻意設計（在你那端調整 BGP 權重）。常見的遷移模式是以 SiteLink 作為主要路徑、舊有 MPLS 作為備援，等到 SiteLink 穩定運作 6–12 個月後再退役 MPLS。

Q7：在高效能網路架構中，AWS PrivateLink 何時比其他替代方案更快？

PrivateLink 在三個特定情境中更快。第一，從私有子網路透過 Interface Endpoint 存取 AWS 服務（S3、DynamoDB、Kinesis、SNS、Secrets Manager、ECR 等），比透過 NAT Gateway 路由更快，因為跳數更少，流量從頭到尾都在 AWS 私有網路上——另外還消除了 NAT Gateway 的資料處理費用。第二，透過 PrivateLink 向多個 VPC 暴露服務，讓每個消費者都有一個帶私有 IP 的本地 ENI；在同一 Region 內的往返 latency 為數十微秒，而 Peering 的路徑仍然需要通過中間路由表查找。第三，PrivateLink 在操作上的擴展速度更快：新增第 501 個消費者，在生產者端不需要任何變更，而 Peering 則需要在兩端各建立新的 Peering 連線和路由表條目。對於跨 Region 的私有服務存取，將 PrivateLink 與 Transit Gateway 跨 Region Peering 或專用複製層搭配使用。

高效能網路架構延伸閱讀

• AWS VPC Connectivity Options Whitepaper（最新版本）
• Amazon EC2 Enhanced Networking 文件（ENA 與 EFA）
• Amazon CloudFront Developer Guide——Cache Policies、Origin Request Policies 和 Origin Shield 章節
• AWS Global Accelerator Developer Guide——Endpoints 和 Traffic Dials 章節
• AWS Transit Gateway 設計最佳實踐 Whitepaper
• AWS Direct Connect Resiliency Recommendations Whitepaper
• AWS PrivateLink Concepts and Scenarios

掌握高效能網路架構——ENA 與 EFA 的 Enhanced Networking、Cluster/Spread/Partition Placement Groups、搭配 Origin Shield 的 CloudFront、用於 TCP/UDP 的 Global Accelerator、大規模 Transit Gateway、搭配 LAG 和 SiteLink 的 Direct Connect，以及用於私有服務暴露的 PrivateLink——為你提供 SAA-C03 Task 3.4 反覆測試所需的工具箱。每個高效能網路架構情境都能化解為選擇正確的層：執行個體調校、邊緣加速、VPC 間路由或混合頻寬。熟記四大支柱、練習決策表，高效能網路架構的題目就能在考試當天成為穩定得分的來源。