A service mesh such as Istio or Linkerd adds cost mainly through its data plane: a sidecar proxy injected next to every application container consumes its own CPU and memory, and across thousands of pods that overhead aggregates into extra nodes. Typical sidecar overhead runs from a low single digit to tens of percent of a pod's resource use depending on traffic, mutual TLS, and telemetry settings. The control plane adds a smaller fixed cost. The mesh pays for itself only when the security, observability, and traffic control it provides would otherwise be built and run at greater cost, so the decision is a value comparison, not a feature checklist.
Here is where the overhead comes from, how to measure it on your own estate, and how to cut it without losing what the mesh is for.
Where does service mesh overhead actually come from?
Most of the cost sits in the data plane. Every meshed pod runs a sidecar proxy that intercepts traffic, terminates and originates mutual TLS, and emits telemetry. Each of those jobs costs CPU and memory, and each request now makes two extra hops through proxies. The control plane that configures and certificates the mesh adds a smaller, more fixed cost. Telemetry is the quiet multiplier: full request level metrics and tracing can cost more than the proxying itself, and they flow straight into your logging and observability bill, which on Kubernetes is already one of the largest line items.
How much does a sidecar really add?
The honest answer is that it depends on your traffic shape, and you should measure rather than guess. As an indicative range, a lightly loaded sidecar might add only a fraction of a CPU core and tens of megabytes of memory, while a proxy in a high throughput path with mutual TLS and rich telemetry can add a large fraction of a core and hundreds of megabytes. Multiply that by pod count and you get the real number. A useful exercise: take your busiest namespace, read the proxy container resource use from the same Cost and Usage Report or billing export that carries the rest of the cluster, and express it as a percent of application use. That percent, applied across the fleet, is your mesh tax.
How do you cut mesh overhead without losing the mesh?
- Mesh only what needs it. Inject sidecars per namespace, not cluster wide. Batch jobs and internal tooling rarely need mutual TLS or traffic shaping.
- Tune telemetry. Sample traces and trim request level metrics to what you actually query. This is usually the single biggest saving and it lands in your observability bill as well.
- Right size the proxy. Set proxy resource requests and limits deliberately rather than accepting defaults, so the scheduler is not reserving headroom you never use.
- Consider a lighter data plane. Sidecarless or ambient mesh modes move shared work out of per pod proxies and can cut the per pod tax materially. Weigh the maturity tradeoff against the saving.
A worked example
A Fortune 500 retailer ran a single mesh across every namespace with full tracing enabled, and the proxy fleet had quietly grown into a noticeable share of cluster compute plus an outsized telemetry bill. We scoped the mesh to the services that genuinely needed mutual TLS and traffic policy, sampled tracing instead of capturing every request, and right sized the proxy requests that had been left at default. Node count fell and the observability line dropped alongside it, with no loss of the security posture the mesh was adopted for. The change was one lever in a Kubernetes program that left the estate materially lighter. Figures are verified against billing data and anonymised.
Frequently asked questions
Does a service mesh increase cloud cost?
How much overhead does an Istio or Linkerd sidecar add?
Is a service mesh worth the cost?
Size your mesh overhead before it sizes your bill
We help platform teams measure what a service mesh costs on AWS, Azure, GCP, and OCI managed Kubernetes, and cut the overhead without losing the controls the mesh exists for. Independent, zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or no risk Gainshare basis. Book a strategy call, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.