Most AWS bills have a line item that’s easy to reason about: instance hours, GB stored, requests served. Application Load Balancer pricing isn’t one of those. It looks like a flat hourly rate on the pricing page, but the number that actually shows up on your invoice is driven by a unit called the Load Balancer Capacity Unit (LCU) — and most teams never figure out which dimension of their traffic is the one AWS is charging them for.
The two-part bill
Every ALB bills two things every month:
- A fixed hourly charge per load balancer (~$0.0225/hour, ~$16.43/month at 730 hours) — the same regardless of traffic.
- LCU-hours — a usage-based charge (~$0.008 per LCU-hour) that scales with how hard the ALB is working.
The fixed part is easy. The LCU part is where the confusion starts.
What one LCU actually covers
AWS defines an LCU as the maximum of four independent measurements, sampled every hour:
- New connections: 25 per second
- Active connections: 3,000 (sampled per minute)
- Processed bytes: 1 MB per second
- Rule evaluations: 1,000 per second
Here’s the part that trips people up: AWS doesn’t sum these four numbers and bill you for the total. It calculates each dimension’s LCU count independently, takes the highest one, and bills you only for that. A traffic pattern that’s heavy on rule evaluations but light on bandwidth pays for rule evaluations — the bandwidth number is irrelevant to the bill, no matter how large it grows, as long as it stays below whichever dimension is already driving the cost.
Why this matters for optimization
This billing model means a lot of intuitive cost-cutting moves do nothing:
- Reducing listener rules doesn’t save money if new-connection volume is your driver.
- Enabling keep-alive to cut active connections doesn’t save money if rule evaluations are the bottleneck.
- Shrinking payload size doesn’t save money if new connections are already the highest dimension.
The only lever that moves your bill is whichever dimension is currently the maximum. Everything else is free headroom you’re not using yet.
A worked example
Say you’re running 200 requests/second, each connection held for 2 seconds, average payload 4 KB, and 5 listener rules evaluated per request:
- New connections: 200 / 25 = 8 LCU
- Active connections: (200 × 2) / 3,000 = 0.13 LCU
- Bandwidth: (200 × 4 KB / 1024) / 1 = 0.78 LCU
- Rule evaluations: (200 × 5) / 1,000 = 1 LCU
The driver here is new connections at 8 LCU — nearly 10x the next-highest dimension. If your goal was to cut cost, adding more routing rules or increasing payload size costs nothing extra, since neither would surpass 8 LCU. The only way to reduce the bill is to reduce new-connection volume — for example, by enabling HTTP keep-alive on clients so fewer connections are established for the same request volume.
Working it out for your own traffic
Guessing which dimension dominates is unreliable once you have more than one traffic shape running through an ALB — API traffic, WebSocket upgrades, and static asset proxying all stress different dimensions. Our AWS ALB Pricing Calculator runs all four LCU formulas from your actual RPS, connection duration, payload size, and rule count, and highlights which dimension is currently your billing driver — so you can tell in advance whether a proposed change (more rules, bigger payloads, longer-lived connections) actually touches your bill or not.
If you’re deciding between an ALB and API Gateway in the first place, the API Gateway vs ALB Cost Comparison calculator finds the traffic-volume breakpoint where one becomes cheaper than the other — useful before you commit to either architecture.