AWS Load Balancers: The Types, Use Cases, and Benefits

Summary:

• AWS offers four distinct load balancer types. Application Load Balancer (ALB) handles layer 7 HTTP/HTTPS routing. Network Load Balancer (NLB) provides ultra-low latency layer 4 traffic handling. Gateway Load Balancer (GWLB) supports inline security appliances. Classic Load Balancer (CLB) remains available as a legacy option.
• Choosing the right AWS load balancer depends on protocol requirements, latency tolerance, static IP needs, and cost considerations tied to Load Balancer Capacity Units (LCUs).
• Recent 2025-2026 AWS updates introduce weighted target groups for NLB, ALB Target Optimizer, QUIC protocol support, and billing changes for inter-AZ data transfer that directly impact architecture decisions.
• Advanced patterns like NLB fronting ALB enable static IP addresses with sophisticated layer 7 routing. GWLB simplifies transparent security appliance insertion.

Every millisecond of latency in a distributed system translates to measurable business impact. This includes abandoned shopping carts, failed API calls, or degraded user experience at scale. AWS load balancers sit at the critical intersection of availability, performance, and cost optimization. Yet many engineering teams default to a single load balancer type without fully understanding the architectural trade-offs involved. This guide dissects the four types of AWS load balancers, examines their technical capabilities through the lens of real-world workloads, and provides the decision framework you need to architect resilient, cost-effective infrastructure in 2025 and beyond.

The following diagram illustrates how different AWS load balancer types integrate within a typical multi-tier architecture. It shows traffic flow from clients through various load balancing layers to backend services.

Understanding AWS Elastic Load Balancing fundamentals

AWS Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets such as EC2 instances, containers, IP addresses, and Lambda functions. The service operates as a fully managed, highly available component that scales automatically based on incoming traffic patterns. Unlike self-managed load balancers like NGINX or HAProxy running on EC2, ELB eliminates the operational burden of capacity planning, patching, and failover management. It also provides native integration with AWS services, including Auto Scaling, Certificate Manager, and CloudWatch.

The fundamental distinction between AWS load balancer types centers on the OSI layer at which they operate. Layer 4 load balancers (NLB and CLB in TCP mode) make routing decisions based on IP addresses and TCP/UDP ports without inspecting packet contents. Layer 7 load balancers (ALB and CLB in HTTP mode) understand application protocols and can route based on HTTP headers, paths, hostnames, and query strings. This architectural difference drives performance characteristics, feature availability, and cost structures across the load balancer family.

Health checks form the reliability backbone of all AWS load balancer types. Each load balancer continuously monitors target health through configurable probes, automatically removing unhealthy targets from rotation and reinstating them upon recovery. The sophistication of health checks varies by load balancer type. ALB supports HTTP response code validation and body content matching, while NLB provides TCP, HTTP, and HTTPS health check options with customizable thresholds. Understanding these health check mechanisms becomes critical when designing systems that must maintain availability during rolling deployments or partial infrastructure failures.

Application Load Balancer provides layer 7 intelligence for modern applications

Application Load Balancer operates at layer 7 of the OSI model, providing content-based routing capabilities that make it the default choice for HTTP and HTTPS workloads. ALB inspects incoming requests and routes them based on host headers, URL paths, HTTP methods, query parameters, and source IP addresses. This routing flexibility enables sophisticated traffic management patterns, including A/B testing, blue-green deployments, and microservices architectures where different URL paths map to distinct backend services.

Core features and protocol support

ALB natively supports HTTP/1.1, HTTP/2, gRPC, and WebSocket protocols, making it suitable for modern application architectures. HTTP/2 support enables multiplexed connections that reduce latency for web applications. gRPC support allows efficient communication between microservices using Protocol Buffers. WebSocket support maintains persistent connections for real-time applications like chat systems, gaming backends, and live dashboards without requiring sticky sessions or connection-draining workarounds.

Key ALB capabilities include:

• Host-based routing: Direct traffic to different target groups based on the Host header, enabling multiple domains on a single load balancer
• Path-based routing: Route requests to specific backends based on URL path patterns like /api/* versus /static/*
• Weighted target groups: Distribute traffic across target groups by percentage for canary deployments
• Lambda function targets: Invoke serverless functions directly without API Gateway overhead
• Authentication integration: Native OIDC and Amazon Cognito authentication at the load balancer layer

ALB Target Optimizer and 2025 enhancements

AWS introduced ALB Target Optimizer at re:Invent 2025. This machine learning-powered feature automatically adjusts target weights based on real-time performance metrics. The optimizer monitors response latency, error rates, and connection counts across targets. It dynamically shifts traffic away from degraded instances before they fail health checks. This proactive approach reduces error rates during partial failures and improves overall application responsiveness without manual intervention.

Additional 2025 enhancements include improved PrivateLink integration, allowing ALB endpoints to be exposed privately to other VPCs and AWS accounts. Static IP support through AWS Global Accelerator integration addresses a long-standing limitation, enabling ALB to work with firewall allowlists that require fixed IP addresses. These updates position ALB as increasingly viable for enterprise environments with strict network security requirements.

Network Load Balancer delivers ultra-low latency at layer 4

Network Load Balancer operates at layer 4, handling TCP, UDP, and TLS traffic with extreme efficiency. NLB processes millions of requests per second while maintaining ultra-low latencies, typically under 100 microseconds for connection establishment. This performance stems from NLB’s flow-based architecture that routes packets without deep inspection. It is ideal for latency-sensitive applications, gaming backends, IoT platforms, and financial trading systems.

Static IP and connection handling

NLB provides static IP addresses per availability zone. This is a critical requirement for applications that must be reachable through firewall allowlists or DNS configurations that cannot accommodate changing IP addresses. Each NLB automatically receives one static IP per enabled availability zone. You can optionally assign Elastic IP addresses for even greater control. This static IP capability, combined with support for PrivateLink, makes NLB the foundation for exposing services to external partners or across VPC boundaries.

Connection handling in NLB preserves the source IP address by default, unlike ALB, which requires X-Forwarded-For headers. This transparency simplifies logging, security analysis, and applications that implement IP-based access controls. NLB also supports long-lived connections essential for database proxies, message queues, and streaming protocols, where connection establishment overhead must be minimized.

Weighted target groups and TLS termination

The weighted target groups feature, launched in late 2025, brings sophisticated traffic management to NLB without sacrificing layer 4 performance. You can now distribute traffic across multiple target groups by percentage, enabling canary deployments and gradual migrations at the TCP/UDP layer. This capability previously required ALB or custom proxy solutions. Weighted target groups maintain NLB’s latency characteristics while adding deployment flexibility.

NLB supports TLS termination, offloading encryption overhead from backend instances while maintaining the performance benefits of layer 4 routing. TLS listeners decrypt traffic at the load balancer using certificates managed through AWS Certificate Manager, then forward unencrypted traffic to targets. For end-to-end encryption requirements, NLB also supports TLS passthrough, where encrypted traffic flows directly to targets that handle their own certificate management.

The following diagram shows NLB’s weighted target group configuration for a canary deployment scenario.

Gateway Load Balancer enables transparent security appliance insertion

Gateway Load Balancer addresses a specialized use case. It inserts third-party virtual appliances like firewalls, intrusion detection systems, and deep packet inspection tools into network traffic flows transparently. GWLB operates at layer 3, using the GENEVE protocol to encapsulate traffic and forward it to appliance fleets while preserving original packet headers. This architecture enables bump-in-the-wire deployments where security appliances inspect all traffic without becoming routing bottlenecks or single points of failure.

Architecture and GENEVE encapsulation

GWLB combines a transparent network gateway with load balancing capabilities across appliance instances. Traffic enters through Gateway Load Balancer Endpoints (GWLBe) deployed in your VPCs, gets encapsulated using the GENEVE protocol on port 6081, and forwards to registered appliance targets. After inspection, appliances return traffic to GWLB, which decapsulates and forwards to the original destination. This flow maintains source and destination IP addresses throughout, ensuring appliances see actual client information.

The GENEVE encapsulation includes metadata that appliances can use for policy decisions, including the original VPC ID, subnet ID, and flow direction. This metadata enables multi-tenant appliance deployments where a single appliance fleet serves multiple VPCs with tenant-specific security policies. Major security vendors, including Palo Alto Networks, Fortinet, and Check Point, provide GWLB-compatible virtual appliances through AWS Marketplace.

Use cases for security and compliance

GWLB excels in environments requiring centralized security inspection across multiple VPCs or accounts. Common deployment patterns include:

1. Centralized egress inspection: Route all outbound internet traffic through GWLB-fronted firewalls for data loss prevention and threat detection
2. East-west traffic inspection: Inspect traffic between VPCs or subnets using Transit Gateway integration with GWLB
3. Ingress threat protection: Position intrusion prevention systems inline before traffic reaches application load balancers
4. Compliance logging: Capture and analyze all network flows through deep packet inspection appliances for regulatory requirements

Classic Load Balancer and legacy considerations

Classic Load Balancer represents the original AWS load balancing service, supporting both layer 4 and layer 7 routing in a single product. While CLB remains available for existing configurations, AWS officially deprecated CLB on December 31, 2025, meaning it can no longer be provisioned in new accounts. AWS actively recommends migration to ALB or NLB for all workloads. CLB lacks support for modern protocols like HTTP/2, gRPC, and WebSocket. It cannot route based on host headers or URL paths, limiting its utility for contemporary application architectures.

Organizations maintaining CLB deployments typically do so for legacy applications where migration risk outweighs benefits, or for EC2-Classic network configurations that predate VPC. AWS provides migration tools that analyze CLB configurations and generate equivalent ALB or NLB setups, reducing the effort required to modernize. The cost structure for CLB differs from newer load balancers, using hourly rates plus data processing charges rather than the LCU-based model. This can result in higher costs for variable traffic patterns.

Comparative analysis for choosing the right load balancer

Selecting the appropriate AWS load balancer requires evaluating protocol requirements, performance characteristics, feature needs, and cost implications. The following comparison table synthesizes key differentiators across all four load balancer types, incorporating 2025-2026 feature updates and pricing structures.

Decision framework by workload type

Consider the following decision logic when selecting a load balancer for specific workload patterns. Web applications serving HTTP/HTTPS traffic benefit most from ALB’s content-based routing, authentication integration, and HTTP/2 support. Microservices architectures using gRPC should default to ALB unless latency requirements demand NLB with TLS passthrough. Real-time applications like gaming, financial trading, or IoT platforms requiring sub-millisecond latency should use NLB regardless of protocol.

For security-focused architectures requiring inline appliance inspection, GWLB provides the only scalable solution that maintains transparency and horizontal scaling. Hybrid patterns combining multiple load balancer types often deliver optimal results. The NLB-fronting-ALB pattern provides static IP addresses for firewall allowlists while preserving ALB’s layer 7 routing capabilities. This addresses a common enterprise requirement that neither load balancer satisfies independently.

Cost optimization and 2025-2026 billing changes

AWS load balancer costs comprise two components. The first is hourly charges for the load balancer itself. The second is Load Balancer Capacity Unit (LCU) charges based on actual usage. LCU consumption depends on four dimensions: new connections per second, active connections, processed bytes, and rule evaluations (ALB only). The highest dimension determines LCU consumption for any given hour, making it essential to understand your traffic patterns when estimating costs.

The 2025 billing changes introduced inter-AZ data transfer charges for cross-zone load balancing on NLB, aligning with ALB’s existing model. Previously, NLB cross-zone traffic was free. AWS now charges standard inter-AZ rates ($0.01/GB in most regions) when cross-zone load balancing is enabled. This change significantly impacts architectures with uneven target distribution across availability zones or high-bandwidth workloads. Consider disabling cross-zone load balancing and using Route 53 latency-based routing as an alternative for cost-sensitive deployments.

The following diagram illustrates LCU calculation across the four consumption dimensions.

Implementation best practices for production deployments

Production load balancer deployments require attention to availability, security, observability, and operational efficiency. Start by enabling access logging to S3 for all load balancers, capturing request details that prove invaluable during incident investigation and capacity planning. Configure CloudWatch alarms for key metrics, including TargetResponseTime, UnHealthyHostCount, and HTTPCode_ELB_5XX_Count to detect issues before they impact users.

Security hardening

Implement defense-in-depth through multiple security layers:

• Security groups: Restrict load balancer ingress to expected source ranges and limit target security groups to accept traffic only from load balancer security groups
• TLS policies: Use the latest AWS-recommended security policies (such as ELBSecurityPolicy-TLS13-1-2-2021-06 or ELBSecurityPolicy-TLS13-1-3-2021-06 depending on compatibility needs) to disable vulnerable cipher suites
• WAF integration: Attach AWS WAF web ACLs to ALB for protection against common web exploits and bot traffic
• Certificate management: Use ACM for automatic certificate renewal and avoid storing private keys on instances

EKS and container integration

Kubernetes workloads on Amazon EKS benefit from the AWS Load Balancer Controller, which automates ALB and NLB provisioning through Kubernetes Ingress and Service resources. The controller supports advanced features including target group binding for existing load balancers, IP-mode targeting that registers pod IPs directly (bypassing NodePort), and integration with AWS WAF and Shield. For service mesh architectures using Istio or App Mesh, position NLB at the ingress gateway to maintain static IPs while the mesh handles internal routing.

Consider the following architecture pattern for EKS production deployments. NLB with TLS termination fronts an internal ALB that performs path-based routing to multiple Kubernetes services. This pattern provides static IPs for external clients, offloads TLS at the network edge, and enables sophisticated routing rules without exposing ALB directly to the internet. The internal ALB can leverage target group binding to register pods directly, reducing latency compared to NodePort routing.

Conclusion

AWS load balancers form the foundation of resilient, scalable architectures. Their effectiveness depends entirely on matching load balancer capabilities to workload requirements. ALB delivers the routing intelligence modern web applications demand. NLB provides the raw performance that latency-sensitive systems require. GWLB enables transparent security inspection at scale. The deprecation trajectory of CLB makes migration planning essential for organizations still running legacy configurations.

The 2025-2026 feature releases, particularly weighted target groups for NLB and ALB Target Optimizer, blur traditional boundaries between load balancer types while introducing new cost considerations through inter-AZ billing changes. Forward-looking architectures should embrace hybrid patterns like NLB-fronting-ALB to capture the benefits of both layer 4 performance and layer 7 intelligence. As AWS continues evolving its load balancing portfolio, the engineers who understand these trade-offs deeply will build systems that perform reliably under pressure while optimizing infrastructure costs.