⚖️ Load Balancer Ingress Rule Latency
Each ALB rule adds ~0.12 μs of evaluation overhead — not the "1 ms" that gets repeated in blog posts, which is off by four orders of magnitude. Rule count still matters, but not the way that folk number implies: 80 rules at 10,000 rps burns about 48 ms of CPU every second, and ALB's hard ceiling of 100 rules per listener forces an architecture decision long before latency does. Input your rule count and evaluation model — first-match linear scan vs. prefix-trie — and quantify the real tax.
📐 Ingress Rule Configuration
Set rule count and evaluation model. First-match linear scan costs ~0.12 μs per rule. Prefix-trie ~0.04 μs per rule. Choose your architecture. The engine computes per-request overhead, the aggregate CPU tax at 10,000 rps, and how much of a core it consumes.
Load Balancer Rule Count and Latency: The Microsecond Tax
Every rule added to a load balancer's ingress configuration imposes a per-request evaluation cost. While individual rule evaluation times are measured in nanoseconds — typically 40 to 120 ns per rule depending on the matching algorithm — these costs compound linearly with rule count and accumulate across the request rate. A load balancer processing 10,000 requests per second with 80 active rules under a first-match model can burn approximately 48 milliseconds of CPU time per second purely on rule evaluation, consuming nearly 5% of a single vCPU core before any application logic executes.
How This Calculator Works
| Model | Per-Rule Cost | Avg Overhead Formula | P99 Overhead Formula |
|---|---|---|---|
| First-Match (Linear Scan) | 0.12 μs per rule | (Rules ÷ 2) × 0.12 μs | Rules × 0.12 μs |
| Prefix-Trie (Tree Search) | 0.04 μs per rule | (Rules ÷ 2) × 0.04 μs | Rules × 0.04 μs |
The first-match model (used by AWS ALB listener rules and many simple reverse proxies) evaluates rules sequentially until a match is found. On average, the matching rule sits at the midpoint of the rule list, giving O(n/2) average case and O(n) worst case. The prefix-trie model (used by NGINX with prefix-based location blocks and HAProxy with ACL trees) organizes rules into a radix tree, achieving O(log n) or near-constant evaluation time regardless of rule count — at the cost of more complex configuration semantics when rules have overlapping path patterns.
Minimizing Rule Count in Production
High rule counts typically arise from path-based routing proliferation — one rule per microservice endpoint. Consolidating rules using wildcard prefixes (/api/* instead of /api/users, /api/orders, etc.) and offloading fine-grained routing to a service mesh (Istio, Linkerd) or API gateway dramatically reduces load balancer rule count. A well-architected ingress layer should have fewer than 50 rules; beyond 100 rules, the linear-scan overhead becomes measurable in P99 latency at moderate traffic volumes. For AWS ALB specifically, the hard limit is 100 rules per listener — if you are approaching that, your routing architecture needs refactoring.