Istio Sidecar Memory Calculator

Estimate memory overhead added by an Istio Envoy sidecar per pod.

About Istio Sidecar Memory Calculator

Every pod in an Istio mesh runs an Envoy sidecar proxy alongside the application container, and its memory usage grows with the number of open connections, configured routes/clusters, and request throughput it must buffer and process. Formula: memory_MB = base(50) + 0.5 × connections + 2 × routes + 0.1 × RPS, applied per pod and then multiplied across the mesh. This overhead is in addition to the application container's own memory and must be budgeted into node capacity planning.

Formulas

Per-sidecar memory

memory_MB = 50 + 0.5 × connections + 2 × routes + 0.1 × RPS

connections: Open connections per pod
routes: Configured route/cluster count
RPS: Requests per second through the sidecar

Total mesh memory

total_mesh_MB = memory_per_sidecar × pod_count

memory_per_sidecar: Estimated memory per sidecar (MB)
pod_count: Number of pods in the mesh

Worked example

With the default values below, Istio Sidecar Memory Calculator returns Memory per Sidecar of 220.0. Change any input above and every figure here is recalculated in your browser.

Inputs used

Connections per Podaccepts 0–1,000,000 connections: 200 connections
Request Rateaccepts 0–1,000,000 req/s: 100 req/s
Route Countaccepts 0–100,000 routes: 30 routes
Pod Countaccepts 1–1,000,000 pods: 50 pods

Results

Memory per Sidecar: 220.0 MB
Total Mesh Memory: 10.74 GiB
Total Mesh Memory: 11,000 MB
Connection Overhead: 100.0 MB
Route Overhead: 60.0 MB

Step by step

1Connection overhead= 100.0MB
2Route overhead= 60.0MB
3Throughput overhead= 10.0MB
4Per-sidecar memory: base + overheads= 220.0MB
5Total mesh memory= 11000MB (10.74GiB)

Assumptions and limits

The result is derived only from the 4 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 2 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 route count matter so much for sidecar memory?

Each route/cluster the sidecar knows about (driven by the number of services in the mesh and how Istio's Sidecar/DestinationRule scoping is configured) adds to the xDS configuration Envoy holds in memory — large meshes without scoped sidecars can see this dominate memory usage.

How can I reduce sidecar memory usage?

Use Istio's Sidecar resource to scope each pod's visible service registry to only what it needs, reducing route/cluster count; also tune concurrency and connection pool settings, and consider ambient mesh mode which removes per-pod sidecars entirely.

Are these coefficients exact?

No — they're reasonable planning heuristics based on commonly observed Envoy behavior. Validate against your own `istio-proxy` container's actual memory usage (via `kubectl top` or Prometheus) and recalibrate the constants for your workload.

Does this include the Istio control plane (istiod)?

No — this estimates only the per-pod data-plane sidecar memory. istiod's own memory scales with mesh size (services, endpoints, and config objects) and should be sized separately.