The Sidecar Tax: Ambient Mesh vs eBPF vs Sidecars

Q: What is the sidecar tax in a service mesh?

The sidecar tax is the total cost of attaching a full Layer 7 proxy to every application pod. The visible part is CPU and memory: Istio's published figures put one Envoy sidecar at about 0.20 vCPU and 60 MB at 1,000 requests per second. The larger, invisible part is structural. Each sidecar is provisioned with requests and limits for that pod's worst hour, so a fleet of 2,000 pods reserves 2,000 worst cases regardless of load; every L7 request is parsed twice, once by the source sidecar and once by the destination; mesh upgrades require restarting every application pod; and the application team owns a proxy it did not choose. Services that only need encryption and identity — usually the majority — pay the full L7 price for an L4 need. Sidecarless architectures attack that mismatch, not the per-request cost of Envoy itself.

Q: How does Istio ambient mode work without sidecars?

Ambient mode splits the proxy's two jobs. Layer 4 — mutual TLS, SPIFFE-based workload identity, TCP telemetry and L4 authorisation — is handled by ztunnel, a purpose-built Rust proxy that runs once per node as a DaemonSet and tunnels pod-to-pod traffic over HBONE, an HTTP-based overlay. Layer 7 — HTTP routing, retries, header-based authorisation, rich observability and WebAssembly extensions — is handled by an optional waypoint, a standard Envoy deployment that a namespace or service opts into via a label and a Gateway API resource. Nothing is injected into the application pod, workloads join the mesh without a restart, and a service with fifty replicas can share one autoscaled waypoint instead of running fifty sidecars. Ambient reached General Availability in Istio 1.24 in November 2024 and is the default sidecarless path in current releases.

Q: Is Istio ambient mode cheaper than sidecars?

For Layer 4 it is dramatically cheaper; for Layer 7 it is roughly the same per request, and the saving comes from running fewer proxies. Istio's own numbers at 1,000 requests per second are about 0.06 vCPU and 12 MB for a ztunnel versus 0.20 vCPU and 60 MB for a sidecar, and a waypoint at about 0.25 vCPU and 60 MB — the same Envoy doing the same parsing. Savings therefore scale with the share of services that need only L4: Istio's GA announcement cites adopters reporting compute savings that can exceed 90 percent in L4-heavy estates and one operator removing about 45 percent of running containers. In an estate where nearly every service uses L7 policy the waypoint fleet grows toward the sidecar fleet's processing cost, and the remaining savings are the single parse, the removal of worst-case padding per replica, and decoupled upgrades.

Q: What does ambient mode not support compared with sidecar mode?

Istio's sidecar-or-ambient comparison lists the gaps explicitly. The EnvoyFilter API is not supported in ambient; custom filters must be re-expressed as WebAssembly or Lua on a waypoint. Sidecar-to-waypoint interoperability, multi-network support and virtual machine workloads are listed as not yet implemented for ambient; multi-cluster support for ambient reached Beta in Istio 1.29 after an alpha in 1.27, while sidecar mode remains stable including multi-cluster. The security model also differs: in sidecar mode each workload holds its own keys, whereas in ambient a node's ztunnel holds the keys for every workload on that node, so a compromised node agent has a wider blast radius than a compromised sidecar. Workloads with any of these dependencies should remain on sidecars until the feature reaches GA.

Q: How is Cilium's eBPF service mesh different from Istio ambient?

Both remove the per-pod sidecar, but they draw the L4/L7 line in different places. Cilium runs Layer 3 and 4 policy, load balancing and observability as eBPF programs inside the Linux kernel with no user-space proxy at all, and hands only application-layer protocols — HTTP, gRPC, DNS — to a per-node Envoy when L7 policy is configured. Istio ambient keeps a user-space L4 proxy (ztunnel) per node and adds per-service waypoints for L7. The practical difference in 2026 is maturity of identity: Istio ambient's mTLS and SPIFFE identity are GA, whereas Cilium's mutual authentication feature is documented as Beta in the current 1.20 release. Teams already running Cilium as their CNI often use it for network policy and observability and run Istio ambient on top for mesh identity and L7; the two are documented as compatible.

Q: Did Kubernetes native sidecar containers fix the sidecar tax?

They fixed the operational half of it and none of the economic half. Native sidecar containers — init containers with a restart policy of Always that start before the application and stop after it — have been Stable since Kubernetes 1.33. They eliminate the classic startup race where the application starts before its proxy is ready, the Jobs that never complete because the sidecar keeps running, and shutdown ordering problems. If those were the reasons a team wanted to go sidecarless, upgrading Kubernetes and enabling native sidecar injection is the cheaper fix. What native sidecars do not change is the per-replica worst-case provisioning, the double L7 parse, upgrades that require application restarts, or the application team's ownership of the proxy — and those are the reasons ambient mode exists.

Q: How should a team migrate from sidecars to ambient safely?

Inventory first, then migrate namespace by namespace with a revert path. The inventory records, per service, which L7 features are actually used, any EnvoyFilter dependencies, any VM or cross-cluster traffic paths, and any per-workload key isolation requirement from a regulator or tenant contract. Services with blockers stay on sidecars. Single-cluster, Kubernetes-only namespaces with no L7 needs move first to ambient L4, with sidecar injection kept as the documented revert; services that need L7 then attach waypoints one at a time. Because sidecar-to-waypoint interoperability is not yet supported, mixed-mode traffic paths between a migrated namespace and an unmigrated one must be mapped before each cutover. Run health gates at each step, confirm that HTTP golden signals still exist for services that went L4-only, and treat the dual-running period as a cost in the business case.

Q: When should a team stay on sidecars in 2026?

When the workload depends on something ambient does not yet provide, or when the security model demands it. Concretely: services using EnvoyFilter for custom Envoy behaviour that cannot be expressed as Wasm or Lua; workloads on virtual machines; multi-network meshes and multi-cluster deployments where the Beta status of ambient multi-cluster is unacceptable; and workloads where a regulator, a tenant contract or the organisation's threat model requires per-workload cryptographic keys rather than node-scoped keys held by a shared agent. Linkerd's continued commitment to a lightweight Rust sidecar is a reasonable choice for teams in that last category. Staying on sidecars is not a failure; it is the correct answer when the inventory says so, and native sidecar containers make it a better answer than it was two years ago.

Satyam Kumar

ブログに戻る

microservices-patterns

The Sidecar Tax: Ambient Mesh, the eBPF Data Plane, and What a Sidecarless Migration Actually Buys (2026)

By Satyam KumarSeptember 22, 202616 min read

service mesh istio ambient mode sidecarless service mesh ztunnel waypoint proxy cilium service mesh ebpf data plane envoy proxy sidecar pattern kubernetes networking mtls kubernetes linkerd platform engineering kubernetes cost optimization spiffe workload identity native sidecar containers

The Sidecar Tax: Ambient Mesh, the eBPF Data Plane, and What a Sidecarless Migration Actually Buys (2026)

Frequently Asked Questions

この記事を共有する

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI＆クラウドアーキテクト。数百万人にスケールするシステム構築を支援。

LinkedIn GitHub

The Sidecar Tax: Ambient Mesh, the eBPF Data Plane, and What a Sidecarless Migration Actually Buys (2026)

Frequently Asked Questions

この記事を共有する

Comments

Leave a comment