ALB pricing: what an LCU actually is (2026)

A load balancer bills two things: an hourly charge, and capacity units. The capacity unit is where the money hides, because an ALB measures four separate dimensions and charges you for only one of them, the largest. Most people optimise the wrong one.

What is a Load Balancer Capacity Unit?

A unit of work with four independent definitions. Per the Elastic Load Balancing pricing page, "You are also charged for the number of Load Balancer Capacity Units (LCU) used per minute", and an Application Load Balancer LCU contains all four of these at once:

The sentence that decides everything: "You are charged only on the dimension with the highest usage." Not the sum. AWS's own example spells it out, "your actual usage was at 240 LCUs based on the highest usage of the four dimensions measured."

Why does that change what you should optimise?

Because effort spent on any dimension that is not currently the highest saves exactly nothing. Halving your payload size on a load balancer whose bill is driven by new connections changes the invoice by zero.

Work out which dimension is binding before touching anything. Divide each measured value by its LCU allowance and compare:

The largest of those four is your bill. CloudWatch publishes the inputs, so this is a query rather than a guess:

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name ConsumedLCUs \
  --dimensions Name=LoadBalancer,Value=app/my-alb/0123456789abcdef \
  --start-time 2026-07-01T00:00:00Z --end-time 2026-07-08T00:00:00Z \
  --period 3600 --statistics Sum Maximum

ConsumedLCUs gives the billed total but not which dimension produced it. For that, pull NewConnectionCount, ActiveConnectionCount, RuleEvaluations and ProcessedBytes over the same window and run the division above. In practice one dimension dominates by a wide margin and it is rarely the one people expect. The full metric list is in the ALB CloudWatch metrics reference, and the NLB equivalent for network load balancers.

Which dimension usually turns out to be the expensive one?

New connections, on APIs, and it is almost always a client that is not reusing them. Put the two connection dimensions on the same time base and the gap is clear: 25 new connections per second is 1,500 a minute, against an allowance of 3,000 active connections a minute. So an LCU tolerates only twice as many connections opened per minute as it does connections held open, and a client that opens a fresh TCP connection for every request converts every request into a new connection. Keep-alive is worth more here than any payload optimisation.

Two documented details change the arithmetic and both are easy to miss.

• Mutual TLS halves the active connection allowance. The pricing page lists "3,000 active connections per minute or 1,500 active connections per minute while using Mutual TLS." Turning on mTLS can double the LCU count on that dimension with no traffic change.
• Certificate choice affects the new connection allowance. "For HTTPS listeners, 25 new connections/sec for LCU computation is applicable for RSA certificates with key size <=2K and ECDSA certificates with key size <=256." A larger key means fewer connections per LCU.

Do listener rules cost anything?

Not until you have more than ten. The pricing page is specific: "If you have 10 or fewer rules configured, the rule evaluations dimension is ignored in LCU computation."

So the eleventh rule is the one that starts a meter, and thereafter rule evaluations scale with request rate multiplied by rules evaluated. On a busy ALB carrying a large rule set for host-based routing, this dimension can quietly become the highest one. Consolidating rules is then the cheapest possible fix, and the listener rules documentation covers how conditions are evaluated against the per-listener quota, and it is invisible if you only look at bytes.

How is a Network Load Balancer different?

Different unit, fewer dimensions, and the values are not comparable. NLB bills NLCUs, and the pricing page states you "are charged only on one of the three dimensions that has the highest usage for the hour." The contents also depend on protocol:

Note the target type clause, because it is a real trap: bandwidth is "1 GB per hour for Amazon Elastic Compute Cloud (EC2) instances, containers, and IP addresses as targets, and 0.4 GB per hour for Lambda functions as targets." Pointing an NLB at Lambda gives you 40% of the bandwidth allowance per NLCU, so the same traffic costs 2.5 times as many capacity units.

Target types and their constraints are set out in the NLB target group documentation.

The active-connection gap is the widest of all: 100,000 active TCP connections per NLCU against an ALB's 3,000. A TCP NLB also tolerates 800 new connections per second per NLCU against an ALB's 25. If your workload is connection-heavy and does not need HTTP routing, that ratio is the whole argument.

Does an idle load balancer cost anything?

Yes. "You are charged for each hour or partial hour that an Application Load Balancer is running", and the same sentence appears for Network Load Balancer. The hourly charge applies with zero requests, which makes a forgotten load balancer in a dev account the same class of waste as an idle NAT Gateway or an unattached Elastic IP.

An internet-facing load balancer also holds a public IPv4 address in each Availability Zone it serves, and those bill separately at $0.005 per hour each. Across three zones that is $10.95 a month before a single request arrives.

There is now also a reservation option. Per the pricing page, "If you use Load Balancer Capacity Unit Reservation, you are charged for each hour that the Application Load Balancer is running, the number of Load Balancer Capacity Units (LCU) reserved per minute, and additional number of LCUs used per minute beyond your reserved LCUs per hour." It is a commitment on top of the hourly charge, not a replacement for it, so measure your steady-state LCU count first.

Where does this land in your bill?

Under Elastic Load Balancing, split by usage type, with the hourly charge and the LCU charge as separate strings. Group by usage type rather than by service, the same technique that resolves the EC2 - Other bucket:

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost UsageQuantity \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Elastic Load Balancing"]}}'

If the LCU line is small relative to the hourly line, you have too many load balancers rather than too much traffic, and consolidation is the lever. If the LCU line dominates, run the four-way division above before changing anything.

One charge that does not appear here at all: the traffic a load balancer sends to targets in another Availability Zone. That is cross-AZ data transfer at $0.01 per GB in each direction, billed under EC2. And it is not optional on an ALB: AWS states that "With Application Load Balancers, cross-zone load balancing is on by default and cannot be changed at the load balancer level", so the only place to influence it is the target group. It is frequently larger than the LCU charge it accompanies.