Starlight Tools

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.

All calculations run locally in your browser. Use measured traffic and vendor-tested ratings for production decisions.

Inputs Results Fit: - Nodes: -

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
Applied to the per-node ratings after vendor or lab testing.
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.

Workload presets
Capacity posture presets

Results

Fit status-
Bottleneck-
Required serving nodes-
Required total nodes-
Design demand
Requests per second:-
Concurrent connections:-
New connections per second:-
Wire throughput:-
In-flight requests estimate:-
Active pool under reserve
Active serving nodes:-
Effective per-node capacity factor:-
Target RPS capacity:-
Target connection capacity:-
Target new-connection capacity:-
Target throughput capacity:-
Zone planning
Required serving nodes per surviving zone:-
Effective healthy nodes after scenario:-
Zone capacity result:-
AWS ALB LCU estimate
Required LCUs:-
Largest LCU dimension:-
Estimated hourly/monthly LCU cost:-
Worst-node utilization
Requests:-
Connections:-
New connections:-
Throughput:-

Next steps

    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.

    Workload demand

    connections = 1,800 x 45 = 81,000

    wire throughput = 12,000 x 20 KiB x 1024 x 8 x 1.10 = 2.16 Gbps

    Headroom demand

    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

    Node requirement

    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 rateHTTP requests handled each secondRequest count, rate, req_rateCPU, rules, WAF, loggingAdd nodes, cache, reduce rule cost, tune WAF/logging
    Active connectionsOpen connections at the same timeActive connections, scurMemory, sockets, idle timeout, WebSocketsAdjust keep-alive, idle timeout, worker limits, memory
    New connections / SYNsConnection setup rateNew connections, accepted, SYN count, conn_rateTLS handshakes, accept queuesReuse connections, tune SYN/accept limits, scale TLS capacity
    Processed bytes / throughputTraffic crossing the balancerProcessed bytes, byte count, bin/boutNIC, packet processing, large responsesCompression, CDN, smaller payloads, faster interfaces
    Rule evaluationsRouting or policy checks per requestRule evaluations, WAF/rule countersComplex listener or WAF policiesReduce rules, move checks upstream, simplify match logic
    Health probesBackend eligibility and failure detectionHealthy hosts, probe statusToo few healthy targets after failureAdd healthy nodes per zone, tune probes, test failover
    Rejected connectionsConnections refused by a limitRejected, dropped, denied, errorsConnection queues, SNAT, listener limitsRaise limits, add nodes, reduce churn, inspect queues
    SNAT portsOutbound translation port capacitySNAT port usage / allocationPort exhaustion for outbound flowsAdd outbound IPs, reduce connection churn, enable reuse

    How to use this load balancer capacity calculator

    1. Start with measured peak traffic: use observed busy-hour requests per second and connection rate when possible.
    2. Set connection behavior: short-lived HTTP connections drive new connection rate, while keep-alive and WebSocket traffic drive concurrent connections.
    3. Enter payload sizes: request and response payloads estimate payload throughput before protocol overhead.
    4. Model resilience: reserve nodes for failure, maintenance, or zone loss, then keep target utilization below the selected ceiling.
    5. 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.

    Explore more tools