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 的負載平衡在兩個基本層級上運作：L4 (傳輸層) 和 L7 (應用層)。Network Load Balancer (NLB) 提供 L4 (TCP/UDP/TLS) 的流量分發，並為極致效能進行了優化，能保留用戶端的來源 IP，並以極低的延遲和連線流失率支援數百萬個並行連線。Application Load Balancer (ALB) 在 L7 (HTTP/HTTPS/WebSocket 和 HTTP/2/gRPC) 運作，提供基於主機和路徑的路由、標頭檢測、基於 HTTP 的運作狀態檢查和 cookie 黏性，並在設定了 ACM 中的憑證時執行 TLS 終止。Gateway Load Balancer (GWLB) 是一種專門打造的負載平衡器，用於透過 GENEVE 封裝和 Gateway Load Balancer 端點 (GWLBe) 來擴展第三方虛擬設備 (如防火牆、IDS/IPS)，從而實現線上流量檢測，無需手動擴展設備。

接聽器 (Listener) 和接聽器規則 (listener rule) 是 L4/L7 的進入點，負責將協定/連接埠對應到目標群組 (target group)。ALB 上的接聽器可以有複雜的規則，用以檢測主機、路徑、標頭、來源 IP CIDR，並將流量轉送到不同的目標群組；ALB 還可以卸載 TLS (終止)，並向目標提供 X-Forwarded-For、X-Forwarded-Proto 和 X-Forwarded-Port 標頭。NLB 的接聽器通常是 TCP/UDP/TLS 接聽器，它會將流量轉送到目標群組而不解析其酬載 (除非您在 NLB 上啟用 TLS 終止)：當使用 TCP 通透 (passthrough) 時，您會保留端對端的 TLS，因此後端必須提供並驗證憑證以進行相互 TLS (mutual TLS)。目標群組是負載平衡器接聽器與一組端點 (執行個體、IP 或 Lambda) 之間的綁定，並公開諸如運作狀態檢查的協定/連接埠/路徑、取消註冊延遲 (連線耗盡) 和黏性屬性等設定。

主要服務與設定

根據流量特性和安全性需求選擇合適的負載平衡器。當您需要基於主機/路徑的路由、具備應用程式感知路由的 HTTP/HTTPS 功能 (如 WebSockets 或 HTTP/2/gRPC)，以及基於 cookie 的黏性時，請使用 ALB。使用 CreateListener 或透過 AWS::ElasticLoadBalancingV2::Listener 來設定 ALB 接聽器，附加來自 ACM 的憑證，並使用帶有條件 (Field=path-pattern, host-header, http-header) 的 CreateRule 來設定接聽器規則。在 ALB 目標群組上啟用黏性，可透過 ModifyTargetGroupAttributes 設定 Key=stickiness.enabled,Value=true 和 Key=stickiness.lb_cookie.duration_seconds,Value=<seconds> 來使用負載平衡器產生的 cookie。

當需要高吞吐量、長時間存在的 TCP 連線，以及需要在後端保留用戶端來源 IP 時，請使用 NLB。使用 aws elbv2 create-load-balancer --name my-nlb --type network --subnets <subnet-ids> 建立 NLB，並使用 aws elbv2 create-listener --load-balancer-arn <arn> --protocol TCP --port 443 --default-actions Type=forward,TargetGroupArn=<tg-arn> 新增一個 TCP 接聽器。對於通透 TLS 和 mTLS，請將 NLB 接聽器設定為 TCP，以便 TLS 由後端終止；在為 Kubernetes 註冊 pod IP 時，將目標群組設定為 target-type ip。使用 ModifyTargetGroupAttributes 來設定 Key=deregistration_delay.timeout_seconds,Value=<seconds> 以允許連線耗盡；對於 NLB，您也可以在適當情況下啟用來源 IP 親和性 (目標群組黏性)。

Gateway Load Balancer 是透過 CreateLoadBalancer Type=gateway 進行設定，並由您的設備執行個體 (或自動擴展群組中的擴展集) 的目標群組支援，它使用消費者 VPC 中的 Gateway Load Balancer 端點將流量導向服務 VPC 的設備。當您需要透明檢測並希望設備能隨流量自動擴展時，請使用此模式；在連接埠 6081 (GENEVE 封裝) 上建立接聽器，並在 GWLB 目標群組中註冊設備的 ENI。

您必須以程式化方式控制的操作設定包括跨區域負載平衡、取消註冊延遲 (連線耗盡) 和運作狀態檢查的調校。對於跨區域負載平衡，請在負載平衡器上設定屬性 (aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> --attributes Key=load_balancing.cross_zone.enabled,Value=true)，以確保流量能跨可用區域 (AZ) 分配，而不是偏向單一 AZ 的容量。在目標群組上設定運作狀態檢查的間隔、逾時以及健康/不健康閾值，以避免在自動擴展事件期間發生狀態抖動 (flapping)。

設計模式與權衡取捨

對於需要端對端 TLS 與相互 TLS (mTLS) 的情境，也就是流量必須保持加密，且客戶端憑證必須呈現給後端，建議優先採用 NLB 搭配 TCP 接聽器的 L4 passthrough 模式。這樣可以保持 TLS session 的完整性，讓後端能夠驗證客戶端的 X.509 憑證；設定目標群組使用 IP 目標，如此一來 Kubernetes pod 的 IP 就能直接被註冊，並由 AWS Load Balancer Controller 管理目標的生命週期。權衡之下，缺點是會失去 ALB 的 L7 功能，例如在負載平衡器層級的主機/路徑路由、Web Application Firewall 整合，以及原生的 HTTP cookie 黏性。

當您需要基於內容的路由、TLS 終止以及進階的 HTTP 功能時，請使用 ALB 並在 ALB 上終止 TLS (使用 ACM 管理的憑證)。為了在日誌記錄和 WAF 規則中保留客戶端 IP，可以讀取 ALB 填入的 X-Forwarded-For 標頭，或使用某個層級將原始客戶端 IP 注入到標頭中。如果您要求後端的作業系統/網路堆疊必須在 socket 層級看到客戶端 IP，請使用 NLB (或啟用 Proxy Protocol 來傳遞原始 IP)，但請注意，Proxy Protocol 必須在目標群組上啟用，且您的應用程式或代理 (例如 Envoy) 必須能夠解析它。

在自動擴展的環境中處理黏性會話 (sticky sessions) 需要謹慎考量。ALB 的 cookie 黏性可以將客戶端在一段時間內綁定到特定目標，但如果會話流量很大，這可能會妨礙 pod 之間的平衡擴展；替代模式包括使用短時間的黏性，並結合將會話狀態外部化到 ElastiCache (Redis) 或 DynamoDB，或是使用 sidecar 代理 (例如 Envoy) 透過一致性雜湊 (consistent hashing) 來處理會話親和性 (session affinity)。連線耗盡 (Connection draining，即取消註冊延遲) 對於優雅關閉 (graceful shutdown) 至關重要：將 deregistration_delay.timeout_seconds 設定為比最長的 RPC/HTTP 請求更長的時間，以避免在 pod 終止期間發生突然中斷和客戶端錯誤；設定 Kubernetes 的 preStop hook 來協調 pod 的生命週期與取消註冊的過程。

當您需要在多個 VPC 之間進行可擴展的內聯檢測 (inline inspection) 並希望集中化安全控制時，GWLB 是合適的模式。必要時可將 GWLB 與 Transit Gateway 或 VPC peering 架構結合使用；與使用像 AWS Network Firewall 這類的託管服務相比，其權衡取捨在於設備管理的成本和營運複雜性。

常見陷阱與決策標準

一個常見的錯誤是在 ALB 上終止 TLS，卻沒有考慮到下游對用戶端驗證或原始來源 IP 的需求。如果後端需要在 TCP 層取得用戶端憑證或真實的來源 IP（用於日誌記錄或授權），就應該透過 NLB passthrough 在後端終止 TLS，或使用 Proxy Protocol 並確保應用程式能解析它。另一個常見的陷阱是在使用 Horizontal Pod Autoscaler 的同時，啟用黏性會話 (sticky sessions) 卻沒有外部的會話儲存：當 Pod 擴展或縮減時，黏性關聯可能會產生熱點和容量浪費；建議優先採用無狀態的後端或將會話狀態外部化。

操作上的錯誤也可能源於設定不當的健康狀態檢查和取消註冊延遲，這會導致在擴展期間發生請求丟失。務必設定能反映應用程式暖機時間的健康狀態檢查路徑和閾值，並使用 deregistration_delay.timeout_seconds 來讓長時間連線能夠優雅地排空 (drain)。跨可用區負載平衡 (Cross-zone load balancing) 應經過審慎評估後設定：啟用它可以減少尾部延遲 (tail latency) 並使負載更均勻，但可能會增加跨可用區的資料傳輸成本；應根據可用區容量和流量模式進行評估。最後，GWLB 引入了封裝 (GENEVE) 和設備管理的額外負擔——應使用 AWS API (CreateTargetGroup/RegisterTargets) 自動化設備註冊，並透過 CloudWatch 指標來驅動自動擴展策略。

實務問題：使用案例情境

公司：Acme Telemetry。挑戰：為部署在 Amazon EKS 叢集中的 gRPC 服務（在 TCP 443 埠上運行的 gRPC over TLS）提供端到端加密，支援數千個並行的長時間連線，使用 Kubernetes Cluster Autoscaler 和 HPA，並要求相互 TLS (mTLS)，以便用戶端憑證由後端進行驗證（也就是說，流量不得被任何中間的負載平衡器解密）。

使用案例實作方法：佈建一個 Network Load Balancer，其 TCP 監聽器設定在 443 埠，並搭配一個類型為 “ip” 且指向 Pod IP 的目標群組。使用 aws elbv2 create-load-balancer --name acme-nlb --type network --subnets <subnet-ids> 建立 NLB，使用 aws elbv2 create-target-group --name tg-grpc --protocol TCP --port 443 --target-type ip --vpc-id <vpc-id> 建立目標群組，透過 Kubernetes 的 AWS Load Balancer Controller 註解 (service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip") 來註冊目標，這樣控制器就會自動註冊 Pod IP，然後使用 aws elbv2 create-listener --load-balancer-arn <arn> --protocol TCP --port 443 --default-actions Type=forward,TargetGroupArn=<tg-arn> 建立監聽器。使用 aws elbv2 modify-target-group-attributes 將目標群組屬性 deregistration_delay.timeout_seconds 設定為一個適當的值（例如 300），以啟用優雅排空 (graceful draining)。
後端 TLS 與 mTLS 設定：在 Pod 層終止 TLS 並執行相互 TLS。部署 Envoy sidecar，或讓 gRPC 伺服器直接接受 TLS，並將伺服器憑證和 CA 套件儲存在 Kubernetes Secrets 中，再掛載到 Pod 裡。設定後端根據您的 CA 來驗證用戶端憑證，並將健康狀態檢查設定為使用 TCP，以避免在負載平衡器上終止 TLS。透過實作 preStop 掛鉤，確保 HPA 和 Cluster Autoscaler 的生命週期掛鉤 (lifecycle hooks) 與目標群組的取消註冊協同運作，讓 Pod 在退出前能完成連線排空。
擴展性與操作控制：如有需要，可使用 aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> --attributes Key=load_balancing.cross_zone.enabled,Value=true 在 NLB 上啟用跨可用區負載平衡，以將連線均勻分佈到各個可用區。使用 CloudWatch 指標（NLB 的 NetworkPackets、ActiveFlowCount）監控並行連線數和流量速率，並為設備（如果使用 sidecar）和工作節點設定自動擴展策略。使用 ModifyTargetGroupAttributes 進行連線排空，並調整健康狀態檢查的間隔，以實現更快速的故障偵測且不產生抖動 (flapping)。最後，使用 AWS Secrets Manager 和 Kubernetes cert-manager 整合來自動化憑證輪替。

AWS 理由：NLB 在 TCP 模式下會端到端地保留 TLS 會話，因此後端可以執行 mTLS 驗證；其 L4 架構是為數百萬個並行流量和長時間連線而設計的，而使用 target-type ip 讓 AWS Load Balancer Controller 能直接註冊 Pod IP，使 HPA/Cluster Autoscaler 能夠透明地擴展。連線排空 (deregistration_delay) 和健康狀態檢查可防止在 Pod 終止期間發生請求遺失，而跨可用區平衡則確保了負載在各可用區間的均勻分佈，同時在可用區間的傳輸成本與效能之間做出權衡。

← DNS 與 Route 53 · 所有領域 · 網路安全與合規性 →

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