Load balancer costs: what to include beyond node spend
Load balancers become a major line item when you have many always-on LBs or when traffic patterns drive high capacity unit usage. A good estimate separates LB-hours (how many) from usage (how busy) and validates both with real metrics.
The cost model (simple and reliable)
- Fixed: load balancer count × hours/month × $/LB-hour
- Usage: avg LCU/NLCU per hour × hours/month × $/unit-hour
- Peak scenario: repeat the usage line for “busy/incident hours” if peaks happen frequently
Tooling: load balancer cost calculator and LCU/NLCU calculator.
What drives LCU/NLCU usage (the part that surprises budgets)
Capacity unit billing is usually the max of several dimensions. The exact thresholds depend on the product, but the drivers are consistent:
- New connections rate: many short-lived connections increase units.
- Active connections: long-lived connections (streaming/WebSockets) increase units.
- Bytes processed: large downloads/uploads and uncompressed payloads increase units.
- Rules/processing: complex routing can add a separate driver in some models.
Deep dive: LCU/NLCU explained and estimate LCU from metrics.
Common architecture patterns that inflate LB spend
- One load balancer per service (especially in Kubernetes): LB-hours scale with microservice count.
- “Everything through the LB”: large static assets and downloads that should be cached at the edge.
- Retry storms: incidents multiply requests and connections even if successful traffic is unchanged.
- Chatty clients: frequent reconnects and short timeouts increase new connections.
- Cross-AZ routing: can add transfer costs outside the load balancer line item.
How to validate the estimate (in one week)
- Count load balancers and confirm they’re intentional (remove abandoned ones).
- Pull a representative week of metrics and compute avg + p95 LCU/NLCU per hour.
- Compare peak hours: are they daily (baseline) or rare (incidents)?
- Cross-check the “top drivers” against reality: bytes processed vs connection churn vs rules.
Quick inventory worksheet (copy/paste)
- LB count: how many per environment (prod/stage/dev) and why each exists
- Hours: always-on (730) vs scheduled (business hours)
- Average units/hour: LCU/NLCU from a representative week
- Peak units/hour: p95 hour and “incident hour” scenarios
- Bytes processed: GB/hour baseline and peak
- Connection churn: new connections/sec during normal vs incident windows
This worksheet is enough to find whether you should optimize LB-hours (count) or unit-hours (traffic patterns).
Next steps
Sources
- Elastic Load Balancing pricing
- ALB CloudWatch metrics (for estimation inputs)
- NLB CloudWatch metrics (for estimation inputs)
Related guides
EKS pricing: what to include in a realistic cost estimate
A practical EKS pricing checklist: nodes, control plane, load balancers, storage, logs/metrics, and data transfer — with calculators to estimate each part.
AWS cross-AZ data transfer cost: causes and estimate steps
A practical guide to AWS cross-AZ data transfer costs: common causes (load balancers, databases, Kubernetes), how to estimate GB crossing zones, and how to reduce it safely.
ECS vs EKS cost: a practical checklist (compute, overhead, and add-ons)
Compare ECS vs EKS cost with a consistent checklist: compute model, platform overhead, scaling behavior, and the line items that often dominate (load balancers, logs, data transfer).
Estimate ALB LCU (and NLB NLCU) from metrics: quick methods
A practical guide to estimate ALB LCU and NLB NLCU from load balancer metrics: new connections, active connections, bytes processed, and rule evaluations — with a repeatable workflow and validation steps.
Load balancer cost optimization (high-leverage fixes)
A practical playbook to reduce load balancer costs: cut LB-hours, reduce LCU/NLCU drivers (connections/bytes/requests), and prevent incident traffic amplification with a measurable validation plan.
Load balancer LCU/NLCU explained (for cost estimates)
A practical explanation of LCU/NLCU billing: what capacity unit-hours represent, which traffic patterns drive them, and how to reason about budgets before you have perfect metrics.
Related calculators
Kubernetes Cost Calculator
Estimate cluster cost by sizing nodes from requests and pricing them.
Kubernetes Node Cost Calculator
Estimate cluster monthly cost from node count and per-node hourly pricing.
Kubernetes Observability Cost Calculator
Estimate log + metrics observability costs for Kubernetes.
FAQ
What are the two main load balancer cost components?
A fixed hourly charge per load balancer plus a usage-based component (often billed as LCU/NLCU hours) driven by traffic and connection patterns.
Why does cost spike even when compute is stable?
Because load balancer usage scales with requests, connections, bytes processed, and rule evaluations/TLS overhead depending on the product—even if your instances are unchanged.
What’s the fastest way to estimate load balancer cost?
Count load balancers (LB-hours), estimate average LCU/NLCU per hour from metrics, then price both components. Add a peak scenario for incident hours.
Last updated: 2026-01-27