Envoy Proxy Capacity Calculator

Estimate Envoy proxy memory usage from open connections and configured routes, given per-connection and per-route memory overhead.

Inputs

Concurrent Connectionsconnections

Number of concurrent open connections the Envoy proxy handles.

Memory per ConnectionKB

Average memory overhead per open connection (buffers, TLS session state).

Configured Routesroutes

Number of route entries in the proxy's route table (RDS).

Memory per RouteKB

Average memory overhead per configured route entry.

Base Memory FootprintMB

Envoy's own baseline memory usage before connections/routes (binary, stats, admin interface).

Total Envoy Memory

249.2MB

Total Envoy Memory

0.243GiB

Connection Memory Share

78.4%

Route Table Memory Share

1.6%

Step by step

Connection memory: connections × per-conn memory
5,000 × 40KB
= 200,000 KB
Route memory: routes × per-route memory
500 × 8KB
= 4,000 KB
Total memory: base + connections + routes
50MB + 199.2MB
= 249.2 MB

How it works

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)

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.

You might also need

Istio Sidecar Memory Calculator Service Mesh Overhead Calculator Ingress Controller Capacity Calculator