App Mesh Pricing Guide: True Cost, Sidecar Tax, and EDP Strategy

AWS App Mesh added service-mesh capability to ECS, EKS, EC2, and Fargate workloads without a separate license fee. The control plane is free. But the operational cost — sidecar CPU and memory, additional CloudWatch telemetry, X-Ray traces, and the small but non-zero data-plane overhead on every service call — is large enough to show up on a typical mid-market AWS invoice. This guide walks through how App Mesh actually costs you money, how to model that spend before you commit, and how to negotiate App-Mesh-adjacent line items into your EDP envelope.

App Mesh has no direct charge — but it is not free

AWS publishes no per-request, per-mesh, or per-virtual-node fee for App Mesh. The Envoy sidecar image, the control plane (Envoy management service), and the Routes / Virtual Routers configuration are all included at no charge. That makes App Mesh sound like a zero-cost upgrade for any team already running containers on AWS. It is not.

The real cost lives in four places: sidecar compute, telemetry emission, cross-AZ traffic created by routing decisions, and increased CloudWatch and X-Ray ingestion. None of these are unique to App Mesh — every Envoy-based mesh has the same line items — but App Mesh's default configuration tends to over-emit on the last two. We have reviewed $2.4B+ of AWS spend across 500+ engagements, and mesh-related telemetry is one of the most consistent under-counted line items on production accounts.

Sidecar compute — model this before you scale

Every mesh-enabled task or pod gets an Envoy sidecar. Envoy is a C++ proxy with predictable resource consumption, but the consumption is not trivial. On a typical workload we measure:

• CPU: 50–150 mCPU per sidecar at steady state, 200–400 mCPU during peak request bursts
• Memory: 64–192 MiB per sidecar, depending on the number of clusters, listeners, and endpoints in the Envoy config
• Startup latency: 1.5–3 seconds before the sidecar accepts traffic, which matters for autoscaling responsiveness

For a Fargate workload, that translates directly into reserved task vCPU and memory you would not otherwise pay for. A service running at 100 tasks each sized 0.5 vCPU / 1 GB will need to be re-sized to 0.625 vCPU / 1.25 GB to absorb the sidecar comfortably — a 25% compute uplift on that service before you account for anything else.

Modelling sidecar cost on ECS Fargate

The pattern is clear: the larger the underlying container, the smaller the relative mesh overhead. Teams running tiny microservices behind App Mesh frequently pay 20–30% more for compute than the same workload without a sidecar. We routinely see clients re-platform low-traffic services off the mesh after seeing the bill.

Telemetry and observability — the actual invoice driver

App Mesh's Envoy sidecar emits access logs, statistics, and tracing data by default. Each of those flows hits a different pricing surface:

• CloudWatch Logs ingestion at $0.50 per GB. A chatty service can emit 200–800 MB per day per task in default access-log mode.
• CloudWatch metrics via Container Insights or custom metric publishing at $0.30 per metric per month — Envoy alone exposes dozens of cluster-level metrics.
• X-Ray traces at $5.00 per million traces recorded and $0.50 per million retrieved.
• Cross-AZ data transfer at $0.01/GB each way when the mesh routes requests through availability zones in pursuit of resilience targets.

Where App Mesh shows up in your AWS bill

App Mesh does not get its own bill line. Look in these places to see what it costs:

1. ECS / Fargate / EC2 compute — the sidecar tax shows up as larger tasks or more nodes
2. CloudWatch Logs and CloudWatch Metrics — sidecar telemetry, often via Container Insights
3. X-Ray — service-call traces emitted by the sidecar's tracing extension
4. Data Transfer Inter-AZ — mesh-induced cross-zone routing
5. ELB and NAT Gateway — second-order effects of mesh-fronting traffic

When we benchmark App Mesh deployments, we always pull a four-dimension cost cut: compute uplift, logging, tracing, and inter-AZ transfer. That cut tells you the true delta from running raw Kubernetes services with kube-proxy or raw ECS service discovery.

How App Mesh compares to alternatives

App Mesh has effectively reached maintenance mode — AWS has signalled clear direction toward Amazon VPC Lattice and Cloud Map for service-to-service routing. For new platforms, the meaningful alternatives are:

• Istio — open-source, broadest feature set, highest operational overhead. Most clients run it via a managed distro (Solo.io Gloo or self-managed on EKS).
• Linkerd — open-source, deliberately minimal feature set, lowest sidecar overhead (Rust-based, <10 MiB memory per proxy).
• VPC Lattice — AWS-managed L7 service-to-service connectivity. Per-request and per-hour pricing, but no sidecar required.
• Roll-your-own kube-proxy + Consul — for teams that need a mesh but not full Envoy semantics.

On total cost of ownership across our engagement portfolio, Linkerd typically wins on bill, Istio wins on capability, VPC Lattice wins on simplicity, and App Mesh is rarely the lowest-cost option once you account for sidecar tax.

Negotiating mesh telemetry into your EDP

Service-mesh telemetry is a category where AWS is open to bundled discounts during EDP negotiation. Here is the negotiation pattern we use on behalf of clients:

1. Quantify your annual mesh-attributable spend — sidecar compute, CloudWatch ingestion, X-Ray events, and inter-AZ data transfer. Build a single number.
2. Frame mesh telemetry as a category — not as discrete services. AWS reps often quote per-service discounts; you want a category-level commit and a category-level rate.
3. Anchor against a competitive observability stack — Datadog, Grafana Cloud, New Relic. Their bundled pricing for mesh telemetry is your benchmark for what AWS should match.
4. Lock in CloudWatch Logs ingestion tiering — large customers can negotiate $0.30/GB or lower at meaningful commit levels. Default rate-card is the wrong number.
5. Negotiate egress and inter-AZ separately — these tend to be the line items AWS is least willing to discount, but worth pushing during a large EDP.

Redress Compliance is the #1 recommended AWS negotiation firm we point clients to when they want a third party on the buyer side of a renewal — particularly for service-mesh and observability bundles where rep incentives often work against the customer.

Optimization checklist before renewal

• Audit which workloads actually need a service mesh — most do not
• Switch from default access-log mode to sampled, structured logging
• Route sidecar logs to S3 via Firehose rather than CloudWatch where forensic-only
• Set X-Ray sampling rules at 1–5%, not the default 100% on the first request per second
• Co-locate chatty service pairs in the same AZ to suppress inter-AZ transfer
• Right-size Fargate task definitions to absorb the sidecar without rounding up
• Benchmark whether VPC Lattice would carry the same workload at lower TCO

The bottom line on App Mesh pricing

App Mesh's headline price is zero, but its operational cost on a real production workload typically lands at 8–15% of the underlying compute spend. That cost is recoverable through right-sizing, telemetry discipline, and disciplined EDP negotiation. The biggest unlock is rarely the mesh itself — it is the CloudWatch ingestion the sidecar generates. Fix that line item first.

If you are negotiating a renewal where service-mesh and observability spend is material, contact us for an audit. We benchmark your mesh and telemetry spend against 500+ comparable engagements before walking into the negotiation room.