AWS Elastic Load Balancer: Overview And Types

Summary:

• AWS Elastic Load Balancing distributes incoming traffic across multiple targets to ensure high availability, fault tolerance, and seamless scalability for modern cloud applications.
• Four distinct load balancer types exist. Application Load Balancer operates at layer 7, Network Load Balancer at layer 4, Gateway Load Balancer at layer 3, and Classic Load Balancer serves legacy workloads. Each is optimized for specific protocols and use cases.
• Recent enhancements include HTTP/3 support, dual-stack IPv6 configurations, cross-zone load balancing improvements, and tighter integrations with containerized environments like ECS and EKS.
• Choosing the right ELB type depends on protocol requirements, latency sensitivity, cost constraints, and whether you need advanced routing, ultra-low latency, or inline security appliance integration.

Every millisecond of downtime translates to lost revenue, degraded user experience, and eroded trust. When a single server receives more requests than it can handle, response times spike, errors multiply, and applications buckle under pressure. AWS Elastic Load Balancing solves this fundamental challenge by intelligently distributing incoming application traffic across multiple targets. Those targets can be EC2 instances, containers, IP addresses, or Lambda functions.

Understanding the types of AWS Elastic Load Balancing and their architectural nuances is essential for engineers designing resilient, high-performance systems. These systems must scale gracefully under unpredictable demand.

The following diagram illustrates how AWS Elastic Load Balancing sits between clients and backend targets, routing requests based on configured rules and health status.

How AWS Elastic Load Balancing works

Before diving into specific load balancer types, understanding the foundational components that power AWS Elastic Load Balancing provides critical context. At its core, every ELB operates through a combination of listeners, target groups, health checks, and routing rules that work together to ensure traffic reaches healthy endpoints efficiently. These building blocks remain consistent across all load balancer types, though their configuration options and capabilities vary significantly.

Listeners define the protocol and port on which the load balancer accepts incoming connections. A single load balancer can have multiple listeners, enabling scenarios where HTTP traffic on port 80 redirects to HTTPS on port 443. Different ports can also serve entirely different applications. Each listener contains rules that determine how requests get forwarded to target groups based on conditions like path patterns, host headers, or HTTP methods.

Target groups represent the logical grouping of backend resources that receive traffic. These groups can contain EC2 instances, IP addresses, Lambda functions, or even other Application Load Balancers. The load balancer continuously monitors target health through configurable health checks, automatically removing unhealthy targets from rotation and reinstating them once they recover.

Consider the following core components:

• Health checks: Periodic probes sent to targets to verify availability, with configurable intervals, thresholds, and timeout values
• Cross-zone load balancing: Distributes traffic evenly across all registered targets in all enabled availability zones, preventing hotspots
• IP address types: Support for IPv4, dual-stack (IPv4 and IPv6), and the newer dual-stack-without-public-IPv4 configuration for private workloads

With these foundational concepts established, examining each load balancer type reveals how AWS has optimized different solutions for distinct architectural requirements and traffic patterns.

Application Load Balancer

The Application Load Balancer operates at layer 7 of the OSI model, making routing decisions based on the content of HTTP and HTTPS requests. This content-aware routing capability makes ALB the preferred choice for modern microservices architectures, containerized applications, and any workload requiring sophisticated request manipulation. ALB inspects headers, paths, query strings, and source IP addresses to route traffic with surgical precision.

Core capabilities and protocols

ALB supports HTTP, HTTPS, HTTP/2, gRPC. Native WebSocket support enables real-time bidirectional communication without workarounds, while gRPC support facilitates efficient communication between microservices using protocol buffers.

Content-based routing rules enable powerful traffic management patterns. Path-based routing directs requests to different target groups based on URL paths, allowing a single ALB to serve multiple microservices. Host-based routing examines the Host header, enabling multi-tenant architectures where different domains route to different backends through the same load balancer.

Advanced routing conditions can evaluate:

1. HTTP headers and their values
2. Query string parameters
3. Source IP CIDR blocks
4. HTTP request methods

Use cases and integrations

ALB excels in containerized environments, offering native integration with Amazon ECS and Amazon EKS through the AWS Load Balancer Controller. Dynamic port mapping allows containers to register with ALB automatically as they scale, eliminating manual target registration. Lambda function targets enable serverless architectures where ALB invokes functions directly, handling the HTTP-to-Lambda translation seamlessly.

Authentication integration through Amazon Cognito or any OpenID Connect provider offloads identity verification from application code. ALB can authenticate users before requests ever reach backend services, simplifying security implementation across microservices. Sticky sessions using application-controlled cookies maintain user affinity when stateful interactions require consistent backend routing.

The following diagram shows ALB routing traffic to different microservices based on URL path patterns.

While ALB provides unmatched flexibility for HTTP workloads, applications requiring raw TCP/UDP performance or ultra-low latency demand a different approach. This leads us to the Network Load Balancer.

Network Load Balancer

The 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, making it the definitive choice for performance-critical applications where every microsecond matters. Unlike ALB, NLB does not inspect packet contents beyond the transport layer, enabling pass-through behavior that preserves client IP addresses and minimizes processing overhead.

Performance characteristics

NLB achieves ultra-low latencies latencies by avoiding the deep packet inspection that layer 7 load balancers require. Static IP addresses per availability zone simplify firewall rules and DNS configurations, while Elastic IP support enables predictable addressing for clients that cannot use DNS resolution. The connection-oriented architecture maintains long-lived TCP connections efficiently, which is critical for database connections, gaming servers, and IoT backends.

TLS termination at NLB offloads cryptographic processing from backend instances while still operating at layer 4 speeds. For scenarios requiring end-to-end encryption, TLS passthrough forwards encrypted traffic directly to targets.

Key performance attributes include:

• Latency: Single-digit millisecond latencies under normal load
• Throughput: Handles millions of requests per second per availability zone
• Connection handling: Supports long-lived connections without timeout concerns
• IP preservation: Maintains source IP visibility for backend logging and security

Deployment scenarios

NLB serves as the entry point for hybrid architectures connecting on-premises data centers to AWS through AWS PrivateLink. This capability enables private connectivity without exposing services to the public internet, satisfying compliance requirements for sensitive workloads. UDP support makes NLB suitable for DNS servers, VoIP applications, and streaming protocols that ALB cannot handle.

Dual-stack support enables IPv6 traffic handling alongside IPv4, with the newer dual-stack-without-public-IPv4 option supporting private IPv6-only deployments. Cross-zone load balancing is disabled by default for NLB to minimize inter-AZ data transfer costs. It can be enabled when even distribution across zones outweighs cost considerations. Integration with AWS Global Accelerator provides anycast IP addresses that route users to the nearest AWS edge location before traversing the AWS backbone to NLB.

Beyond traditional load balancing, some architectures require inline inspection of all traffic for security purposes. Neither ALB nor NLB provides this capability natively. This requirement drives the need for Gateway Load Balancer.

Gateway Load Balancer

Gateway Load Balancer operates at layer 3, designed specifically for deploying, scaling, and managing third-party virtual network appliances. GWLB enables transparent insertion of firewalls, intrusion detection systems, and deep packet inspection tools into the traffic path without modifying application architectures. This unique positioning addresses security and compliance requirements that demand all traffic pass through inspection appliances.

Architecture and GENEVE protocol

GWLB uses the GENEVE protocol to encapsulate traffic, preserving original packet headers while routing through virtual appliances. This encapsulation ensures that security tools see unmodified traffic, enabling accurate threat detection and policy enforcement. The architecture combines a Gateway Load Balancer endpoint in the customer VPC with the load balancer itself distributing traffic across appliance instances.

Traffic flow follows a specific pattern. Packets enter through the GWLB endpoint, get encapsulated and sent to appliances, processed, returned to GWLB, and finally forwarded to their destination. This bump-in-the-wire architecture maintains transparency while enabling horizontal scaling of security appliances. The following diagram illustrates this traffic flow.

Security use cases

Organizations deploying next-generation firewalls from vendors like Palo Alto Networks, Fortinet, or Check Point leverage GWLB to scale these appliances elastically. Rather than sizing firewall instances for peak load, GWLB enables auto-scaling groups of virtual appliances that expand and contract based on traffic volume. Intrusion prevention systems benefit similarly, with GWLB distributing inspection workload across multiple instances.

While modern architectures typically employ ALB, NLB, or GWLB, legacy applications may still rely on the original AWS load balancing solution. Understanding it is useful for migration planning.

Classic Load Balancer

The Classic Load Balancer represents the original AWS load balancing service, supporting both layer 4 and layer 7 traffic on a single resource. CLB predates the specialized load balancer types and lacks many features that modern applications require. AWS recommends migrating existing CLB deployments to ALB or NLB. New deployments should avoid CLB entirely unless specific legacy constraints exist.

CLB supports HTTP, HTTPS, TCP, and SSL protocols but lacks the advanced routing capabilities of ALB and the performance characteristics of NLB. Sticky sessions, basic health checks, and SSL termination remain functional. However, features like path-based routing, host-based routing, WebSocket support, and HTTP/2 require migration to ALB. The AWS migration documentation provides detailed guidance for transitioning workloads.

Understanding each load balancer type individually provides a foundation. Practical decision-making requires direct comparison across key attributes.

Feature comparison matrix

The following table consolidates critical attributes across all four load balancer types, reflecting capabilities as of 2026. This comparison enables rapid evaluation based on specific workload requirements.

With technical capabilities mapped, translating this knowledge into practical selection criteria helps engineers make informed architectural decisions.

Practical decision guide

Selecting the appropriate load balancer type requires evaluating multiple factors beyond raw technical capabilities. Cost implications, regional availability, existing infrastructure, and future scalability requirements all influence the optimal choice. The following framework structures this decision process.

Choose Application Load Balancer when: Your application uses HTTP/HTTPS protocols, requires content-based routing, needs authentication integration, targets containers or Lambda functions. ALB suits microservices architectures where different URL paths route to different services.

Choose Network Load Balancer when: Ultra-low latency is critical, you need static IP addresses, the application uses TCP/UDP protocols that ALB cannot handle, or you require millions of requests per second with minimal overhead. NLB excels for gaming backends, financial systems, and IoT platforms.

Choose Gateway Load Balancer when: Compliance or security policies mandate traffic inspection through virtual appliances, you need to scale third-party firewalls or IDS/IPS systems, or you require transparent traffic insertion without application changes.

Cost optimization strategies vary by load balancer type. ALB costs depend heavily on rule complexity and processed bytes, making rule consolidation valuable. NLB costs scale with new connections and processed bytes, favoring connection reuse patterns. Refer to the AWS ELB pricing page for current rates and calculator tools.

Conclusion

AWS Elastic Load Balancing provides the foundational traffic distribution layer that enables highly available, scalable, and resilient cloud architectures. The four load balancer types address distinct architectural requirements. Application Load Balancer handles layer 7 HTTP intelligence. Network Load Balancer delivers layer 4 performance. Gateway Load Balancer enables security appliance integration. Classic Load Balancer supports legacy compatibility. Selecting the appropriate type requires balancing protocol needs, latency sensitivity, routing complexity, and cost constraints against your specific workload characteristics.

As AWS continues enhancing ELB capabilities with features like HTTP/3 support, improved dual-stack configurations, and deeper container orchestration integrations, the service remains central to modern cloud architecture. Engineers who master these load balancing patterns position themselves to design systems that gracefully handle traffic spikes, survive availability zone failures, and scale seamlessly as demand grows. The investment in understanding AWS Elastic Load Balancing pays dividends across every distributed system you architect.