Estimate CPU overhead added by an Istio Envoy sidecar under request load.
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.
Per-sidecar CPU
cpu_millicores = 100 + 0.5 × RPS + mtls_overhead + logging_overhead
Total mesh CPU
total_mesh_cpu_cores = (cpu_per_sidecar × pod_count) / 1000
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.
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.
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.
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.