ALB vs NLB Pricing: LCU Math Demystified (2026)

Prices below are 2026 US East (N. Virginia) list rates for planning purposes. AWS publishes these per-region and they do shift over time — always confirm current numbers against the AWS Elastic Load Balancing pricing page before budgeting a production workload.

Every AWS load balancer type meters capacity across several traffic dimensions in parallel, then converts each dimension into an equivalent number of “capacity units” for that hour. The dimension that produces the highest unit count wins — you pay for that one number, not the sum of all dimensions. This is the single most misunderstood part of load balancer pricing, and it's why two workloads with identical bandwidth can land on wildly different bills.

The mechanics work the same way across ALB, NLB, and GWLB — only the specific dimensions and their per-unit thresholds differ. AWS measures usage each hour, computes how many capacity units each dimension alone would require to serve that traffic, and bills the maximum of those numbers rounded to the nearest 0.01 unit.

One Application Load Balancer LCU-hour buys you the highest of these four thresholds, measured over the hour:

To compute LCUs for an hour: divide your actual usage in each dimension by its per-LCU threshold, then take the largest of the four resulting numbers. That's your billed LCU count for that hour — the other three dimensions ride along free once the max one is covered.

Network Load Balancer drops the rule-evaluation dimension (NLB does L4 routing, not L7 content-based rules) and uses a coarser byte-processing rate that reflects its higher-throughput design:

NLB's active-connections threshold (100,000/minute per unit) is more than 30x looser than ALB's (3,000/minute), which is exactly why NLB is the right tool for workloads with huge numbers of long-lived, low-chatter TCP connections — think IoT fleets, game servers, or gRPC streams — that would otherwise blow through ALB's active connection LCU and force you to pay for capacity you don't functionally need.

Gateway Load Balancer sits at L3 and is built for one job: transparently routing traffic through third-party virtual appliances (firewalls, intrusion detection, deep-packet inspection) using GENEVE encapsulation, without the traffic's source or destination needing to know an appliance is in the path. Its capacity-unit math is simpler in practice — the dominant dimension is almost always processed bytes/hour flowing through the appliance fleet, since GWLB doesn't do connection-based routing decisions the way ALB and NLB do. Treat GWLB cost as roughly proportional to total inspected traffic volume for planning purposes, then verify against actual usage once appliances are live.

Assume a mid-size API service behind an ALB with this hourly traffic profile at peak:

• 450 new connections/second
• 8,000 active connections/minute
• 2.5 GB processed/hour (HTTPS, TLS terminated on the ALB)
• 600 rule evaluations/second (a handful of path-based routing rules)

Convert each dimension into LCUs using the thresholds above:

The max across all four is new connections at 18.0 LCUs — that's the billed number for this hour, even though processed bytes and active connections are nowhere close to that ceiling. This is the core lesson: a connection-churn-heavy workload (short-lived requests, frequent reconnects, aggressive client retry logic) can dominate the bill long before bandwidth becomes the limiting factor.

Assuming this peak profile holds for roughly 10 peak-equivalent hours/day (a common simplification for services with a daily traffic curve) and a lighter ~4 LCU baseline for the other 14 hours:

Run the same 2.5 GB/hr peak traffic through an NLB instead (assuming it's a raw TCP workload rather than HTTP, so the ALB comparison isn't apples-to-apples, but useful for seeing the rate difference): the processed-bytes threshold is looser (1 GB/hr per NLCU vs. 0.4 GB/hr for ALB with TLS termination) and the per-unit rate is lower ($0.006 vs. $0.008), so NLB pricing for byte-heavy, low-connection-churn traffic comes in meaningfully cheaper — often the deciding factor for high-throughput streaming or bulk-transfer workloads that don't need L7 routing.

Cheapest isn't just about the sticker rate — the wrong load balancer type for your traffic shape can cost more even at a lower per-unit price, because the wrong dimension model produces more billed units.

• Choose ALB for HTTP/HTTPS/gRPC traffic that needs path- or host-based routing, WebSocket support, native OIDC/Cognito authentication, or Kubernetes ingress via the AWS Load Balancer Controller. The rule-evaluation and content-aware routing capability is worth the higher per-LCU rate for anything that benefits from L7 intelligence.
• Choose NLB for raw TCP/UDP/TLS traffic needing ultra-low latency (single-digit millisecond added latency), a static IP or Elastic IP per AZ, extreme connections-per-second scale (millions), or preservation of the client's source IP without proxy protocol overhead. NLB is also the required front door for AWS PrivateLink endpoint services.
• Choose GWLB only when you need to insert third-party security appliances (firewalls, IDS/IPS) transparently into a traffic path across many VPCs — it's not a general-purpose load balancer for application traffic and shouldn't be evaluated as an ALB/NLB alternative outside that use case.

For containerized workloads, this decision usually shows up as EKS ingress choice; see our EKS vs AKS vs GKE pricing guide for how load balancer cost fits into overall managed Kubernetes economics.

LCU/NLCU/GLCU charges are billed independently of data transfer and NAT Gateway processing fees — they're not a substitute for either. A single request path where a client hits an internet-facing ALB, the target routes an outbound call through a NAT Gateway, and the response leaves back out to the internet can rack up three separate per-byte-style charges on effectively the same data:

• ALB processed-bytes LCU cost for bytes flowing through the load balancer
• NAT Gateway processing charge ($0.045/GB) for any outbound traffic routed through it — see our NAT Gateway pricing guide for the full breakdown
• Internet data transfer out ($0.09/GB tiered) for bytes leaving AWS entirely — detailed in our AWS data transfer cost map

None of these individually looks large on a line-item basis, but at meaningful traffic volumes they compound. Architectures that route unnecessary traffic through a NAT Gateway when a VPC endpoint would do, or that terminate TLS redundantly at multiple hops, pay for the same bytes multiple times over. Model the full path, not just the load balancer line item, when estimating total cost.

To model your own load balancer and networking spend without building a spreadsheet from scratch, the SpendArk cloud cost calculator lets you compare ALB, NLB, and the surrounding data transfer costs side by side.