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


Related guides


Related calculators


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