Load Balancer Sizing Calculator
Size load balancer nodes, AWS ALB LCUs, connections, and throughput for failover planning.
Estimate whether a load balancer pool can handle peak RPS, concurrent connections, new connections per second, wire throughput, and availability-zone loss. Choose a generic, cloud, or proxy mode, then enter measured traffic, per-node ratings, target utilization, feature reductions, and failover reserve to find the bottleneck.
Sizing mode
Use the mode that matches how your team reads capacity: LCUs, backend target capacity, SNAT and health metrics, or proxy worker limits.
Generic mode compares request rate, active connections, connection churn, and throughput against tested per-node capacity.
Inputs
Pool, reserve, and headroom
Per-node rated capacity
Use tested capacity from the same protocol mix, TLS policy, logging, and rules you plan to run.
TLS, WAF, logging, and session controls
Availability-zone planning
Import and normalize monitoring metrics
The request and byte helpers convert time-windowed totals to RPS and throughput inputs. CSV import recognizes common metric names when a value column is present.
AWS Application Load Balancer LCU calculator
ALB LCU estimate uses the largest dimension: new connections / 25, active connections / 3000, processed GB per hour / 1, and rule evaluations / 1000. Edit the price to match your region and contract.
Results
Advertisement
Worked calculation example
Example: an API edge sees 12,000 peak RPS, 20 KiB average combined request and response payload, 1,800 new connections per second, 45 second average connection duration, 10% wire overhead, 25% design headroom, 10% worst-node imbalance, 70% target utilization, and one failed-node reserve.
connections = 1,800 x 45 = 81,000
wire throughput = 12,000 x 20 KiB x 1024 x 8 x 1.10 = 2.16 Gbps
design RPS = 12,000 x 1.25 = 15,000
design connections = 81,000 x 1.25 = 101,250
design throughput = 2.16 x 1.25 = 2.70 Gbps
With 8,000 RPS, 120,000 connections, 2,500 new connections/sec, and 3 Gbps per node, RPS and new connections each need 3 serving nodes after utilization and imbalance.
With one failed-node reserve, the plan needs 3 + 1 = 4 total nodes.
Use your monitoring data
Map provider metrics to the calculator fields before normalizing totals to per-second values.
| Provider | RPS / request count | Active connections | New connections or SYNs | Processed bytes | Health, rejects, and rule metrics |
|---|---|---|---|---|---|
| AWS CloudWatch | RequestCount over the period |
ActiveConnectionCount |
NewConnectionCount |
ProcessedBytes |
RejectedConnectionCount, HealthyHostCount, RuleEvaluations |
| Azure Monitor | Data path availability plus app gateway request metrics where applicable | SNAT connection or connection count metrics | SYN count / connection attempts | Byte count / throughput | SNAT port usage, packet count, health probe status, failed connections |
| Google Cloud Monitoring | Request count or request rate | Open connections or in-flight requests | New connection count / connection rate | Sent and received bytes | Backend utilization, healthy backends, target capacity, 5xx/rejected traffic |
| NGINX status/API | Requests delta divided by interval | Active / reading / writing / waiting | Accepted connections delta | Access log bytes or API counters | Dropped connections, upstream health, worker connections, SSL handshakes |
| HAProxy stats | rate / req_rate |
scur |
conn_rate |
bin / bout deltas |
ereq, econ, dreq, backend health, slim |
Capacity dimensions compared
| Dimension | What it means | Common metric name | Typical bottleneck | Mitigation |
|---|---|---|---|---|
| RPS / request rate | HTTP requests handled each second | Request count, rate, req_rate | CPU, rules, WAF, logging | Add nodes, cache, reduce rule cost, tune WAF/logging |
| Active connections | Open connections at the same time | Active connections, scur | Memory, sockets, idle timeout, WebSockets | Adjust keep-alive, idle timeout, worker limits, memory |
| New connections / SYNs | Connection setup rate | New connections, accepted, SYN count, conn_rate | TLS handshakes, accept queues | Reuse connections, tune SYN/accept limits, scale TLS capacity |
| Processed bytes / throughput | Traffic crossing the balancer | Processed bytes, byte count, bin/bout | NIC, packet processing, large responses | Compression, CDN, smaller payloads, faster interfaces |
| Rule evaluations | Routing or policy checks per request | Rule evaluations, WAF/rule counters | Complex listener or WAF policies | Reduce rules, move checks upstream, simplify match logic |
| Health probes | Backend eligibility and failure detection | Healthy hosts, probe status | Too few healthy targets after failure | Add healthy nodes per zone, tune probes, test failover |
| Rejected connections | Connections refused by a limit | Rejected, dropped, denied, errors | Connection queues, SNAT, listener limits | Raise limits, add nodes, reduce churn, inspect queues |
| SNAT ports | Outbound translation port capacity | SNAT port usage / allocation | Port exhaustion for outbound flows | Add outbound IPs, reduce connection churn, enable reuse |
How to use this load balancer capacity calculator
- Start with measured peak traffic: use observed busy-hour requests per second and connection rate when possible.
- Set connection behavior: short-lived HTTP connections drive new connection rate, while keep-alive and WebSocket traffic drive concurrent connections.
- Enter payload sizes: request and response payloads estimate payload throughput before protocol overhead.
- Model resilience: reserve nodes for failure, maintenance, or zone loss, then keep target utilization below the selected ceiling.
- Check the bottleneck: the highest required-node dimension is the first capacity limit to address.
Formula and assumptions
Active serving nodes: total nodes - reserved or failed nodes
Concurrent connections: new connections/sec x average connection duration
In-flight requests: requests/sec x average request time in seconds
Payload throughput: requests/sec x (request KiB + response KiB) x 1024 x 8
Wire throughput: payload throughput x (1 + protocol overhead)
Design demand: raw demand x (1 + design headroom)
Target cluster capacity: per-node rating x active nodes x target utilization
Required serving nodes: ceil(design demand x imbalance / (per-node rating x target utilization)) for each capacity dimension, then use the maximum.
Worst-node utilization includes the imbalance percentage. This models uneven distribution from hashing, persistence, uneven zones, or hot backends.
Example sizing scenarios
| Scenario | Capacity pressure | Planning note |
|---|---|---|
| API gateway | Requests per second and TLS handshakes | Use vendor ratings measured with similar TLS ciphers, WAF rules, logging, and header sizes. |
| Long-lived WebSocket or streaming clients | Concurrent connections and memory | Connection count may be the bottleneck even when request rate is low. |
| Static media edge | Throughput | Average response size can dominate node count before RPS limits are reached. |
| Short-lived mobile traffic | New connections per second | Connection churn can exhaust handshake capacity before steady-state connection count looks high. |
Requests, connections, and throughput are different limits
A load balancer can run out of capacity in several independent ways. Request processing limits are tied to HTTP parsing, policy evaluation, routing, logging, TLS termination, and response handling. Concurrent connection limits are tied to memory, socket tables, keep-alive behavior, idle timeouts, and long-lived protocols. New connection limits are tied to accept rates, SYN handling, TLS handshakes, and connection setup work.
Throughput is another limit. A workload with moderate request rate can still require many nodes if responses are large or if both request and response bodies traverse the balancer. This calculator separates payload throughput from protocol overhead, then applies design headroom and target utilization so the estimate reflects a production planning posture rather than a perfect-lab maximum.
For production planning, replace the default per-node values with capacity test results from your own load balancer model, configuration, TLS policy, WAF rules, logging pipeline, and observability stack. Vendor headline ratings may be measured under ideal packet sizes or feature sets that do not match your deployment.
Methodology
The calculator turns traffic assumptions into four design demand dimensions: requests per second, concurrent connections, new connections per second, and wire throughput. It compares each dimension with the active cluster capacity after reserved nodes are removed and target utilization is applied. The largest required-node count is reported as the bottleneck.
Last reviewed: June 2026. Calculations are deterministic arithmetic and run locally in your browser.
FAQs
How many requests can a load balancer handle?
There is no universal number. Use tested per-node RPS for your load balancer type, enabled features, payload size, and policy stack, then apply target utilization, headroom, imbalance, and failover reserve.
How do I calculate AWS ALB LCUs?
Calculate each LCU dimension separately: new connections, active connections, processed bytes, and rule evaluations. The hourly LCU estimate is the largest dimension.
What is the difference between RPS and concurrent connections?
RPS measures request processing rate. Concurrent connections measure open sockets and long-lived sessions. A WebSocket workload can have low RPS but high concurrent connection pressure.
What is the difference between active connections and new connections?
Active connections are already open. New connections per second are setup events, which stress accept queues, SYN handling, TLS handshakes, and connection churn.
What causes rejected connections?
Rejected connections often indicate a listener, queue, SNAT pool, socket table, target group, or node-level limit. Compare rejected counts with active connections, new connections, and health metrics.
What is a safe target utilization for load balancers?
Many teams plan around 60% to 80% of tested capacity, then tune based on burst behavior, deployment risk, autoscaling speed, and failover requirements.
How much headroom should I use?
For production planning, 20% to 40% is a common starting range. Use more when traffic is bursty, autoscaling is slow, or a full-zone loss must be absorbed immediately.
How do sticky sessions affect capacity?
Sticky sessions can concentrate traffic on fewer nodes or backends. Model that with higher worst-node imbalance or a tested capacity reduction.
Should I size for total nodes or active nodes?
Size demand against active serving nodes after reserved or failed nodes are removed. Total nodes should include the reserve needed for maintenance or failure.
Why include new connections per second?
Short-lived traffic, TLS handshakes, and client churn can overload connection setup paths even when concurrent connections look acceptable.
Does this model backend server capacity?
No. It sizes the load balancer layer only. Backend pools, databases, caches, DNS, and upstream network links need separate checks.
How should I size for WebSockets?
Use measured peak active connections and connection duration. WebSocket and streaming designs usually bottleneck on memory, sockets, idle timeout, and per-connection state before RPS.
How do health checks affect failover?
Health checks decide which nodes and targets can receive traffic. For failover, size against healthy nodes per zone after a one-node or one-zone loss scenario.
Is this calculator private?
Yes. Inputs are processed locally and are not submitted to a server.
Disclaimer
This is an infrastructure planning aid, not a vendor guarantee or safety certification. Validate production designs with load testing, vendor documentation, observability data, failure drills, and change-management requirements.