ALB: the line item nobody watches

Application Load Balancer is the most-used and least-audited line item in AWS. Every team has one, every architecture diagram has one, and almost nobody on the team can tell you what their LCU column will look like next month. Then the bill comes in and the ALB row is bigger than the EC2 fleet the ALB is fronting.

The pricing has two halves. The hourly base is $0.0225 per ALB per hour, around $16.43 a month no matter what. The LCU-hour bills $0.008 each, and an LCU is the maximum across four dimensions: new connections per second, active connections per minute, processed bytes per hour, and rule evaluations per second. "Maximum" is the part that fools teams. You can drop one dimension to zero and save nothing, because a different dimension was the one driving your bill.

The four LCU dimensions, ranked by how often they bite

In four years of FinOps audits, the breakdown is almost always the same. Sorted by how often each one is the dominant LCU driver in real customer accounts:

1. Processed bytes. 1 GB per hour equals one LCU. This dominates for almost any team with real traffic. A single ALB at 30 GB/hour throughput is paying 30 LCU straight off the processed-bytes line, $172/month before any other dimension lights up.
2. Rule evaluations. The first 10 rules per request are free. After that, 1,000 rule evaluations per second equals one LCU. Teams with elaborate path-based routing across 20+ rules per ALB blow past the free tier on every request.
3. Active connections. 3,000 active connections per minute equals one LCU. Matters mostly for websocket and long-poll workloads. Stateless REST APIs rarely hit it.
4. New connections. 25 new connections per second equals one LCU. Connection pooling and keep-alives make this the rarest driver. If your client SDK is well-behaved, you will never hit it.

Read the actual driver from CloudWatch

Stop guessing. ALB exposes a ConsumedLCUs metric that AWS itself uses to bill you. Pull seven days at one-hour granularity and you have ground truth:

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name ConsumedLCUs \
  --dimensions Name=LoadBalancer,Value=app/my-alb/abc123 \
  --start-time $(date -u -d '7 days ago' +%FT%TZ) \
  --end-time $(date -u +%FT%TZ) \
  --period 3600 \
  --statistics Maximum

If the maximum is steady at, say, 28, that ALB cost you about $163 in LCU-hours over the week, on top of $2.69 in base hours. A small ALB. The interesting question is how many of those you have. Which brings us to inventory.

The audit that finds 30 percent in 20 minutes

Run this against every account in the org and you will find ALBs nobody remembers creating:

aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[?Type==`application`].[LoadBalancerName,DNSName,CreatedTime]' \
  --output table

Now cross-reference the list against target group health. ALBs whose target groups have zero registered targets, or all-unhealthy targets, are pure base-hour waste. We see teams running 40-60 of these in stale dev and stage accounts. Multiply by $16.43 and the result is a thousand dollars a month in pure idle.

Three patterns that quietly double the bill

After the inventory cleanup, three architectural patterns explain most of the remaining surprise:

One ALB per microservice. The ALB-per- service pattern is convenient for IaC modularity, but each service pays $16.43/mo before traffic. Twenty services means $329/mo in base hours alone. Consolidate behind a shared ALB with host-based and path-based rules and you only pay the base once.

Big payloads through ALB. Image uploads, video chunks, large JSON exports. ALB charges processed- bytes LCU on both directions. Anything that can flow through S3 presigned URLs or CloudFront should not be bouncing through ALB. We have seen image-upload paths that added $2,000/month in LCU until the team flipped to presigned URLs.

Public ALB doing service-to-service. Two services in the same VPC talking through a public ALB, because that was the URL someone copied into the config six months ago. Internal NLB or PrivateLink would skip the whole LCU bill and shave latency.

NLB vs ALB, when to switch

NLB bills NLCU (Network Load Balancer Capacity Unit), which is calculated differently and tends to be cheaper for connection-heavy, byte-light workloads. NLB is L4, so you lose host-based routing, path-based routing, OIDC auth, WAF integration, and Lambda targets. The trade is real.

Rule of thumb: keep ALB at the public edge where you need L7 features. Move internal east-west traffic to NLB or PrivateLink. The savings show up immediately and the operational model is the same.

The before-lunch change

If you read this far and want to do one thing today, run the inventory query above and delete the ALBs whose target groups are empty. That is the change with the biggest savings-per-minute ratio in the AWS catalog.

Plug your numbers into the ALB cost calculator to see which dimension is driving your bill before you start cutting. The dimension that drives it is the only one worth tuning.