How is AWS load balancer cost actually calculated?

You are billed for the maximum LCU across four independent dimensions — new connections, active connections, bandwidth, and rule evaluations — not the sum. One LCU is the smaller of the two capacities per dimension, and each dimension is rounded up separately. This calculator reproduces that logic with real 2026 pricing so you can compare ALB vs NLB side by side for your exact traffic profile.

Why does ALB cost more than NLB for the same traffic?

ALB bills a fifth dimension — rule evaluations — that NLB does not have. Every rule you add to an ALB costs processing time that counts toward LCUs, so a balancer with many routing rules can rack up significant rule-evaluation charges even with modest traffic. NLB skips that dimension entirely, which is why for pure L4 traffic NLB is usually cheaper. The calculator lets you toggle your rule count and see the exact delta.

What is the fixed hourly floor in the pricing model?

Every load balancer also has a flat per-hour charge that you pay regardless of traffic. At 2026 prices that fixed component alone adds up across multiple balancers and AZs, and it is the reason a mostly-idle ALB still shows up on your bill. This tool includes that floor in the monthly projection, so the number you get is the real billable amount, not just the traffic portion.

AWS ALB vs NLB Cost Calculator — Pay for the Max LCU Dimension (2026)

AWS ALB vs NLB Cost Calculator

Load balancers don't bill by throughput. They bill by LCU — Load Balancer Capacity Units — and you pay for the single largest dimension, not the sum of them. A balancer pushing 2 Gbps but only 5 new connections/sec still bills 2 LCU, because bandwidth is the binding dimension. ALB and NLB price LCU differently ($0.008 vs $0.006) and count dimensions differently (ALB caps at 25 new connections/LCU; NLB tolerates 800). This calculator models both against your exact traffic: new connections, active connections, bandwidth, and — for ALB — rule evaluations beyond the first 10. Then it puts ALB and NLB head to head.

📐 Traffic Profile

Describe your load balancer's steady-state traffic. The engine computes LCU for both ALB and NLB from the same numbers and shows which dimension binds each. All four LCU dimensions are evaluated; the max wins.

Number of Load Balancers

Requests per Second (avg)

New Connections/sec

Active (Concurrent) Connections

Avg Request + Response Size (KB)

Content-Based Rules (beyond first 10, free)

Hours per Month (billing)

NLB terminates TLS (adds TLS-flow dimension) NLB preserves client IP:port (adds tuple dimension)

Scenario Preset

AWS Region

📊 Monthly Load Balancer Cost — ALB vs NLB

💰 Total Monthly Cost

Type	LCU	Binding Dimension	Fixed $/mo	LCU $/mo	Total/mo	Annual

🧱 LCU Dimension Breakdown (which one binds you?)

📋 ALB / NLB LCU & Pricing Reference (2026)

One LCU = the smaller of the two capacities per dimension. You are billed for the MAX of the dimensions, rounded up. Fixed hourly is per load balancer. us-east-1 baseline; other regions vary ±10%.

Dimension	ALB per LCU	NLB per LCU
New connections / flows per sec	25	800 (TCP)
Active connections / flows	3,000	100,000
Bandwidth	1 Gbps	1 Gbps
Rule evaluations per sec (ALB)	1,000	—
New TLS flows per sec (NLB)	—	50
Source/dest IP tuples (NLB)	—	240,000
Price per LCU-hour	$0.008	$0.006
Fixed per LB-hour	$0.0225	$0.0225

ALB rule evaluations count only rules evaluated beyond the first 10 free rules. NLB bandwidth per LCU is 1 Gbps for both TCP and TLS. Source: AWS Pricing Calculator, July 2026. Verify against your region.

The Dimension You're Not Watching Is the One You Pay For

Most teams size a load balancer by "how much traffic" and stop. But LCU billing doesn't care about your gut feel — it cares about four independent dimensions, and bills you for whichever is largest. Get the largest one wrong and you either over-provision (paying for LCU you don't use) or, worse, you assume NLB is always cheaper and miss that ALB's rule-evaluation dimension is silently the binding constraint on a path-based routing setup.

1. "Pay for the Max, Not the Sum" — The Core Rule

Four dimensions are computed. The LCU count is the ceiling of the maximum, not the total. A balancer at 2 Gbps, 5 new conn/s, 3,000 active, 100 rule-evals/s computes LCU = max(2/1, 5/25, 3000/3000, 100/1000) = max(2, 0.2, 1, 0.1) = 2 LCU. Bandwidth binds. Doubling active connections to 6,000 (2 LCU) or adding 50 rules (still 0.05 LCU) changes nothing — you're already capped by bandwidth. This is why throwing more rules at an ALB usually costs $0 until you cross a dimension boundary. The calculator shows you exactly which dimension is binding so you know what actually moves the bill.

⚡ The Insight: If your binding dimension is bandwidth, ALB and NLB cost the same per Gbps (both 1 Gbps/LCU) — NLB is only 25% cheaper because its LCU-hour is $0.006 vs $0.008. But if your binding dimension is new connections, NLB is 32× more efficient (800 vs 25 per LCU). The workload shape, not the vendor, decides the gap.

2. The Rule-Evaluation Gotcha (ALB Only)

ALB counts rule evaluations at 1,000 per LCU-second — but only for rules evaluated beyond the first 10. Ten free rules is a lot; most simple path-based setups never cross it. The moment you do — 50 content-based rules on a 2,000 rps endpoint evaluates 2,000 × 40 = 80,000 rule-evals/s = 80 LCU from rules alone, which can become the binding dimension even when bandwidth is modest. This is the trap: a URL-rewrite-heavy ALB can bill more in rule LCU than in bandwidth LCU. NLB has no rule concept at all — another reason NLB wins pure L4 workloads.

3. ALB vs NLB — When Each Wins

Need	Use ALB when…	Use NLB when…
HTTP routing	Path/host-based rules, redirects, auth, gRPC, WebSocket upgrade	Not applicable — L4 only
Connection rate	Fine up to ~tens of k new conn/s before LCU explodes	800 new flows/LCU — absorbs hundreds of k/s cheaply
Latency	+1 rule = +~1ms (see ALB Rule Latency Inspector)	Lowest latency, no HTTP parsing, static IP option
Cost at high conn	Pricier per connection	Up to 32× cheaper on connection-bound workloads
TLS termination	Native, offloaded	Supported, adds TLS-flow LCU dimension

4. The Fixed Hourly Floor

Every load balancer costs $0.0225/hr = $16.43/month before a single request. Two balancers in two AZs for HA = $32.86/mo floor. At low traffic this fixed cost dominates — a dev ALB serving 5 rps still costs ~$16/mo. If you're running multiple ALBs for marginal traffic, consolidating behind one ALB with host-based routing (free rules!) often cuts the fixed floor in half. The calculator's fixed-vs-LCU split makes this visible.

5. Who Should Care Most

Profile	Typical Monthly Bill	What This Calculator Reveals
Small API / internal	$16–40/mo	Fixed hourly floor dominates. One ALB, host-based routing beats three separate ALBs. NLB unlikely to help at this scale.
Standard web app	$40–200/mo	Bandwidth usually binds. ALB vs NLB within 25%. Rule count matters only if you exceed 10 content rules at high rps.
Connection-heavy (games, MQTT, IoT)	$200–2,000/mo	New-connection dimension binds. NLB is dramatically cheaper — 32× more efficient per LCU. Switching can cut the bill 3–5×.
Rule-heavy edge router	$150–1,000/mo	Rule-eval LCU can become binding. Audit rule count; NLB can't do the routing, so the fix is rule consolidation, not LB swap.