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
- Elastic Load Balancing pricing (LCU/NLCU pricing context)
- ALB CloudWatch metrics
- NLB CloudWatch metrics