Istio Sidecar Memory Calculator
Estimate the memory footprint of the Envoy sidecar proxy Istio injects into each pod, and the total across your mesh.
Inputs
Average number of open upstream/downstream connections the sidecar tracks per pod.
Requests per second flowing through the sidecar.
Number of distinct routes/clusters configured in the sidecar's Envoy config.
Number of pods in the mesh running this sidecar profile.
Memory per Sidecar
220.0MB
Total Mesh Memory
10.74GiB
Total Mesh Memory
11,000MB
Connection Overhead
100.0MB
Route Overhead
60.0MB
Step by step
Connection overhead
0.5MB × 200
= 100.0MB
Route overhead
2MB × 30
= 60.0MB
Throughput overhead
0.1MB × 100
= 10.0MB
Per-sidecar memory: base + overheads
50 + 100.0 + 60.0 + 10.0
= 220.0MB
Total mesh memory
220.0MB × 50 pods
= 11000MB (10.74GiB)
How it works
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
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.
You might also need
- Istio Sidecar CPU CalculatorCommonly used together
- Envoy Proxy Capacity CalculatorCommonly used together
- API Gateway Throughput CalculatorCommonly used together
- Pod Resource CalculatorCommonly used together
- Docker Container Memory CalculatorCommonly used together
- Node Capacity CalculatorCommonly used together