Skip to content
Calcrivo

Istio Sidecar CPU Calculator

Estimate the CPU cost of the Envoy sidecar proxy per pod based on request rate, mTLS and access logging configuration.

Inputs

req/s

Requests per second flowing through the sidecar.

Whether mutual TLS encryption/decryption is active between services.

Whether Envoy access logs are generated for each request.

pods

Number of pods running this sidecar profile, for total mesh CPU.

CPU per Sidecar

230.0millicores

Total Mesh CPU

11.50cores

Total Mesh CPU

11,500millicores

mTLS Overhead

50millicores

Access Logging Overhead

30millicores

Step by step

  1. Throughput cost

    0.5m × 100 req/s

    = 50.0m

  2. mTLS overhead

    enabled

    = 50m

  3. Access logging overhead

    enabled

    = 30m

  4. Per-sidecar CPU: base + throughput + mTLS + logging

    100 + 50.0 + 50 + 30

    = 230.0m

  5. Total mesh CPU

    230.0m × 50 pods

    = 11500m (11.50 cores)

How it works

Envoy's CPU cost per pod scales with request throughput and the features enabled on the proxy — mutual TLS adds encryption/decryption cost on every connection, and access logging adds per-request serialization overhead. Formula: cpu_millicores = base(100) + 0.5 × RPS + mtls_overhead(50 if enabled) + logging_overhead(30 if enabled), then multiplied across all mesh pods for total CPU demand.

Formulas

Per-sidecar CPU

cpu_millicores = 100 + 0.5 × RPS + mtls_overhead + logging_overhead

RPS
Requests per second through the sidecar
mtls_overhead
50 millicores if mTLS enabled, 0 otherwise
logging_overhead
30 millicores if access logging enabled, 0 otherwise

Total mesh CPU

total_mesh_cpu_cores = (cpu_per_sidecar × pod_count) / 1000

cpu_per_sidecar
CPU per sidecar in millicores
pod_count
Number of pods in the mesh

Frequently Asked Questions

Is mTLS overhead worth it?

For most services yes — the security benefit of encrypted, authenticated service-to-service traffic outweighs a modest, roughly fixed CPU cost per sidecar, especially since Envoy uses efficient TLS session reuse to amortize the cost across requests.

Can I disable access logging to save CPU?

You can, but you lose per-request observability at the mesh layer. A common middle ground is sampling access logs (e.g. only log errors or a percentage of traffic) rather than disabling entirely.

How does this compare to the application container's own CPU usage?

Sidecar CPU is additive overhead on top of your application — for high-RPS, latency-sensitive services this overhead can be a meaningful fraction of total pod CPU, which is one reason ambient mesh (sidecar-less) modes have gained interest.

Should I size CPU requests/limits differently for the sidecar vs. the app container?

Yes — Istio lets you set proxy resource requests/limits independently via annotations or the global mesh config, and this estimate should feed directly into the `istio-proxy` container's own resource spec.

You might also need

Related Calculators

Istio Sidecar Memory CalculatorPod Resource CalculatorAPI Gateway Throughput Calculator