Estimate ALB LCU (and NLB NLCU) from metrics: quick methods

LCU/NLCU bills are hard to predict until you translate metrics into capacity units per hour. The most reliable approach is: pull the driver metrics, compute average + p95, then estimate units/hour (LCU/NLCU) and price them. This guide focuses on getting to a defensible estimate quickly.

Step 1: choose a representative window (and define peak hours)

  • Budget baseline: pick a “normal week” and compute averages.
  • Peak scenario: define what peak means for you (p95 hour, busiest day, or incident window).
  • Separate non-prod: dev/test often has very different patterns (and can be scheduled).

Step 2: collect the driver metrics

You can estimate from the provider’s “LCU-like” metric if available, but a portable approach is to collect the driver inputs and let a calculator map them to units.

  • New connections (per second average)
  • Active connections (average concurrent)
  • Bytes processed (convert to GB/hour)
  • Rule evaluations (ALB-focused driver when you have complex routing)

Step 3: turn CloudWatch sums into per-second / per-hour numbers

CloudWatch often provides metrics as a Sum over a period. To convert:

  • Per-second average = sum over period / seconds in period
  • Per-hour GB = bytes over hour / 1e9 (or use your provider’s convention consistently)

If you only have Mbps charts, convert to GB/month first using Units converter, then back into GB/hour for unit estimates.

Step 4: estimate units/hour (LCU/NLCU)

Capacity unit billing typically takes the maximum across the dimensions (connections, bytes, rules). The easiest way to avoid mistakes is to use a calculator that implements the provider’s mapping.

Step 5: price units/hour + the fixed LB hourly fee

  • Monthly usage cost ≈ avg units/hour × hours/month × $/unit-hour
  • Monthly fixed cost ≈ LB count × hours/month × $/LB-hour

Step 6: add a peak scenario (the part that prevents under-budgeting)

  • Compute p95 (or busiest hour) units/hour and multiply by peak hours/month.
  • Decide if peak happens daily (baseline) or only during incidents (rare).
  • Include retries/timeouts: incident traffic often multiplies connections and bytes.

Common mistakes

  • Using peak-only metrics for the whole month (overestimates baseline).
  • Ignoring peak scenarios entirely (underestimates budgets).
  • Mixing units (GB vs GiB, bytes vs bits) and getting a silent 1.07× or 8× error.
  • Estimating from request rate only and forgetting payload size and connection churn.
  • Not validating after changes (routing tweaks and retries can shift the dominant driver).

Sources


Related guides


Related calculators


FAQ

What do I need to estimate LCU/NLCU?
Average new connections/sec, average active connections, and bytes processed per hour. For ALB, rule evaluations can be an additional driver depending on configuration.
Should I use average or peak metrics?
Use averages for a monthly budget and add a peak scenario for busy/incident hours. Many bills are driven by a small number of repeatable peak periods.
What’s the fastest workflow?
Extract driver metrics for a representative window, compute average units/hour with a calculator, then price units/hour plus the fixed LB hourly fee. Validate after a week and refine the peak scenario.

Last updated: 2026-01-27