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.

EKS 網路 (CNI、Pod 網路)

Amazon EKS 中的 Pod 網路主要由 Amazon VPC CNI plugin (amazon-vpc-cni-k8s) 主導，它為每個 Pod 分配一個來自 VPC 的 IP 位址，並將 Pod 流量直接置於 VPC 網路上。這種設計提供了可預測的 VPC 層級安全控制（安全群組、NACLs）和低延遲路由，但需要仔細的 IP 位址和 ENI 容量規劃，因為每個 ENI 的次要 IPv4 位址數量以及每個執行個體類型的 ENI 數量都受到硬體限制。aws-node daemonset 負責驅動 IP 分配和附加/分離操作；其 ConfigMap 可透過 kubectl 編輯以調整行為（例如，設定

undefined

、

undefined

或

undefined

）。前綴委派 (Prefix delegation) 和 Pod ENI 模式可以透過讓節點將整個 /28 前綴分配給一個 ENI (

undefined

)，或為每個 Pod 分配一個專用 ENI（適用於高安全性隔離），來減少每個節點的 IP 耗盡問題。

Amazon VPC CNI 的替代方案，如 Cilium (eBPF) 或 Calico，可以提供不同的權衡。Cilium 可以取代 kube-proxy 並使用 eBPF 實現高效能的 L3/L4 轉送，啟用節點之間的透明加密（WireGuard 或 IPsec），並透過使用覆蓋 (overlay) 或偽裝 (masquerading) 方法來減少節點層級的 IP 壓力。使用 Cilium，您仍然可以與 VPC 路由整合以處理輸出 (egress) 和輸入 (ingress) 流量，但可以避免頻繁的 ENI 附加/分離操作；這在高 Pod 流動率下尤為重要。對於非常高的連線數和嚴格的 L7 行為，您還應考慮調整 kube-proxy 模式 (IPVS) 和節點核心設定：調整

undefined

、

undefined

和

undefined

，並透過 kubelet 或 daemonset init 指令碼公開這些設定，以避免在數千個並行長時間存活的 gRPC 連線下發生臨時埠耗盡的問題。

ECS 網路模式與 Lambda VPC 整合

ECS 任務網路有三種主要模式：bridge、host 和 awsvpc。awsvpc 模式與 Kubernetes Pod 網路最為相似，因為它為每個任務（或任務群組）附加一個 ENI，並直接為任務分配一個私有 IP 和安全群組。透過在

undefined

或

undefined

API 呼叫中指定帶有

undefined

和

undefined

的

undefined

來設定 awsvpc。Fargate 強制使用 awsvpc，因此提供任務層級的網路隔離，並與 AWS Cloud Map 整合以進行服務探索。當您需要基於安全群組的每個任務的流量過濾，或者需要公開標準的 VPC 路由和指標時，請使用 awsvpc。

需要存取 VPC 的 Lambda 函數會透過在其設定的子網路和安全群組中的 ENI 附加到 VPC。這些 ENI 由 Lambda 控制平面建立和管理，但 ENI 的佈建可能會增加冷啟動延遲，並且在歷史上限制了快速擴展，除非透過預置並行 (provisioned concurrency) 或使用 VPC 端點 (AWS PrivateLink) 和精心設計的子網路架構來緩解。在 VPC 中放置許多 Lambda 函數時，請確保子網路有可用的 IP，視需要使用 NAT Gateway 或 NAT 執行個體進行輸出流量 (egress)，並盡可能優先使用 VPC 端點 (透過

undefined

的

undefined

端點) 以避免將輸出流量路由到網際網路。使用 CloudWatch Logs 和 VPC Flow Logs 監控 ENI 的附加/分離，以觀察擴展行為並對與並行相關的節流問題進行疑難排解。

App Mesh 與服務探索

AWS App Mesh 使用 Envoy sidecar 作為資料平面，並提供 L3–L7 可觀測性、流量塑形、重試和 TLS 發起/終止控制。透過 App Mesh API (

undefined

、

undefined

、

undefined

) 或適用於 Kubernetes 的 App Mesh 控制器來定義網格 (mesh)、虛擬節點 (virtual node) 和虛擬服務 (virtual service)。App Mesh 透過設定 VirtualNode 接聽程式的 TLS 區塊與

undefined

和憑證授權機構來支援 mTLS，並且您可以與 AWS Certificate Manager (ACM) 或 SDS 整合以進行憑證分發。但是，請注意，App Mesh sidecar 的設計是終止並重新加密流量；如果要求規定應用程式流量在用戶端和應用程式 Pod 之間必須保持端到端加密（不在網路代理中解密），您必須確保 TLS 僅在 Pod 處終止，並避免在網格入口 (ingress) 或負載平衡器處終止它。

服務探索通常對於 EKS 是使用 Kubernetes Services 和 CoreDNS，對於跨平台是使用 Cloud Map (

undefined

、

undefined

)，對於基於 DNS 的查詢是使用 Route 53 私有託管區域。AWS Cloud Map 直接與 ECS 和 App Mesh 整合，啟用 SRV 或 A 記錄以及 API 驅動的健康檢查。對於執行個體快速擴展的動態環境，結合短的 DNS TTL 和 Cloud Map 健康檢查以避免過時的解析結果；如果您需要即時一致性，請使用服務網格控制平面 API 來獲取端點，而不是依賴 DNS 快取。

設計模式與權衡取捨

在設計大規模、使用 TLS 與 mTLS 的 gRPC 時，您必須決定 TLS 在何處終止。在負載平衡器 (ALB) 上終止 TLS，可以將憑證卸載到 ACM 並簡化憑證輪換，但這會破壞端對端加密，並且除非後端使用轉發的用戶端憑證資訊重新建立 TLS，否則無法為後端 Pod 提供相互 TLS。若要實現真正的端對端 mTLS，讓應用程式端點直接驗證用戶端，請使用 L4 passthrough 閘道，例如 Network Load Balancer，並讓 Pod/應用程式處理 TLS/mTLS。將 NLB 的 target-type ip 與 AWS Load Balancer Controller 的註解 service.beta.kubernetes.io/aws-load-balancer-target-type: “ip” 結合使用，可直接註冊 Pod 的 IP；此模式擴展性良好，因為 NLB 專為數百萬個連線而設計，並支援長期的 TCP/gRPC 會話而無需終止 TLS。

對於需要 HTTPS 終止的 Ingress 和基於路徑的路由，Application Load Balancer 更為合適，因為它支援主機/路徑規則、重新導向以及與 WAF 的整合。當 ALB 終止 TLS 時，若要保留用戶端 IP，請依賴 X-Forwarded-For 標頭；後端 Web 伺服器必須取用並記錄 X-Forwarded-For，且您應啟用 ALB 存取日誌以供驗證。如果您需要在伺服器層取得真實的用戶端 socket 位址（例如為了舊版軟體），請使用帶有 proxy protocol v2 的 NLB，並確保後端服務支援 proxy protocol。

跨多個 AWS 帳戶和 VPC 的服務連線能力，會根據不同的模式而有不同的擴展方式。VPC peering 很簡單，但在管理上是 N^2 的複雜度；Transit Gateway 可集中化路由，並透過路由表隔離為多個 VPC 提供更好的擴展性；AWS PrivateLink (Interface VPC Endpoints) 則提供最精細的、針對每個服務且具身份感知能力的存取模型，因為您是透過 NLB 暴露端點服務，而消費者在其 VPC 中建立介面端點。對於需要嚴格存取控制和可擴展上線流程的多帳戶共享服務，應優先選擇 PrivateLink，因為它能隔離路由（消費者 VPC 中的路由表無需變更），並使用安全群組進行精細的控制。

常見的陷阱與決策標準

一個常見的陷阱是假設同一種網路模型適用於所有工作負載。有狀態或長連線的工作負載（如 gRPC、資料庫）偏好使用 L4 passthrough (NLB)，並在 pod 層級進行 TLS 終止，或使用 hostPort/hostNetwork 模式來避免代理伺服器造成的延遲；而需要基於路徑的路由、WAF 或 WebSocket 終止的 HTTP 微服務，則能從 ALB 和 App Mesh 的功能中獲益。另一個錯誤是，在 awsvpc 模式下擴展 EKS 節點或 ECS 任務時，沒有考慮到 ENI/IP 的限制：務必參考 EC2 執行個體類型的 ENI 和每個 ENI 的 IP 數量表，並在需要高 pod 密度時使用 prefix delegation 或 Cilium overlays。

監控與偵錯需要多種來源的資訊：VPC Flow Logs 和 ENI 指標可用來查看流量的出口/入口，CloudWatch 上的 AWS Load Balancers 指標（如 ActiveFlowCount、ProcessedBytes）以及來自 Envoy/App Mesh 或 AWS X-Ray agent 的應用程式層級遙測資料。對於 Lambda 和 Fargate，請記住，與 ENI 操作相關的冷啟動問題可以透過 provisioned concurrency 來緩解，或透過重新架構存取模式來使用 VPC 端點和 PrivateLink，這樣函式就不需要廣泛的出口存取權限。

實務問題：使用情境範例

公司名稱：Acme Payments Inc. 挑戰：Acme Payments 在 Amazon EKS 上運行一個 gRPC 服務，該服務必須在 TCP 443 埠上支援數千個並行的 TLS 連線，使用相互 TLS (mTLS) 以便後端服務能驗證客戶端憑證，並允許 EKS 叢集透過 Cluster Autoscaler 和 HPA 自動擴展，且不會中斷連線或需要在負載平衡器中終止 TLS。

編號方法：

在應用程式中或在一個不會為外部客戶端終止端到端 TLS 的 sidecar 中，實作 pod 層級的 TLS 和相互驗證來部署服務。將伺服器/客戶端憑證儲存在 AWS Secrets Manager 中，並透過 Kubernetes CSI secrets store 掛載，或使用與 pod 生命週期相容的憑證分發機制。
使用 AWS Load Balancer Controller，透過標註 Service (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”) 來建立一個 Network Load Balancer，並將目標類型設定為 IP (service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”)，然後在 443 埠上建立一個 TCP listener。這確保了 NLB 執行 L4 passthrough 且不終止 TLS。
設定 NLB target group 的協定為 TCP，並動態註冊 pod IP（Load Balancer Controller 將會呼叫 CreateTargetGroup 和 RegisterTargets）。確保健康檢查設定為 TCP 或一個自訂的、基於 TCP 的健康探測，並設定較短的間隔，以便在自動擴展期間能快速將目標標記為健康 (aws elbv2 create-target-group –protocol TCP –port 443 –target-type ip; aws elbv2 create-listener –protocol TCP –port 443 …)。
調整 Amazon VPC CNI 以支援高 pod 密度並減少 ENI 的變動：如果支援，啟用 prefix delegation（在 aws-node ConfigMap 中設定 ENABLE_PREFIX_DELEGATION=true），設定 WARM_IP_TARGET 來維持備用 IP 位址，並監控 aws-node 的指標（kube-system daemonset 的日誌和 CloudWatch 自訂指標）。如果節點層級的 IP 限制是個問題，可以考慮使用 Cilium 搭配 eBPF 來獲得更高的 pod 密度並減少 ENI 操作。
安全地擴展叢集：確保 Cluster Autoscaler 具有正確的節點群組標籤和 IAM 權限，設定 PodDisruptionBudgets，並驗證 target group 的健康檢查和 NLB 的連線清空（connection draining）已設定妥當，以避免在縮減規模時丟失長時間存在的 gRPC 連線。
確保憑證輪替與信任：使用 ACM Private CA 或 Secrets Manager 自動化憑證輪替，並確保 pod 在不需要重新設定 NLB 的情況下，能取得更新的信任捆綁包（trust bundles）。使用能反映 mTLS 交握準備就緒狀態的 Kubernetes readiness/liveness 探測。

AWS 的理由：在 IP 目標模式下的 Network Load Balancer 會將 TLS 保留到 pod（實現真正的端到端加密），並支援數百萬個持久性 TCP 連線，使其非常適合處理數千個並行的 gRPC 會話。直接註冊 pod IP 避免了每個節點上 hostPort 或 instance 目標註冊的複雜性，並且能與 Cluster Autoscaler/HPA 完美配合，因為 AWS Load Balancer Controller 會隨著 pod 的擴展自動註冊和取消註冊 pod IP。調整 VPC CNI 或採用基於 eBPF 的資料平面可以防止 IP 耗盡並減少 ENI 附加/分離的延遲，這對於快速自動擴展和高連線數的工作負載至關重要。透過 Secrets Manager 或 CSI provider 儲存和交付 mTLS 相關成品，使得憑證的生命週期管理變得容易，且無需更動負載平衡器。

← 自動化、IaC 與網路營運 · 所有領域

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