ALB vs. NLB vs. CLB: choosing a load balancer

Published April 9, 2026

Provisioning a load balancer on AWS, most people pick Application Load Balancer without thinking about it. It’s the default in the console, it’s what the tutorials use, and it’s genuinely the right call for most HTTP services. But it isn’t the only option, and it isn’t always the cheapest or the most correct one.

This guide compares the three EC2 load balancer types AWS still sells: Application (ALB), Network (NLB), and Classic (CLB), on what they do and what they cost, using the same pricing data behind the networking pricing reference and its live estimator. If you already know you want ALB or NLB and just need the numbers for your region, that page has a full region-by-region breakdown of every rate below.

The three types in sixty seconds

• Application Load Balancer (ALB) operates at layer 7. It reads HTTP/HTTPS requests and routes them by host, path, header, or query string to different target groups. It understands WebSocket and gRPC, terminates TLS, and is what you want for a web app, an API, or anything where routing depends on the content of the request.
• Network Load Balancer (NLB) operates at layer 4. It routes TCP, UDP, and TLS connections without inspecting them, forwarding packets rather than parsing requests. It supports a static IP (or Elastic IP) per Availability Zone, preserves the client’s source IP by default, and handles connection volumes and latency that ALB isn’t built for. It’s also the load balancer type required in front of a PrivateLink endpoint service.
• Classic Load Balancer (CLB) is the original ELB, predating both of the above. AWS has discouraged new CLB usage for years. It lacks target groups, host/path-based routing, and native Lambda and container targets, and covers only a fraction of what ALB and NLB now do. It still runs, and it still bills, but there’s effectively no “choose CLB” case for a new service. The only realistic reason to see one today is that it’s already there, attached to something old.

What each one actually costs

Every AWS load balancer bills two ways: an hourly charge for the load balancer itself, and a usage charge for what passes through it. ALB and NLB meter usage in Load Balancer Capacity Units (LCUs), a bundled measure that factors in new connections, active connections, processed bytes, and (for ALB only) rule evaluations, billed at whichever dimension is highest that hour. CLB instead charges a flat rate per GB processed, with no LCU concept involved.

Our dataset carries the LCU rate as a single flat LCUUsage line per region. It doesn’t break out the underlying connection, byte, and rule dimensions AWS uses to compute which LCU count you’re actually billed for, so treat the LCU price below as the multiplier, not a full LCU calculator. AWS’s console and Cost Explorer will show you your actual LCU consumption once a load balancer is running.

Real rates, pulled directly from networking_pricing.csv:

Two things jump out once the numbers sit next to each other.

The hourly charge is identical between ALB and NLB in every region in the dataset. There’s no “NLB is cheaper to run” story at the base rate. You pay the same $/hour for the load balancer itself either way.

The LCU rate is where NLB gets cheaper, and by a consistent margin: 25% less per LCU-hour than ALB in every region above ($0.006 vs. $0.008 in us-east-1, $0.00825 vs. $0.011 in São Paulo). That discount is the entire cost argument for NLB over ALB when both would technically work, and it only shows up once your traffic is consuming a meaningful number of LCUs, since the flat hourly charge is the same regardless.

CLB’s hourly rate, meanwhile, runs at or above both of the modern types in every region above, and it bills data processed per GB with no LCU concept: no credit for a load balancer sitting mostly idle, no discount for efficient request routing. It’s not priced as a bargain option. It’s priced like the load balancer AWS would rather you migrate off of.

A worked comparison: ALB vs. NLB for a modest service

Take a steady, moderate-traffic service, enough load to keep the balancer doing real work but not a burst spike, and assume it lands around 5 LCU-hours on average. (That number is illustrative, not derived from this dataset; your own console will show your real figure.) At 730 hours/month:

us-east-1:

• ALB: $0.0225 × 730 + 5 × $0.008 × 730 = $16.43 + $29.20 = $45.63/mo
• NLB: $0.0225 × 730 + 5 × $0.006 × 730 = $16.43 + $21.90 = $38.33/mo
• NLB comes in about 16% cheaper, all of it from the LCU rate and none from the hourly charge.

sa-east-1:

• ALB: $0.034 × 730 + 5 × $0.011 × 730 = $24.82 + $40.15 = $64.97/mo
• NLB: $0.034 × 730 + 5 × $0.00825 × 730 = $24.82 + $30.11 = $54.93/mo
• Same pattern, about 15% cheaper for NLB.

The gap scales with traffic: the more LCUs your service actually consumes, the more the 25% LCU discount is worth in absolute dollars. At very light traffic, a load balancer sitting mostly idle in front of a low-volume internal service, the flat hourly charge dominates and the two land within cents of each other.

None of this is an argument to run HTTP traffic through NLB to save 16%. If your workload needs layer-7 routing (host-based rules, path-based rules, WebSocket upgrades, TLS termination with SNI), ALB is the correct tool, and forcing the workload onto NLB would cost far more in engineering time to reimplement that routing logic yourself, usually in application code, than the LCU savings are worth. The comparison matters when the workload is already layer-4 shaped and NLB is the technically correct choice. In that case, it’s cheaper too.

Where CLB still fits

Nowhere, for a new service. AWS has been steering customers off Classic Load Balancer since ALB and NLB shipped, and the feature gap has only widened: no target groups, no native support for Lambda or IP targets, no host/path-based routing, weaker health checks, and no modern TLS policy management. The pricing table above shows it costing the same or more than the load balancers that replaced it, with none of the routing capability.

The only place CLB shows up today is attached to something that predates the migration: an EC2-Classic-era stack, or a service nobody has gotten around to moving. If you have one of those, the move is almost always to ALB (for HTTP/HTTPS traffic) or NLB (for raw TCP/UDP), not a decision about whether to keep CLB. AWS’s own migration tooling, the ELB migration wizard in the console, handles most of the mechanical work.

Checking the numbers for your own service

1. Confirm the traffic shape first: HTTP/HTTPS with routing rules points to ALB; raw TCP/UDP, extreme connection volume, or a static-IP requirement points to NLB. This decision comes before cost, because the wrong layer doesn’t do the job regardless of price.
2. Look up your region’s hourly and LCU rates in the full networking pricing reference, filtering to “Load Balancer-Application” or “Load Balancer-Network” to see every region at once.
3. Estimate your LCU consumption from actual or expected traffic: new connections per second, active connections, throughput, and (for ALB) rule evaluations. AWS bills whichever dimension is highest each hour, so a rough estimate from your current traffic is more useful than a guess.
4. Multiply out hourly plus LCU cost the way the worked example above does, for your real region and your real LCU estimate.
5. If you’re comparing the load balancer against the compute it sits in front of, check the instance explorer and the comparison tool. For most services the EC2 fleet behind the load balancer costs far more per month than the load balancer itself, so don’t over-optimize this line item at the expense of the routing behavior you actually need.

Making the call

Choose ALB. Any HTTP or HTTPS service: web apps, REST or GraphQL APIs, anything needing host- or path-based routing, WebSocket, gRPC, or TLS termination with multiple certificates via SNI. This is the right default for most new services, and the cost difference against NLB is small enough that it shouldn’t override the routing requirement.

Choose NLB. Raw TCP/UDP workloads, extreme connection volumes or ultra-low-latency requirements (gaming servers, IoT ingestion, financial protocols), anything needing a static IP or Elastic IP, preserving the original client IP without proxy protocol workarounds, or serving as the front end for a PrivateLink endpoint service. When either type would technically work, NLB’s 25%-cheaper LCU rate makes it the better economic choice too.

Don’t choose CLB. It isn’t a “when to use it” case for new work. AWS discourages it, it lacks the routing features of both modern types, and this data shows it costing as much or more. If you’re running one, plan the migration to ALB or NLB rather than treating CLB as a valid third option.

Bottom line: the hourly charge doesn’t differentiate ALB from NLB. They’re priced identically per hour in every region in this dataset. The entire cost argument for NLB is a 25%-cheaper LCU rate, which only matters once there’s real traffic behind it. Pick based on what layer your traffic needs first; if that leaves a genuine choice, let the LCU rate break the tie.