Amazon ANS-C01: 網路效能與監控 — 學習指南

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

屬於 AWS Advanced Networking Specialty ANS-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

增強型網路與低延遲架構

AWS 中的增強型網路 (Enhanced networking) 是一組作業系統 (OS) 和 hypervisor 層級的功能，能顯著提升每秒封包數 (packets-per-second)、降低延遲和 CPU 開銷，並為每個虛擬介面提供更高的吞吐量。主要技術有兩種：Elastic Network Adapter (ENA)，為大多數現代 EC2 執行個體系列提供基於 SR-IOV 的高效能網路；以及 Elastic Fabric Adapter (EFA)，這是一種繞過作業系統 (OS-bypass) 的類 RDMA 裝置，專為 HPC 和緊密耦合的 MPI/libfabric 工作負載而設計。要啟用 ENA，您需要確認執行個體類型支援 ENA 且 Linux AMI 具有 ENA 驅動程式；您也可以透過程式化方式啟用或查詢，例如在需要時使用 EC2 API 呼叫 RunInstances 搭配 InterfaceType=efa，或使用 ModifyInstanceAttribute 來支援 ena。EFA 的附加方式是建立一個 InterfaceType=efa 的網路介面 (aws ec2 create-network-interface --interface-type efa)，或是啟動帶有已啟用 EFA 的網路介面的執行個體；該執行個體必須執行支援的核心 (kernel) 和 libfabric/efa 核心模組，並且通常應放置在叢集置放群組 (cluster placement group) 中，以獲得最低的主機內延遲和最高的對分頻寬 (bisection bandwidth)。

置放群組 (Placement groups) 透過控制執行個體在底層網路架構中的位置來影響效能。叢集 (cluster) 置放群組會將執行個體偏向放置在單一機架或低延遲的網路域中，以實現最大的東西向頻寬和一致的延遲——這對許多 EFA 使用案例是必要的。分散 (spread) 置放群組會強制執行主機層級的分散，以避免關聯性故障，但不會改善延遲。對於突發性高吞吐量的情境，執行個體系列和 vCPU 數量定義了基準的網路頻寬配額；例如，某些執行個體大小宣稱高達 25 Gbps 或 100 Gbps，但若沒有 ENA/EFA，封包處理和 TCP 堆疊可能會成為瓶頸。當為數千個並行 TCP 連線（例如，gRPC over TLS）進行架構設計時，應選擇具有高並行連線容量的執行個體類型、啟用 ENA，並且在 EKS 中執行時，優先選擇 NLB / target-type=ip 以進行直接的 pod 定址，從而避免節點連接埠 (node port) 的瓶頸。

可觀測性與強制執行的關鍵服務與組態

監控網路健康狀況和診斷瓶頸，需要結合使用 VPC Flow Logs、CloudWatch 指標、Traffic Mirroring 以及 Reachability/Access 分析器。VPC Flow Logs 提供每個流量的元數據 (metadata)（來源/目的地 IP、連接埠、封包數、位元組數、動作），您可以將這些日誌傳送到 CloudWatch Logs 或 S3，並使用 CloudWatch Logs Insights 進行查詢，以找出高流量的字首 (prefix) 或「頭號發話者」(top talkers)。若要進行即時的封包層級檢測，Traffic Mirroring 允許您建立一個鏡像目標 (mirror target) 和一個篩選器，然後建立會話 (session) (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session)，將來自 ENI 的流量複製到在 EC2 中執行的檢測設備，或複製到 AWS Network Packet Broker 的合作夥伴。

CloudWatch 為不同層級提供了相關指標：EC2 執行個體指標，如 NetworkIn/NetworkOut 和 NetworkPacketsIn/NetworkPacketsOut；AWS/ApplicationELB 下的 Application Load Balancer 指標，如 RequestCount、ActiveConnectionCount 和 ClientTLSNegotiationErrorCount；AWS/NetworkELB 下的 Network Load Balancer 指標，如 ProcessedBytes 和 NewFlowCount；以及 AWS/DirectConnect 的虛擬介面指標 BytesIn/BytesOut。使用 CloudWatch Alarms 和針對流量日誌的 Contributor Insights 來偵測飽和的流量。為了進行路徑和組態驗證，Reachability Analyzer（透過 EC2 API StartNetworkInsightsAnalysis / CreateNetworkInsightsPath）讓您能夠模擬和測試穿越路由表、NACL、安全群組以及 VPN/Direct Connect 附件的端到端封包路徑，而 Network Access Analyzer 則有助於偵測跨越您的 VPC 和 AWS Organizations 的非預期網路存取路徑。

關於負載平衡與安全存取的設計模式與權衡取捨

當您需要在後端實現真正的端對端 TLS 與相互 TLS (mutual TLS)，同時支援數千個 gRPC 連線時，使用 TCP 模式的 Network Load Balancer 是偏好的模式。NLB 預設會保留用戶端的來源 IP，並且可以透過 AWS Load Balancer Controller 為 EKS 服務建立，方法是使用諸如 service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" 和 target-type=ip 等註解，以將流量直接傳送到 pod 的 IP。在 443 連接埠上使用 TCP 通透 (passthrough) 意味著後端 pod 會終止相互 TLS (用戶端與伺服器憑證驗證)，因此流量永遠不會在負載平衡器中解密，從而保留了雙向驗證。此模式能良好地擴展連線數量，因為 NLB 專為數百萬個並行連線和低單一連線開銷而設計。

對於需要在負載平衡器終止 TLS 並進行到多個目標群組的路徑式路由的架構，Application Load Balancer 是正確的選擇，因為它支援 HTTP/2 和 gRPC、路徑式路由以及主機式規則。為了在 ALB 終止 TLS 時提供準確的用戶端 IP 記錄，請確保後端應用程式能解析 X-Forwarded-For 標頭 (ALB 會自動注入)，或者如果您需要在 TCP 層保留來源 IP，請搭配 NLB 使用 PROXY protocol。如果您使用 Global Accelerator 來提供靜態 anycast 前端 IP，並希望防止用戶端繞過加速器直接存取 ALB 的 URL，請鎖定 ALB 的安全群組，使其僅接受來自加速器靜態 IP (分配給加速器的兩個靜態位址) 的傳入流量，如此一來，直接的網際網路存取就會被拒絕。

對於具有嚴格按業務單位控制與擴展需求的多帳戶共享服務，AWS PrivateLink (由內部 NLB 支援的 VPC Endpoint Services) 通常是最安全且可擴展的模式。共享服務 VPC 透過 Network Load Balancer 端點 (

undefined

搭配目標群組) 發布服務，並將其公開為 VPC Endpoint Service。消費者帳戶在其 VPC 中建立介面端點，以附加到提供者的 NLB；提供者透過端點政策和安全群組來控制存取，且流量永遠不會經過集中的路由平面。當您需要完整的路由可見性和可轉移的連線能力時，Transit Gateway 是合適的選擇，但它會集中化路由，且在每個服務的存取控制方面，其粒度不如 PrivateLink。

常見的陷阱與決策標準

一個常見的錯誤是假設執行個體的公告頻寬是無限的；執行個體系列和大小會設定硬性的網路限制，擴展時應考慮將流量分散到多個 ENI，並將執行個體放置在叢集置放群組中，以獲得一致的效能。另一個陷阱是，僅依賴 CloudWatch 的 NetworkIn/NetworkOut，而未與 VPC Flow Logs 關聯以將流量歸因於特定的 VPC、子網路或業務單位；必須使用 Flow Logs 和 Traffic Mirroring 來隔離是哪個虛擬介面或應用程式造成 Direct Connect 飽和。此外，當需要端對端相互 TLS 時，應避免在 ALB 上終止 TLS——如果政策要求後端必須看到用戶端憑證，請選擇使用 NLB 進行 TLS Passthrough，或執行 TLS 橋接並進行適當的憑證驗證，但要明確指出信任的建立點。

在診斷像 Direct Connect 這類共享實體線路上的間歇性飽和問題時，請關聯跨層級的指標：AWS/DirectConnect 的虛擬介面指標、VPC Flow Logs 的每個子網路/ENI 的位元組計數，以及 EC2 的 Network* 指標以了解執行個體層級的行為。使用 Reachability Analyzer 來驗證非對稱路由或錯誤的路由傳播是否造成回程路徑問題，並使用 Traffic Mirroring 擷取封包以進行深度協定檢測。

實務問題：使用情境

AcmeIoT 面臨一個問題：全球的自動販賣機必須透過 gRPC 與相互 TLS 連線至一個 EKS 上託管的後端，連線數量必須達到數千個，服務必須保持端對端加密，且後端 pod 會透過 Cluster Autoscaler 和 HPA 動態擴展。

為 Kubernetes Service 建立一個類型為 Network Load Balancer 的 AWS LoadBalancer，使用 AWS Load Balancer Controller 和註解來指定 NLB 和 target-type=ip (service.beta.kubernetes.io/aws-load-balancer-type: “nlb” 和 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: “ip”)。在 443 埠上設定一個 TCP 接聽器，讓 NLB 執行純粹的 TCP Passthrough；不要在 NLB 上設定 TLS 憑證。
在應用程式 pod 中實作相互 TLS 終止與驗證。每個 pod 都應提供伺服器憑證並驗證用戶端憑證，使用與 AWS Secrets Manager 或 SSM Parameter Store 整合的短期憑證輪換流程。使用 target-type ip 確保 pod IP 可被連線，並在目標群組上設定 TCP 或 gRPC 健康狀態檢查。
選擇具有 ENA 支援和足夠網路頻寬的執行個體，以確保高連線擴展性，啟用 ENA (確認 AMI 中有 ENA 驅動程式，並在需要時使用 aws ec2 modify-instance-attribute 來啟用 ena-support)，並使用 Cluster Autoscaler 根據 pod 請求來擴展節點，將 pod 部署到多個節點上。對於需要一致延遲的緊密耦合叢集，請使用置放群組，並在多個可用區域 (AZ) 中部署足夠數量的節點。
使用 CloudWatch 和 VPC Flow Logs 進行監控與驗證。為 NLB 的 ActiveFlowCount/NewFlowCount 和 EKS 工作節點 EC2 的 NetworkIn/Out 建立 CloudWatch 指標和警報。使用 VPC Flow Logs 來識別任何的 top-talkers (流量大戶)，並使用 Reachability Analyzer (StartNetworkInsightsAnalysis/CreateNetworkInsightsPath) 在自動擴展事件期間驗證路由路徑。若需要封包層級的偵錯，請建立 Traffic Mirroring 會話將流量導向一個檢測執行個體。

AWS 的理由：TCP 模式下的 Network Load Balancer 會保留來源 IP、支援大量並行連線，且因為它不終止 TLS，所以允許端對端 TLS。搭配 AWS Load Balancer Controller 使用 target-type ip 能與 EKS 的自動擴展語意整合，因此新的 pod IP 會被動態註冊為目標。ENA 和適當的執行個體大小提供了處理數千個並行 TLS 連線所需的原始網路容量，而不會耗盡主機的 CPU，而 CloudWatch、VPC Flow Logs、Reachability Analyzer 和 Traffic Mirroring 的組合提供了偵測和修復飽和或路由問題所需的可觀測性。

← 內容交付與邊緣網路 · 所有領域 · 自動化、IaC 與網路營運 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →