Estimate ALB LCU (and NLB NLCU) from metrics: quick methods
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
This page is the measurement workflow, not the bill-boundary page: the goal is to turn CloudWatch metrics for new connections, active connections, processed bytes, and rule activity into a defendable units-per-hour model. LCU/NLCU bills are hard to predict until you translate metrics into capacity units per hour.
If you still are not sure which costs belong inside the load balancer bill versus beside it, go back to the pricing guide first. Open the pricing guide.
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.
Evidence pack before you trust the model
- Average hours: a normal week of metrics for baseline unit-hours.
- Peak hours: p95 or incident-hour samples so repeat spikes do not disappear in the monthly average.
- Driver attribution: identify whether bytes, new connections, active connections, or rules are dominant.
- Non-prod separation: keep staging or dev behavior out of the production model unless it truly shares the bill.
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).
Next step after the model is believable
Once you know which dimension dominates and whether peak behavior is normal or incident-driven, move to load balancer cost optimization. Keep the pricing guide nearby when bill scope questions reappear.
Sources
- Elastic Load Balancing pricing (LCU/NLCU pricing context)
- ALB CloudWatch metrics
- NLB CloudWatch metrics