Load Balancers

Elastic Load Balancing distributes incoming traffic across multiple targets. AWS offers three load balancer types, each optimized for different protocols and use cases.

Application Load Balancer (ALB) operates at layer 7 (application layer) and handles HTTP, HTTPS, gRPC, and WebSocket traffic. It inspects request content including headers, cookies, and URL paths, enabling content-based routing. An ALB listens on ports 80 and 443 and forwards requests to target groups based on rules. Path-based routing sends /api/* to one target group and /static/* to another. Host-based routing sends api.example.com to one group and web.example.com to another. ALBs support native OIDC authentication, WAF integration, and request/response manipulation. They are the standard choice for web applications, microservices, and containerized workloads on ECS and EKS.

Network Load Balancer (NLB) operates at layer 4 (transport layer) and handles TCP, UDP, and TLS traffic. It does not inspect application content, which makes it faster with single-digit millisecond latency and capable of handling millions of requests per second. NLBs preserve source IP addresses using the Proxy Protocol. They support static IP addresses and Elastic IPs, making them suitable for scenarios where DNS-based load balancing is insufficient. NLBs are ideal for gaming servers, IoT MQTT brokers, financial trading platforms, and any workload requiring extreme performance or static IPs.

Gateway Load Balancer (GWLB) operates at layer 3 (network layer) and is designed for deploying third-party virtual appliances such as firewalls, intrusion detection systems, and deep packet inspection tools. GWLB uses the GENEVE protocol (port 6081) to encapsulate traffic and forward it to appliance targets. The appliance inspects or modifies traffic and returns it through the GWLB. This architecture enables security service insertion without modifying the application network topology. GWLB endpoints can be placed in VPCs, and traffic is routed to the GWLB using route table entries.

Choosing the right load balancer depends on protocol requirements, performance needs, and feature requirements. Use ALB for HTTP/HTTPS with content-based routing. Use NLB for TCP/UDP with low latency and static IPs. Use GWLB for third-party security appliances. ALBs and NLBs can be combined: an NLB handles SSL termination and static IP assignment while forwarding to an ALB for content routing.

Target groups define how the load balancer routes traffic to registered targets. Each target group specifies a protocol, port, and VPC. Targets can be EC2 instances, IP addresses, Lambda functions, or containers. Health checks determine which targets receive traffic. The load balancer periodically sends requests (for ALB) or connections (for NLB) to each target on the configured health check port and path. A target is considered healthy after passing the configured number of consecutive checks (default 5) and unhealthy after failing the configured number (default 2).

Health check configuration includes protocol, port, path (ALB only), healthy threshold, unhealthy threshold, interval, and timeout. For ALBs, the health check path is typically /health or /ready. The response must return a 2xx or 3xx status code to be considered healthy. For NLBs, health checks use TCP connections or HTTP/HTTPS checks. The interval ranges from 5 to 300 seconds, and timeout from 2 to 120 seconds. Slow-start gradually increases traffic to newly registered targets over a configurable period (300-900 seconds), preventing overwhelming instances that just joined the group.

Sticky sessions (session affinity) ensure a user's requests are routed to the same target for the duration of a session. ALBs implement this using load balancer-generated cookies with a configurable duration. NLBs use source IP-based affinity. Sticky sessions are useful for applications that store session state locally rather than in a shared store like Redis. However, they reduce load distribution effectiveness and can cause hot spots if traffic is uneven.

Connection draining (deregistration delay) controls how long the load balancer waits before closing connections to a target being deregistered. The default is 300 seconds. During this period, the target stops receiving new connections but continues processing existing ones. This prevents abrupt disconnections during deployments or scaling events. For NLBs, this is called deregistration delay and works similarly for TCP connections.

Cross-zone load balancing distributes traffic evenly across all registered targets in all enabled availability zones. Without it, each load balancer node distributes traffic only to targets in its own AZ, which can cause imbalance if target counts differ across AZs. With cross-zone enabled, all targets across all AZs receive roughly equal traffic. Cross-zone is enabled by default for ALBs but disabled by default for NLBs (and incurs inter-AZ data transfer charges). For GWLB, cross-zone is always enabled. The recommendation is to maintain roughly equal target counts across AZs and enable cross-zone as a safety net rather than relying on it.