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），从而实现内联流量检测，无需手动扩展设备。

侦听器和侦听器规则是 L4/L7 的入口点，用于将协议/端口映射到目标组。ALB 上的侦听器可以拥有复杂的规则，用于检查主机、路径、标头、源 IP CIDR，并将流量转发到不同的目标组；ALB 还可以卸载 TLS（终止）并将 X-Forwarded-For、X-Forwarded-Proto 和 X-Forwarded-Port 标头呈现给目标。NLB 侦听器通常是 TCP/UDP/TLS 侦听器，它将流量转发到目标组而不解析负载（除非您在 NLB 上启用了 TLS 终止）：当使用 TCP 直通时，您会保留端到端的 TLS，因此后端必须为双向 TLS (mutual TLS) 提供并验证证书。目标组是负载均衡器侦听器与一组终端节点（实例、IP 或 Lambda）之间的绑定，它们公开了诸如健康检查协议/端口/路径、取消注册延迟（连接耗尽）和粘性属性等特性。

关键服务和配置

根据流量特性和安全要求选择合适的均衡器。当您需要基于主机/路径的路由、具有应用感知路由的 HTTP/HTTPS 功能（如 WebSockets 或 HTTP/2/gRPC）以及基于 Cookie 的粘性时，请使用 ALB。使用

undefined

或通过

undefined

配置 ALB 侦听器，附加来自 ACM 的证书，并使用带有条件（Field=path-pattern, host-header, http-header）的

undefined

设置侦听器规则。在 ALB 目标组上启用粘性，方法是使用

undefined

设置

undefined

和

undefined

，以使用负载均衡器生成的 Cookie。

当需要高吞吐量、长连接的 TCP 连接以及在后端保留客户端源 IP 时，请使用 NLB。使用

undefined

创建 NLB，并使用

undefined

添加 TCP 侦听器。对于直通 TLS 和 mTLS，将 NLB 侦听器配置为 TCP，以便 TLS 由后端终止；在为 Kubernetes 注册 Pod IP 时，将目标组的 target-type 设置为 ip。使用

undefined

设置

undefined

以允许连接耗尽；对于 NLB，您还可以在适当的情况下启用源 IP 亲和性（目标组粘性）。

Gateway Load Balancer 通过

undefined

进行配置，并由您的设备实例（或自动伸缩组中的规模集）的目标组支持，它在消费者 VPC 中使用 Gateway Load Balancer 端点将流量引导至服务 VPC 的设备。当您需要透明检测并希望设备随流量自动扩展时，请使用此模式；在端口 6081 (GENEVE 封装) 上创建侦听器，并在 GWLB 目标组中注册设备 ENI。

您必须以编程方式控制的操作设置包括跨区域负载均衡、取消注册延迟（连接耗尽）和健康检查调优。对于跨区域均衡，请在负载均衡器上设置属性（

undefined

），以确保流量在可用区之间均匀分布，而不是偏向于单个可用区的容量。在目标组上设置健康检查间隔、超时以及健康/不健康阈值，以避免在自动伸缩事件期间出现状态抖动（flapping）。

设计模式与权衡

对于需要流量保持加密且客户端证书必须呈现给后端的端到端 TLS 和双向 TLS (mTLS) 场景，首选使用带有 TCP 侦听器的 NLB 进行 L4 直通。这能保持 TLS 会话的完整性，以便后端可以验证客户端的 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（或启用代理协议来传递原始 IP），但请注意，必须在目标组上启用代理协议，并且您的应用程序或代理（例如 Envoy）必须能够解析它。

在自动扩展环境中处理粘性会话需要仔细考虑。ALB 的 Cookie 粘性可以在一段时间内将客户端绑定到特定目标，如果会话流量很大，这可能会阻碍跨 Pod 的均衡扩展；替代模式包括使用短期粘性，并结合将会话状态外部化到 ElastiCache (Redis) 或 DynamoDB，或使用边车代理（Envoy）通过一致性哈希来处理会话亲和性。连接耗尽（取消注册延迟）对于实现优雅关闭至关重要：将 deregistration_delay.timeout_seconds 设置为比最长的 RPC/HTTP 请求更长的时间，以避免在 Pod 终止期间发生突然中断和客户端错误；配置 Kubernetes 的 preStop 钩子，以协调 Pod 生命周期与取消注册过程。

当您需要在多个 VPC 之间进行可扩展的内联检查并希望实现集中式安全控制时，GWLB 是合适的模式。根据需要将 GWLB 与 Transit Gateway 或 VPC 对等连接架构相结合；与使用 AWS Network Firewall 等托管服务相比，其权衡之处在于设备管理的成本和运营复杂性。

常见陷阱和决策标准

一个常见的错误是在 ALB 终止 TLS，却没有考虑到下游对客户端身份验证或原始源 IP 的需求。如果后端需要在 TCP 层获取客户端证书或真实的源 IP（用于日志记录或授权），则应通过 NLB 直通在后端终止 TLS，或者使用 Proxy Protocol 并确保应用程序能够解析它。另一个常见的陷阱是在使用 Horizontal Pod Autoscaler 的同时启用了粘性会话，但没有使用外部会话存储：当 Pod 扩容或缩容时，粘性亲和性可能会造成热点和容量浪费；推荐使用无状态后端或将状态外部化。

配置不当的健康检查和注销延迟也会导致操作失误，从而在扩缩容期间造成请求丢失。务必设置能反映应用程序预热过程的健康检查路径和阈值，并使用 deregistration_delay.timeout_seconds 来允许长连接耗尽。应有目的地设置跨可用区负载均衡：启用它可以减少尾部延迟并均衡负载，但可能会增加跨可用区的数据传输成本；需要根据可用区容量和流量模式进行评估。最后，GWLB 引入了封装（GENEVE）和设备管理的开销——应使用 AWS API（CreateTargetGroup/RegisterTargets）自动化设备注册，并使用 CloudWatch 指标来驱动自动扩缩容策略。

实践问题：用例场景

公司：Acme Telemetry。挑战：为一个部署在 Amazon EKS 集群中的 gRPC 服务（在 TCP 443 端口上运行的 gRPC over TLS）提供端到端加密，支持数千个并发长连接，使用 Kubernetes Cluster Autoscaler 和 HPA，并要求双向 TLS (mTLS)，以便客户端证书由后端验证（即，流量不得被任何中间的负载均衡器解密）。

1. 用例实现方法：配置一个 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），以实现优雅耗尽。

2. 后端 TLS 和 mTLS 配置：在 Pod 层终止 TLS 并执行双向 TLS。部署 Envoy sidecar 或让 gRPC 服务器直接接受 TLS，将服务器证书和 CA 捆绑包存储在 Kubernetes Secrets 中并挂载到 Pod。配置后端根据您的 CA 验证客户端证书，并配置健康检查使用 TCP，以避免在负载均衡器上终止 TLS。通过实现 preStop 挂钩，确保 HPA 和 Cluster Autoscaler 的生命周期挂钩与目标组注销进行协调，允许 Pod 在退出前完成连接耗尽。

3. 可扩展性和操作控制：如果需要，使用 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 进行连接耗尽，并调整健康检查间隔以实现更快的故障检测，同时避免抖动。最后，使用 AWS Secrets Manager 和 Kubernetes cert-manager 集成来自动化证书轮换。

AWS 理由：TCP 模式下的 NLB 能够端到端地保留 TLS 会话，这样后端就可以执行 mTLS 验证；其 L4 架构专为数百万并发流和长连接而构建，并且使用 target-type ip 允许 AWS Load Balancer Controller 直接注册 Pod IP，使 HPA/Cluster Autoscaler 能够透明地进行扩缩容。连接耗尽（deregistration_delay）和健康检查可防止在 Pod 终止期间丢失请求，而跨可用区均衡可确保在各可用区之间均匀分配，同时以跨可用区传输成本换取性能。

← DNS 与 Route 53 · 所有领域 · 网络安全与合规性 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →