How does AWS LCU (Load Balancer Capacity Unit) billing actually work?

AWS bills ALB and NLB by LCU-hours: the number of LCUs consumed per hour times the hours your load balancer is active. One LCU represents a unit of capacity across four independent dimensions: new connections/ flows per second, active connections/flows, bandwidth (Gbps), and — for ALB only — rule evaluations per second. AWS computes LCU usage for each dimension independently, then bills you for the ceiling of the single largest dimension. A balancer at 2 Gbps bandwidth and 5 new connections/second bills 2 LCU (bandwidth binds at 2 Gbps ÷ 1 Gbps/LCU = 2 LCU), not 2.2. Adding more active connections or rules has zero cost impact until one of those dimensions overtakes bandwidth. This is the core rule: you pay for the MAX dimension, not the SUM. The cost consequence is that each workload has a binding dimension, and identifying it — rather than optimizing all four — is the only way to control costs. Use the ALB vs NLB Cost Calculator at jslet.com/alb-nlb-cost-calculator to see which dimension binds for your traffic profile.

When is NLB cheaper than ALB?

NLB is cheaper than ALB when the new-connection dimension binds. NLB counts 800 new TCP flows per LCU; ALB counts only 25 new connections per LCU — a 32× difference. At 50,000 new connections/second, NLB needs 63 LCU (50,000 ÷ 800) while ALB needs 2,000 LCU (50,000 ÷ 25). Even at NLB's slightly higher active-flow capacity (100,000 vs ALB's 3,000), the new-connection dimension dominates for connection-heavy workloads: gaming servers, IoT/MQTT backends, WebSocket-heavy applications, and connection-pooled microservice meshes. At 50,000 new conn/s, NLB costs approximately $461/month while ALB costs $2,134/month — NLB is 4.6× cheaper. However, NLB cannot do HTTP routing, host-based rules, or request-level redirects — it operates at L4 only. If your workload requires content-based routing, ALB is the only option regardless of cost.

When do ALB rule evaluations become a cost problem?

ALB's rule-evaluation dimension bills at 1,000 rule evaluations per second per LCU — but only for rules beyond the first 10, which are free. At 50 content-based routing rules serving 2,000 requests/second, the ALB evaluates (50 − 10) × 2,000 = 80,000 rule evaluations/second = 80 LCU. If the other three dimensions (connections, active connections, bandwidth) sum to less than 80 LCU, rule evaluations become the binding dimension. At 80 LCU × $0.008/LCU-hour × 730 hours = $467/month in rule-evaluation LCU alone — often surpassing bandwidth and new-connection LCU combined. The trap compounds with request rate: at 5,000 rps with the same 50 rules, rule evaluations jump to 200,000/s = 200 LCU = $1,168/month. The fix: consolidate rules (fewer evaluated per request path), use host-based routing (which groups requests before rules apply), or move complex routing logic upstream to CloudFront or a service mesh layer where rules are cheaper or free. NLB has no rule-evaluation concept at all — another reason NLB dominates pure L4 workloads, even at high LCU counts on other dimensions.

How much does an idle ALB or NLB cost per month?

Every ALB and NLB has a fixed hourly cost that applies regardless of traffic: $0.0225/hour in us-east-1. At 730 hours per month, that's $16.43/month per load balancer before a single request touches it. Two load balancers in two availability zones for high availability = $32.86/month as the absolute floor. At low traffic volumes (dev environments, internal APIs serving single-digit requests per second), this fixed cost dominates — a 1 LCU ALB at 5 rps costs ~$16.43 + (1 × $0.008 × 730) = $22.27/month. The fixed hourly cost matters most when you have many small load balancers rather than fewer consolidated ones. Consolidating behind a single ALB with host-based routing (free rules within the first 10) often eliminates multiple $16.43/month fixed charges. The ALB vs NLB Cost Calculator at jslet.com/alb-nlb-cost-calculator splits fixed and LCU costs so you can see exactly how much of your bill is the idle floor.

Should I use ALB or NLB for Kubernetes ingress?

The answer depends on what's behind the load balancer and your traffic profile. For HTTP workloads with host/path-based routing needs, AWS Load Balancer Controller creates an ALB — it can do context-path routing to different services, SSL termination at the LB, and WAF integration. For non-HTTP workloads (gRPC without HTTP/2 framing, raw TCP, UDP, or workloads where you need static IP addresses for allowlisting), use NLB. The cost difference is workload-dependent: if your K8s services are connection-heavy (thousands of new connections/second from external clients), NLB is structurally cheaper. If they're request-heavy with modest connection rates and need path-based routing, ALB is the tool — and the rule count matters. For internal service-to-service communication within the cluster, consider whether you even need a load balancer: ClusterIP services or service mesh (Istio/Linkerd) with internal routing may eliminate the LCU bill entirely.

The LCU Trap: Why Your Load Balancer Bill Has Nothing To Do With Bandwidth

Executive Summary

Most engineers think about load balancers in terms of throughput. "We're pushing 2 Gbps through the ALB, so it's probably costing us something around..." — and that's where the intuition breaks. LCU billing doesn't care about your intuition. It cares about four independent dimensions, computes each one, and bills you for whichever is largest. The other three could be zero or they could be enormous — it doesn't matter. The max wins.

This quirk of the pricing model has a counterintuitive consequence: the dimension that determines your bill is usually not the one you're monitoring. Most teams watch bandwidth because it maps to "how much traffic." But bandwidth is almost never the binding dimension unless you're running a data-heavy workload with small connection counts. The real binding dimension depends on your workload shape — and for many architectures, it's new connections (NLB wins by 32×) or rule evaluations (ALB-only trap). If you picked ALB because you need HTTP routing and didn't check whether your rule count is the binding dimension, your bill may be 2–3× what it should be for the bandwidth you're actually pushing.

This briefing deconstructs LCU billing mechanics, walks through five workload profiles that flip the binding dimension in unexpected ways, and provides a decision framework for choosing ALB vs NLB — not on features, but on cost structure. Because the features determine whether you can use one or the other. The cost structure determines whether you should.

How LCU Billing Actually Works — The Max Rule

ALB and NLB each bill by LCU-hour. An LCU is a bundle of capacity across four (ALB) or up to six (NLB) dimensions:

Dimension	ALB per LCU	NLB per LCU	Implication
New connections / flows / second	25	800	NLB is 32× more efficient per LCU
Active connections / flows	3,000	100,000	NLB is 33× more efficient per LCU
Bandwidth (Gbps)	1 Gbps	1 Gbps	Equal — both bill 1 Gbps/LCU
Rule evaluations / second*	1,000	—	ALB only. First 10 rules free.

* NLB additionally bills for TLS flows (50/LCU) and source/destination IP tuple preservation (240,000/LCU) when those features are enabled. They rarely bind unless you have a very specific workload pattern — TLS-heavy without high connection counts, or source-IP-preserved without high active connections.

The billing rule: compute all dimensions, ceiling the maximum, bill that LCU count. LCU = ceil( max(dim1, dim2, dim3, dim4) ). The minimum is 1 LCU per load balancer per hour.

Here's a concrete example. An ALB serving 2,000 requests/second with 40 KB average response size, 500 new connections/second, 40,000 active connections, and 20 content-based routing rules:

Dimension	Raw Value	Formula	LCU from Dim
New connections	500	500 ÷ 25	20.0
Active connections	40,000	40,000 ÷ 3,000	13.3
Bandwidth	0.64 Gbps	(2000 × 40 × 8) ÷ 1e9	0.64
Rule evaluations	20,000/s	(20-10) × 2000 ÷ 1000	20.0
ALB LCU (max, ceiling)	20 LCU (new connections and rule evaluations tie at 20)

Two dimensions tie at 20 LCU. Add 10 more rules to go from 20 to 30, and rule evaluations become the sole binding dimension at 30 LCU — a 50% bill increase, while bandwidth hasn't moved. This is the trap: changes to one dimension can bind and spike the bill, while the dimension you're monitoring (usually bandwidth) stays flat. And if you don't know which dimension binds, you can't predict which changes will spike the bill.

⚡ The Core Insight: Because you pay for the MAX, optimizing the non-binding dimensions has zero cost impact. If new connections bind at 20 LCU, reducing active connections from 40,000 to 3,000 saves exactly $0. The bill is already determined by new connections. Every cost optimization effort should start by identifying the binding dimension — then asking whether you can change it, or whether a different load balancer type would bind on a cheaper dimension. The ALB vs NLB Cost Calculator shows the binding dimension for both types side by side.

"So bandwidth never matters?" Sometimes. If you're pushing 50 Gbps through 5 connections — a video processing pipeline or a CDN origin — bandwidth absolutely binds, and ALB and NLB bill it identically at 1 Gbps/LCU. The 25% per-LCU-hour difference is the entire story. But that workload shape is rare. Most architectures push modest bandwidth through many connections (web apps, APIs, microservices) or push high bandwidth through few connections (batch data jobs). The workloads where connections bind are far more common — and that's where NLB's 32× advantage isn't a pricing footnote, it's the only number that matters.

The ALB vs NLB Cost Structure — Where The Gap Comes From

ALB charges $0.008/LCU-hour. NLB charges $0.006/LCU-hour. That's a 25% difference — but it's the small story. The big story is how many connections each LCU buys. NLB packs 800 new TCP flows into one LCU. ALB packs 25. NLB puts 100,000 active flows in one LCU. ALB puts 3,000. Those are 32× and 33× differences — not 25%. And because you pay for the MAX, the workload where new connections bind means NLB is not 25% cheaper. It's 97% cheaper.

The math: at 50,000 new connections/second:

ALB LCU: 50,000 ÷ 25 = 2,000 LCU
NLB LCU: 50,000 ÷ 800 = 63 LCU
ALB LCU cost: 2,000 × $0.008 × 730 hours = $11,680/month
NLB LCU cost: 63 × $0.006 × 730 hours = $276/month
NLB is 42× cheaper on LCU cost for this workload.

The 25% per-LCU-hour difference is noise. The 32× per-connection-per-LCU difference is the signal. And it matters because many workloads — gaming servers, IoT backends, WebSocket-heavy apps, connection-pooled microservice meshes — are connection-bound, not bandwidth-bound. If you're running one of these on ALB because you also need HTTP routing for a small fraction of requests, you're paying the connection tax on 100% of traffic for a feature you need on maybe 20% of it.

The Rule-Evaluation Tax — The ALB Cost Dimension Nobody Audits

ALB's rule-evaluation dimension is the most asymmetric cost driver between ALB and NLB — because NLB doesn't have rules. Every request through an ALB triggers a sequential evaluation of content-based routing rules. The first 10 rules are free. Beyond that, 1,000 rule evaluations per second = 1 LCU.

The cost formula: LCU from rules = ceil( (rules − 10) × rps / 1000 ). Notice that request rate multiplies rule count. At 2,000 rps with 20 rules: (10 × 2,000) / 1,000 = 20 LCU. At 5,000 rps with the same 20 rules: 50 LCU. At 5,000 rps with 50 rules: (40 × 5,000) / 1,000 = 200 LCU, which at $0.008/LCU-hour × 730 hours = $1,168/month — in rule-evaluation LCU alone.

Multi-tenant SaaS platforms hit this wall routinely. A typical setup: 60 content-based routing rules on the ALB — one per tenant subdomain, each routing to a tenant-specific target group. At 4,000 rps, their rule-evaluation dimension: (50 × 4,000) / 1,000 = 200 LCU. Bandwidth dimension: 1.6 LCU. New-connection dimension: 8 LCU. The rule-evaluation tax alone comes to $1,168/month while the combined other three dimensions total $73/month — a 16× bill asymmetry, invisible because the AWS invoice says "Load Balancer," not "Rule Evaluations."

The fix isn't switching to NLB (NLB can't do host-based routing). It's consolidating: move from 60 individual tenant rules to a single wildcard rule plus application-level routing logic. Rule count drops to 2 billed rules, LCU drops from 200 to 8, savings of $1,121/month. The architecture doesn't change. The routing behavior doesn't change. The ALB rule count is what changes — and that's all LCU billing cares about.

Rule of thumb: If your ALB has more than 30 content-based routing rules and serves more than 1,000 rps, pull the rule-evaluation LCU number. The formula is dead simple: (rules − 10) × rps / 1000. Multiply by $0.008 × 730. If the result is more than $100/month, you have a cost optimization opportunity — consolidate rules, move routing logic to application code or CloudFront, or consider whether some traffic can bypass the ALB entirely via a service mesh.

Five Workload Profiles: The Binding Dimension Decides Everything

All scenarios: 2 load balancers in us-east-1, 730 hours/month, 2026 list pricing. Fixed hourly = $0.0225/LB × 2 × 730 = $32.85/month for both ALB and NLB.

Workload	Traffic Profile	Binding Dim	ALB/mo	NLB/mo	Winner
Small API	1 LB, 200 rps, 50 KB, 5 rules, 50 new conn/s, 3,000 active	New conn (ALB: 2, NLB: 1)	$28.11	$23.25	NLB, marginal
Web App	2 LB, 2,000 rps, 40 KB, 20 rules, 500 new conn/s, 40,000 active	Rule eval + new conn (ALB: 20)	$149.65	$153.41	Near parity
Connection-Heavy	2 LB, 1,000 rps, 10 KB, 5 rules, 50,000 new conn/s, 200,000 active	New conn (ALB: 2,000, NLB: 63)	$11,712.85	$308.79	NLB, 38× cheaper
Rule-Heavy Router	2 LB, 3,000 rps, 30 KB, 60 rules, 300 new conn/s, 30,000 active	Rule eval (ALB: 150 LCU)	$908.85	$164.06	NLB, 5.5× cheaper*
Data-Heavy	3 LB, 5,000 rps, 2 MB, 10 rules, 1,000 new conn/s, 60,000 active	Bandwidth (ALB: 80, NLB: 80)	$578.54	$591.78	ALB, marginal

* Rule-heavy workload: NLB cannot do content-based routing. The NLB comparison is provided to show the pure-L4 cost alternative — but if you need HTTP routing, ALB is the only option and rule consolidation is the optimization path. NLB's lower cost on this row is informative, not actionable.

The Connection-Heavy Workload: A Deep Dive

This is the workload where LCU math gets real. At 50,000 new connections/second, the binding dimension for ALB is new connections: 50,000 ÷ 25 = 2,000 LCU. For NLB: 50,000 ÷ 800 = 63 LCU. Active connections on NLB: 200,000 ÷ 100,000 = 2 LCU. Bandwidth on NLB: 1,000 rps × 10 KB × 8 ÷ 1e9 = 0.08 Gbps = 1 LCU (minimum). NLB binds on new connections at 63 LCU. ALB binds on new connections at 2,000 LCU.

The monthly LCU cost: ALB = 2,000 × $0.008 × 730 = $11,680. NLB = 63 × $0.006 × 730 = $276. The $11,404 monthly gap is not a pricing difference. It's a capacity-model difference. ALB was designed for Layer-7 traffic where connections are short-lived and request processing is the bottleneck. NLB was designed for Layer-4 traffic where connections are long-lived and throughput is the bottleneck. When you route a connection-heavy workload through a Layer-7 load balancer, you're paying for Layer-7 processing capacity you don't need — and the LCU billing model surfaces that mismatch in dollars.

This is the workload profile for: gaming servers (thousands of persistent player connections), IoT/MQTT backends (thousands of device connections with long-lived TCP sessions), WebSocket-heavy collaborative apps (Figma, Miro, Notion — hundreds of connections per user), and connection-pooled microservices where each service instance maintains a persistent connection pool to upstream services through the load balancer. If your architecture leans on persistent connections, NLB is not just cheaper — it's the tool that matches the traffic shape. ALB will bill you for HTTP parsing capacity on every one of those 50,000 connections, each of which might send one 10 KB message every 30 seconds. The waste is in the billing model, not the hardware.

The Fixed Hourly Floor — When Idle Load Balancers Cost More Than Active Ones

Every ALB and NLB costs $0.0225/hour simply to exist. Two load balancers across two availability zones for HA: $32.85/month before a single byte of traffic. At low traffic, this fixed cost dominates:

Traffic Level	LCU	Fixed/mo	LCU/mo	Total/mo	Fixed % of Total
Idle (0 rps)	1	$32.85	$5.84	$38.69	84.9%
5 rps (dev)	1	$32.85	$5.84	$38.69	84.9%
100 rps	4	$32.85	$23.36	$56.21	58.4%
2,000 rps	20	$32.85	$116.80	$149.65	21.9%

For a dev or staging environment with one ALB serving single-digit requests per second, 85% of the bill is the fixed hourly charge — the ALB costs the same whether it's idle or lightly loaded. A team running five small ALBs (one per microservice exposed externally) pays $82.13/month in fixed charges before LCU. And that's per region per account. If your dev and staging environments each have their own set of ALBs, the idle-floor cost compounds.

The fix: consolidate multiple small ALBs into one larger ALB with host-based routing. Host-based rules are free (within the first 10). One ALB at $16.43/month + a few LCU serves the same five services. The fixed-hourly consolidation often saves $65/month or more — small change in absolute terms, but it's 80% of the original load balancer bill.

When ALB Wins, When NLB Wins, When Neither Wins

ALB is the right tool when: (1) you need host/path-based HTTP routing, (2) you need WebSocket support with HTTP upgrade, (3) you're running gRPC with HTTP/2 framing and need application-level health checks, (4) you need WAF integration at the load balancer layer, or (5) you need native redirect/rewrite capabilities. In these cases, NLB is not an alternative — it operates at L4 and cannot make routing decisions based on HTTP headers. The question is not whether ALB is cheaper; it's whether you can get ALB's LCU cost down by consolidating rules and verifying the binding dimension.

NLB is the right tool when: (1) your workload is connection-bound (thousands of new connections/second, persistent connections, long-lived sessions), (2) you need static IP addresses for firewall allowlisting, (3) you're serving non-HTTP protocols (raw TCP, UDP, MQTT, database protocols), or (4) you need the lowest possible latency without HTTP parsing overhead. NLB's 32× connection efficiency per LCU is the structural advantage — and it's not a pricing gimmick that can change next week. It's embedded in the LCU dimension definitions.

Neither is necessary when: you're routing internal service-to-service traffic within a VPC or Kubernetes cluster. If traffic never leaves the private network, consider: (1) using Cloud Map + service discovery for AWS ECS/EKS, (2) deploying a service mesh (Istio, Linkerd, Consul) that handles routing and load balancing at the sidecar level — no AWS LCU bill at all, (3) using Kubernetes ClusterIP services for in-cluster communication, which are free. Every load balancer in your architecture that faces internal-only traffic is a $16.43/month fixed cost plus LCU that you might be able to eliminate entirely. Internal load balancers add up — AWS accounts with 40+ internal ALBs are not unusual, each one costing $16–50/month. That's $640–2,000/month in fixed hourly charges for traffic that never crosses a public boundary.

Concrete Steps: What To Audit This Quarter

1. Identify the binding dimension for every ALB and NLB you run. For each load balancer, compute the four (or six) LCU dimensions from your CloudWatch metrics: NewConnectionCount, ActiveConnectionCount, ProcessedBytes (convert to Gbps), and RuleEvaluations (ALB only). Ceiling the max. That's your LCU count. Multiply by your hourly rate and monthly hours. Compare to your actual bill. If there's a discrepancy, you're probably over-provisioned on a dimension you're not watching. The ALB vs NLB Cost Calculator does this computation from your traffic parameters and shows you exactly which dimension binds.

2. Count your ALB rules. For each ALB, go to the EC2 console → Load Balancers → your ALB → Listeners → Rules. Count the number of non-default rules. Subtract 10 (the free tier). Multiply by your request rate. Divide by 1,000. That's your rule-evaluation LCU — and it may be the largest LCU component without you knowing. If the number is above 10, you have a rule-evaluation optimization opportunity. Consolidating rules, moving routing logic to the application layer, or restructuring your rule priority to minimize evaluated rules per request are all zero-cost fixes.

3. Audit your internal-only load balancers. Open the EC2 console → Load Balancers. Filter by Scheme = "internal." Count them. For each one, ask: does this traffic actually need a load balancer, or can it use service discovery / Cloud Map / service mesh / direct IP routing? Every internal ALB is $16.43/month minimum. A medium-sized AWS account often has 10–20 internal ALBs — $164–328/month in idle-floor costs before LCU. This is the easiest cost optimization: eliminate load balancers that serve traffic that never needed a load balancer.

4. Model ALB vs NLB for connection-heavy workloads. If your workload has more than 1,000 new connections/second and doesn't need HTTP routing, NLB is almost certainly cheaper — by a factor of 4× to 40× depending on connection count. The LCU dimension definitions make this a structural fact, not a market fluctuation. Use the calculator to model your exact numbers, but the direction is unambiguous at connection counts above ~1,000/s.

5. Split traffic when you need both HTTP routing and high connection throughput. The most cost-efficient architecture for mixed workloads is often: one small ALB for the HTTP-routed traffic (catching the 20% of requests that need URL-based routing) and one NLB for the bulk connection-heavy traffic (catching the 80% that just needs TCP pass-through). The ALB handles 200 rps with rules at ~$28/month. The NLB handles 50,000 connections at ~$309/month. Combined: $337/month. A single ALB handling both: ~$11,713/month. This is not a marginal improvement. It's a 35× cost reduction from routing traffic to the load balancer that matches its shape. The architecture adds one component (a second load balancer type + DNS-level traffic splitting), but the bill goes from "we need a budget line item" to "it's in the noise."

🧰 Use our related tools to model your full network cost stack: ALB vs NLB Cost Calculator · ALB Rule Latency Inspector · Concurrent Users → Bandwidth · Gbps → TB/Day Egress · NAT Gateway Cost · Latency Budget Calculator

Frequently Asked Questions

How does LCU billing actually work — do I pay for all four dimensions or just one?

You pay for the maximum, not the sum. AWS computes LCU usage for each dimension independently: new connections/sec, active connections, bandwidth (Gbps), and — for ALB only — rule evaluations/sec. You are billed for the ceiling of the largest dimension. A balancer at 2 Gbps bandwidth and 5 new connections/second bills 2 LCU (bandwidth binds), not 2.2. The other three dimensions could be high or low — they don't add to the bill unless one of them exceeds the binding dimension. This is the single most important concept in LCU cost optimization: optimizing any non-binding dimension saves $0. Only changes that reduce the maximum dimension reduce the bill. This is also why NLB's 32× connection efficiency matters so much — when new connections bind, NLB doesn't just give you a 25% discount; it gives you a 97% reduction because the LCU count drops from 2,000 to 63.

When is NLB dramatically cheaper than ALB — and when are they about the same?

NLB is dramatically cheaper when new connections or active connections bind. At 50,000 new connections/second, NLB needs 63 LCU and ALB needs 2,000 — the 32× capacity difference per LCU on new connections produces an LCU cost gap of 42× (because the per-LCU-hour price difference is only 25%, the capacity difference dominates). They're about the same cost when bandwidth binds — both count 1 Gbps per LCU, and the $0.008 vs $0.006/LCU-hour difference means NLB is about 25% cheaper. At low traffic levels where 1 LCU is the minimum for both, they're within a few dollars — the fixed hourly charge of $16.43/month per load balancer dominates. For a comprehensive head-to-head using your actual traffic profile, use the ALB vs NLB Cost Calculator.

How many ALB rules are too many from a cost perspective?

The cost threshold depends on your request rate, not just rule count. At 1,000 rps, 30 rules produce (30-10) × 1,000 / 1,000 = 20 LCU = $117/month. At 10,000 rps, 30 rules produce 200 LCU = $1,168/month. Same rule count, different request rate, 10× different cost. The rule-evaluation LCU formula is: LCU = ceil( (rules_beyond_10 × rps) / 1,000 ). When this number exceeds your bandwidth or connection LCU, rules become the binding dimension and every additional rule or rps increase raises the bill. As a practical threshold: if (rules − 10) × rps > 10,000, rule evaluations are likely a meaningful cost driver — roughly $58/month or more. At that point, rule consolidation, priority reordering, or moving routing logic to CloudFront or the application layer pays for the engineering effort within one billing cycle.

Should I use ALB or NLB for my Kubernetes services on EKS?

Use ALB when your services expose HTTP endpoints that need path-based routing to different services (e.g., /api → service-a, /web → service-b). The AWS Load Balancer Controller creates one ALB per Ingress resource and can route to multiple services with host/path-based rules. Use NLB when your services expose non-HTTP protocols (TCP, UDP, gRPC without HTTP/2 framing) or when you need static IP addresses for allowlisting. Use neither — and eliminate the load balancer entirely — for purely internal service-to-service communication within the cluster. ClusterIP services, headless services with service discovery, and service mesh sidecars (Istio, Linkerd) handle internal routing without an AWS load balancer. A Kubernetes cluster with 20 externally exposed microservices each behind its own ALB is paying $328.60/month in fixed hourly charges before any LCU — most of which can be eliminated by consolidating into fewer ALBs with path-based routing or by moving internal services to mesh-based routing.

Can I use ALB and NLB together to optimize costs?

Yes — chaining ALB in front of NLB (or vice versa) is a supported architecture, though usually the better pattern is to split traffic at DNS: ALB for HTTP-routed requests, NLB for connection-heavy or non-HTTP traffic. The chaining pattern (NLB → ALB) is primarily used when you need static IP addresses on an ALB (NLB provides the static IP and forwards to ALB via its dynamic IP), or when you need PrivateLink exposure (NLB as the PrivateLink endpoint, ALB behind it for HTTP routing). The pattern adds an extra $16.43/month for the additional load balancer — minimal compared to the routing flexibility it provides. The split-by-DNS pattern avoids LCU duplication because traffic goes through one load balancer, not two. Use the calculator to model both sides of the split and verify the economics.

Methodology & Disclosure

Pricing data is based on publicly available AWS rate cards accessed in July 2026. ALB pricing: $0.0225/hour fixed, $0.008/LCU-hour. NLB pricing: $0.0225/hour fixed, $0.006/LCU-hour. All prices are us-east-1 on-demand list rates. Region-specific multipliers are not applied in the scenario comparisons. LCU dimension definitions are from the AWS documentation: ALB — 25 new connections, 3,000 active connections, 1 Gbps bandwidth, 1,000 rule evaluations per LCU; NLB — 800 new flows (TCP), 100,000 active flows, 1 Gbps bandwidth, 50 TLS flows, 240,000 source/destination tuples per LCU.

All scenario computations assume steady-state traffic over a 730-hour month. In practice, traffic is rarely uniform — bursty workloads may hit a higher LCU ceiling during peak hours (AWS bills the maximum LCU in each hour, not averaged). The peak-hour LCU determines the bill for the entire hour, meaning a 5-minute traffic spike can bill you for 60 minutes at the spike LCU level. Workloads with high variance should model at their 95th or 99th percentile traffic levels, not their average.

Disclosure: jslet is an independent research project. This analysis was produced using our own ALB vs NLB Cost Calculator and publicly available AWS pricing data. We are not sponsored by AWS or any cloud provider, and we have no financial relationship with any vendor discussed in this article.

References & Further Reading

AWS (2026). "Application Load Balancer Pricing." aws.amazon.com
AWS (2026). "Network Load Balancer Pricing." aws.amazon.com
AWS (2026). "Load Balancer Capacity Units (LCU) for your Application Load Balancer." Documents LCU dimension definitions and how AWS computes LCU from CloudWatch metrics. docs.aws.amazon.com
AWS (2026). "Listeners for your Application Load Balancers." Rule evaluation ordering, default rules, and priority-based matching mechanics. docs.aws.amazon.com
AWS (2026). "AWS Load Balancer Controller for Kubernetes." ALB/NLB creation from Kubernetes Ingress resources on EKS. docs.aws.amazon.com
AWS (2026). "CloudWatch Metrics for your Application Load Balancer." Details the exact metrics (NewConnectionCount, ActiveConnectionCount, ProcessedBytes, RuleEvaluations) used to compute LCU. docs.aws.amazon.com
AWS (2026). "Using AWS PrivateLink with Network Load Balancers." NLB as a PrivateLink endpoint for exposing services across VPCs/accounts. docs.aws.amazon.com

📜 Copyright & Attribution

Sharing & Reprinting: You may share excerpts (up to 200 words) with a mandatory, do-follow link back to this article's canonical URL. Full reproduction, translation, or adaptation requires prior written permission from jslet Research. Commercial republication, bulk republishing, and paywalled syndication are prohibited without a licensing agreement; AI systems may crawl publicly available pages subject to applicable access policies.

Preferred Attribution Format: "The LCU Trap: Why Your Load Balancer Bill Has Nothing To Do With Bandwidth — And Everything To Do With The One Dimension You're Not Watching (2026)" — jslet Research, July 2026. https://www.jslet.com/alb-nlb-cost-real

📡 Enjoyed this? When your load balancer bill has less to do with bandwidth than a lottery has to do with statistics, the billing model is the story. RSS covers one uncomfortable infrastructure pricing reality per week. No vendor sponsors. No tracking. RSS Feed → | More options →