Amazon ANS-C01: Load Balancing and Traffic Management — Study Guide
Part of the AWS Advanced Networking Specialty ANS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Core concept
Load balancing in AWS operates on two fundamental layers: L4 (transport) and L7 (application). Network Load Balancer (NLB) provides L4 (TCP/UDP/TLS) distribution and is optimized for extreme performance, preserving the client source IP and supporting millions of concurrent connections with very low latency and connection churn. Application Load Balancer (ALB) operates at L7 (HTTP/HTTPS/WebSocket and HTTP/2/gRPC), provides host- and path-based routing, header inspection, HTTP-based health checks, and cookie stickiness, and performs TLS termination when configured with certificates in ACM. Gateway Load Balancer (GWLB) is a purpose-built load balancer to scale third-party virtual appliances (firewalls, IDS/IPS) using the GENEVE encapsulation and Gateway Load Balancer endpoints (GWLBe), enabling inline traffic inspection without manual appliance scaling.
Listeners and listener rules are the L4/L7 entrypoints that map protocols/ports to target groups. A listener on an ALB can have complex rules that inspect host, path, headers, source IP CIDR, and forward to different target groups; ALB can also offload TLS (terminate) and present X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Port headers to targets. An NLB listener is typically a TCP/UDP/TLS listener that forwards traffic to target groups without parsing the payload (unless you enable TLS termination at the NLB): when using TCP passthrough you preserve end-to-end TLS so the backend must present and validate certificates for mutual TLS. Target groups are the binding between a load balancer listener and the set of endpoints (instance, IP, or Lambda), and they expose attributes such as health check protocol/port/path, deregistration delay (connection draining), and stickiness properties.
Key services and configuration
Choose the right balancer for the traffic characteristics and security requirements. Use ALB when you need host/path-based routing, HTTP/HTTPS features like WebSockets or HTTP/2/gRPC with application-aware routing, and cookie-based stickiness. Configure ALB listeners with CreateListener or via AWS::ElasticLoadBalancingV2::Listener, attach certificates from ACM, and set listener rules using CreateRule with conditions (Field=path-pattern, host-header, http-header). Enable stickiness on ALB target groups with ModifyTargetGroupAttributes setting Key=stickiness.enabled,Value=true and Key=stickiness.lb_cookie.duration_seconds,Value=<seconds> to use load-balancer-generated cookies.
Use NLB for high-throughput, long-lived TCP connections and when client source IP preservation is required at the backend. Create NLB with aws elbv2 create-load-balancer –name my-nlb –type network –subnets <subnet-ids> and add a TCP listener with aws elbv2 create-listener –load-balancer-arn <arn> –protocol TCP –port 443 –default-actions Type=forward,TargetGroupArn=<tg-arn>. For passthrough TLS and mTLS, configure the NLB listener as TCP so that TLS is terminated by the backend; set the target group to target-type ip when registering pod IPs for Kubernetes. Use ModifyTargetGroupAttributes to set Key=deregistration_delay.timeout_seconds,Value=<seconds> to allow connection draining; for NLB you can also enable source IP affinity (target group stickiness) where appropriate.
Gateway Load Balancer is configured with CreateLoadBalancer Type=gateway and backed by target groups of your appliance instances (or scale set in an autoscaling group), and uses a Gateway Load Balancer endpoint in consumer VPCs to steer traffic to the service VPC appliances. Use this pattern when you need transparent inspection and want appliances to scale with traffic automatically; create listeners on port 6081 (GENEVE encapsulation) and register the appliance ENIs in the GWLB target group.
Operational settings you must control programmatically include cross-zone load balancing, deregistration delay (connection draining), and health check tuning. For cross-zone balancing set attributes on the load balancer (aws elbv2 modify-load-balancer-attributes –load-balancer-arn <arn> –attributes Key=load_balancing.cross_zone.enabled,Value=true) to ensure traffic distribution across AZs rather than skewing per-AZ capacity. Set health check interval, timeout, and healthy/unhealthy thresholds on target groups to avoid flapping during autoscaling events.
Design patterns and trade-offs
For end-to-end TLS and mutual TLS (mTLS) where traffic must remain encrypted and client certificates must be presented to the backend, prefer L4 passthrough using NLB with TCP listeners. This keeps the TLS session intact so backends can validate client X.509 certs; configure target groups to use IP targets so Kubernetes pod IPs can be registered directly and the AWS Load Balancer Controller can manage target lifecycle. The trade-off is losing ALB L7 features such as host/path routing, Web Application Firewall integrations, and native HTTP cookie stickiness at the load balancer layer.
When you need content-based routing, TLS termination, and advanced HTTP features, use ALB and terminate TLS at the ALB (ACM-managed certificates). To retain client IP for logging and WAF rules, read the X-Forwarded-For header which ALB populates or use a layer that injects original client IP into headers. If you require the backend OS/network stack to see client IP at the socket level, use NLB (or enable Proxy Protocol to pass the original IP), but note that Proxy Protocol must be enabled on the target group and your application or proxy (for example, Envoy) must parse it.
Handling sticky sessions in an autoscaling environment requires careful consideration. ALB cookie stickiness can bind a client to a target for a duration, which can inhibit balanced scaling across pods if session traffic is heavy; alternative patterns include using short-duration stickiness combined with session state externalization to ElastiCache (Redis) or DynamoDB, or using a sidecar proxy (Envoy) to handle session affinity with consistent hashing. Connection draining (deregistration delay) is critical for graceful shutdown: set deregistration_delay.timeout_seconds to a duration longer than the longest RPC/HTTP request to avoid abrupt termination and client errors during pod termination; configure Kubernetes preStop hooks to coordinate pod lifecycle with deregistration.
GWLB is the appropriate pattern when you need scalable inline inspection across many VPCs and want centralized security controls. Combine GWLB with Transit Gateway or VPC peering architectures as necessary; the cost and operational complexity of appliance management are the trade-offs versus using managed services like AWS Network Firewall.
Common pitfalls and decision criteria
A frequent mistake is terminating TLS at the ALB without accounting for downstream needs for client authentication or original source IP. If backends require the client certificate or the true source IP at the TCP layer (for logging or authorization), terminate TLS at the backend via NLB passthrough or use Proxy Protocol and ensure the application parses it. Another common pitfall is enabling sticky sessions without external session storage while using Horizontal Pod Autoscaler: as pods scale out or in, sticky affinity may create hotspots and wasted capacity; prefer stateless backends or externalize session state.
Operational errors also arise from misconfigured health checks and deregistration delays that lead to request drops during scaling. Always set health check paths and thresholds to reflect application warm-up and use deregistration_delay.timeout_seconds to allow long-lived connections to drain. Cross-zone load balancing should be set intentionally: enabling it reduces tail latency and evens load but can increase cross-AZ data transfer costs; evaluate against AZ capacity and traffic patterns. Finally, GWLB introduces encapsulation (GENEVE) and appliance management overhead—automate appliance registration using the AWS APIs (CreateTargetGroup/RegisterTargets) and instrument with CloudWatch metrics to drive autoscaling policies.
Practical Problem: Use-Case Scenario
Company: Acme Telemetry. Challenge: Provide end-to-end encryption for a gRPC service (gRPC over TLS on TCP port 443) deployed in an Amazon EKS cluster, support thousands of concurrent long-lived connections, use Kubernetes Cluster Autoscaler and HPA, and require mutual TLS (mTLS) so that the client certificate is validated by the backend (i.e., traffic must not be decrypted by any intermediate load balancer).
Use-case implementation approach: Provision a Network Load Balancer with a TCP listener on port 443 and a target group of type “ip” pointing to pod IPs. Create the NLB with aws elbv2 create-load-balancer –name acme-nlb –type network –subnets
<subnet-ids>, create the target group with aws elbv2 create-target-group –name tg-grpc –protocol TCP –port 443 –target-type ip –vpc-id<vpc-id>, register targets via the AWS Load Balancer Controller annotations for Kubernetes (service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip”) so the controller registers pod IPs automatically, and create the listener with aws elbv2 create-listener –load-balancer-arn<arn>–protocol TCP –port 443 –default-actions Type=forward,TargetGroupArn=<tg-arn>. Set target group attribute deregistration_delay.timeout_seconds to an appropriate value (for example 300) using aws elbv2 modify-target-group-attributes to enable graceful draining.Backend TLS and mTLS configuration: Terminate TLS and perform mutual TLS in the pod layer. Deploy Envoy sidecars or have the gRPC servers accept TLS directly, storing server certificates and CA bundles in Kubernetes Secrets and mounted into the pod. Configure backends to validate client certificates against your CA and configure health checks to use TCP to avoid terminating TLS at the load balancer. Ensure HPA and Cluster Autoscaler lifecycle hooks coordinate with target group deregistration by implementing preStop hooks that allow pods to finish draining before exit.
Scalability and operational controls: Enable cross-zone load balancing on the NLB if required with aws elbv2 modify-load-balancer-attributes –load-balancer-arn
<arn>–attributes Key=load_balancing.cross_zone.enabled,Value=true to evenly distribute connections across AZs. Monitor concurrent connections and flow rates with CloudWatch metrics (NetworkPackets, ActiveFlowCount for NLB) and set autoscaling policies for the appliance (if using sidecar) and for worker nodes. Use ModifyTargetGroupAttributes for connection draining and tune health check intervals for quicker failure detection without flapping. Finally, automate certification rotation using AWS Secrets Manager and Kubernetes cert-manager integration.
AWS rationale: NLB in TCP mode preserves the TLS session end-to-end so the backend can perform mTLS validation; its L4 architecture is built for millions of concurrent flows and long-lived connections, and using target-type ip lets the AWS Load Balancer Controller register pod IPs directly, enabling HPA/Cluster Autoscaler to scale transparently. Connection draining (deregistration_delay) and health checks prevent request loss during pod termination, and cross-zone balancing ensures even distribution across AZs while trading off inter-AZ transfer cost for performance.
← DNS and Route 53 · All domains · Network Security and Compliance →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →