intermediategeneral

What are the differences between ALB, NLB, and CLB?

⚡

Quick Answer

ALB (Application Load Balancer) operates at Layer 7 with content-based routing, path/host rules, and WebSocket support. NLB (Network Load Balancer) operates at Layer 4 with ultra-low latency, static IPs, and millions of requests per second. CLB (Classic Load Balancer) is the legacy option with basic Layer 4/7 support and should not be used for new deployments.

Detailed Answer

AWS offers three load balancer types, each designed for different networking layers and use cases. Understanding when to use each is a fundamental networking decision that affects application latency, scalability, and architecture.

The Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) of the OSI model. It understands the HTTP protocol — it reads headers, paths, query strings, and even request body content. Think of it as an intelligent receptionist who reads your appointment letter, understands which department you need, and directs you to the correct floor. ALB supports content-based routing rules: you can route /api/payments/* to one target group, /api/users/* to another, and host-based routing sends api.payments.example.com to different targets than dashboard.payments.example.com. This enables microservice architectures where a single ALB fronts dozens of services. ALB supports WebSocket connections natively, HTTP/2 for multiplexed streams, gRPC for service-to-service communication, and sticky sessions with cookies. It can perform SSL/TLS termination, authenticate users with OIDC or Amazon Cognito before forwarding requests, and return fixed responses or redirects without hitting any backend. ALB integrates with AWS WAF for web application firewall protection.

The key limitation of ALB is latency. Because it inspects HTTP content, it adds processing overhead. Typical ALB latency is 1-5ms for simple routing, but it can be higher under complex rule evaluation. ALB does not provide static IP addresses — it uses DNS names that resolve to changing IPs, which is problematic for clients that require IP whitelisting. The workaround is placing an NLB in front of an ALB or using AWS Global Accelerator for static anycast IPs.

The Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP/TLS). It does not inspect HTTP content — it routes based on IP protocol data: source/destination IP and port. Think of it as a high-speed highway interchange that routes vehicles based on their lane (port) without stopping to check what is inside the vehicle. NLB is designed for extreme performance: it handles millions of requests per second with ultra-low latency (typically under 100 microseconds for the load balancer itself). It provides static IP addresses (one per AZ), supports Elastic IP assignment, and preserves the client's source IP address by default (no need for X-Forwarded-For headers).

NLB is ideal for: TCP services that are not HTTP (database connections, MQTT for IoT, custom binary protocols), applications requiring static IPs for firewall whitelisting, extreme throughput requirements (gaming, financial trading, video streaming), and as a frontend for AWS PrivateLink to expose services to other VPCs. NLB supports TLS termination but does not inspect HTTP content, so you cannot route based on URL paths or host headers.

A critical difference is health check behavior. ALB health checks are HTTP-based — it sends an HTTP GET to a path like /health and expects a 200 response. NLB health checks can be TCP (just verifying the port is open), HTTP, or HTTPS. TCP health checks are less accurate because a process might accept TCP connections but be unable to serve requests (for example, the JVM is running but the application is stuck in garbage collection).

The Classic Load Balancer (CLB) is the original AWS load balancer from 2009. It provides basic Layer 4 and Layer 7 functionality but lacks the advanced features of ALB and NLB. It does not support content-based routing, WebSockets (properly), HTTP/2, target groups, or multiple listeners with different rules. CLB uses one backend per load balancer, making microservice routing impossible. AWS has been discouraging CLB for years and recommends migrating to ALB or NLB. The only remaining reason to use CLB is EC2-Classic networking, which itself is deprecated.

Cost comparison: ALB charges per hour ($0.0225/hr) plus per Load Balancer Capacity Unit (LCU) based on new connections, active connections, and processed bytes. NLB charges per hour ($0.0225/hr) plus per Network Load Balancer Capacity Unit (NLCU) based on new connections/flows, active connections/flows, and processed bytes. NLB can be more expensive for HTTP workloads because it counts TCP connections, not HTTP requests — a single HTTP/2 connection can carry thousands of requests but NLB sees it as one flow. CLB charges per hour ($0.025/hr) plus per GB of data processed.

In modern architectures, the common pattern is: ALB for HTTP/HTTPS API traffic and web applications, NLB for non-HTTP protocols, PrivateLink services, and ultra-low-latency requirements, and CLB for nothing new — migrate away.

# Create an ALB for the payment processing API with path-based routing aws elbv2 create-load-balancer \ --name payment-api-alb \ --type application \ --scheme internet-facing \ --subnets subnet-0pub1a subnet-0pub1b subnet-0pub1c \ --security-groups sg-0alb1a2b3c4d5e6f \ --ip-address-type ipv4 \ --tags Key=Service,Value=payment-api Key=Environment,Value=production # --type application: creates an ALB for Layer 7 HTTP/HTTPS routing # --scheme internet-facing: ALB gets public IPs reachable from the internet # --subnets: deployed across 3 AZ public subnets for high availability # --security-groups: allows inbound 443 and outbound to target groups # Create target groups for different microservices behind the ALB aws elbv2 create-target-group \ --name payment-processing-tg \ --protocol HTTP \ --port 8080 \ --vpc-id vpc-0a1b2c3d4e5f67890 \ --target-type ip \ --health-check-path /actuator/health \ --health-check-interval-seconds 15 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 3 # --name: target group for the payment processing microservice # --protocol HTTP: backend communication is HTTP (TLS terminated at ALB) # --port 8080: the port the payment service containers listen on # --target-type ip: routes to IP addresses (for ECS Fargate or EKS pods) # --health-check-path: Spring Boot actuator health endpoint # --health-check-interval-seconds: checks every 15 seconds # --healthy-threshold-count: 2 consecutive successes to mark healthy # --unhealthy-threshold-count: 3 consecutive failures to mark unhealthy # Create path-based routing rules on the ALB listener aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:119283746501:listener/app/payment-api-alb/abc123/def456 \ --priority 10 \ --conditions '[{"Field":"path-pattern","Values":["/api/payments/*"]}]' \ --actions '[{"Type":"forward","TargetGroupArn":"arn:aws:elasticloadbalancing:us-east-1:119283746501:targetgroup/payment-processing-tg/abc123"}]' # --priority 10: evaluated before lower-priority rules (higher number = lower priority) # --conditions: matches any request with URL path starting with /api/payments/ # --actions: forwards matching traffic to the payment processing target group # Create an NLB for the real-time trading data feed (TCP, ultra-low latency) aws elbv2 create-load-balancer \ --name trading-feed-nlb \ --type network \ --scheme internal \ --subnets subnet-0priv1a subnet-0priv1b \ --tags Key=Service,Value=trading-feed Key=Environment,Value=production # --type network: creates an NLB for Layer 4 TCP routing # --scheme internal: not internet-facing, only accessible within the VPC # NLB provides static IPs per AZ and sub-millisecond latency # No security groups needed — NLB passes traffic transparently to targets # Create a TCP target group for the trading data feed aws elbv2 create-target-group \ --name trading-feed-tcp-tg \ --protocol TCP \ --port 9092 \ --vpc-id vpc-0a1b2c3d4e5f67890 \ --target-type instance \ --health-check-protocol TCP \ --health-check-interval-seconds 10 # --protocol TCP: Layer 4 routing without HTTP inspection # --port 9092: Kafka broker port for the trading data feed # --health-check-protocol TCP: verifies port is accepting connections # TCP health checks have lower overhead than HTTP health checks

What are the differences between ALB, NLB, and CLB?

More AWS questions