Envoy Proxy Capacity Calculator

Calculate the request throughput capacity of an Envoy proxy instance.

About Envoy Proxy Capacity Calculator

Envoy's memory footprint combines a fixed base cost with two dynamic components that scale with load: memory = base_memory + connections × per_conn_memory + routes × per_route_memory. Connection state (buffers, TLS session data, HTTP/2 stream state) usually dominates for high-throughput proxies, while very large route tables (thousands of virtual hosts) can make route memory a significant factor in API gateway or ingress deployments.

Formula

max_rps = (cpu_cores × 1000) / cpu_per_request_millicores

cpu_cores: CPU cores allocated to Envoy proxy
cpu_per_request_millicores: CPU consumed per proxied request (millicores)

Worked example

With the default values below, Envoy Proxy Capacity Calculator returns Total Envoy Memory of 249.2. Change any input above and every figure here is recalculated in your browser.

Inputs used

Concurrent Connectionsaccepts 0–10,000,000 connections: 5,000 connections
Memory per Connectionaccepts 0.1–100,000 KB: 40 KB
Configured Routesaccepts 0–1,000,000 routes: 500 routes
Memory per Routeaccepts 0.01–100,000 KB: 8 KB
Base Memory Footprintaccepts 0–100,000 MB: 50 MB

Results

Total Envoy Memory: 249.2 MB
Total Envoy Memory: 0.243 GiB
Connection Memory Share: 78.4%
Route Table Memory Share: 1.6%

Step by step

1Connection memory: connections × per-conn memory= 200,000 KB
2Route memory: routes × per-route memory= 4,000 KB
3Total memory: base + connections + routes= 249.2 MB

Assumptions and limits

The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why does memory per connection vary so much between workloads?

TLS termination, HTTP/2 multiplexing, and large request/response buffering all increase per-connection memory significantly compared to simple plaintext TCP proxying — profile your actual Envoy instances under representative load rather than relying on generic defaults.

How can I reduce Envoy sidecar memory in a service mesh?

Reducing the mesh-wide route/cluster configuration pushed to each sidecar (e.g. via Istio Sidecar resource scoping to relevant namespaces) is the most effective lever, since every sidecar otherwise receives the full mesh's route table by default.

Does connection pooling reduce memory usage?

Yes — reusing upstream connections instead of opening a new one per request reduces the total concurrent connection count Envoy must track, directly lowering connection-related memory overhead.

What's a typical base memory footprint for Envoy?

A minimal Envoy sidecar with default stats and admin interface typically starts around 30-80MB before any dynamic connection or route load is applied, though this varies by build and enabled filters.