Service meshes solve a real problem. In a microservices environment, you want mutual TLS between services, traffic management, retries, circuit breaking, and observability without writing that code in every service. The service mesh handles it at the infrastructure layer.
The dominant implementation pattern has been sidecars: a proxy container runs alongside every application container, intercepts all network traffic, and applies the mesh policies. Envoy is the most common proxy. Istio, Linkerd, and Consul all use variants of this pattern.
The sidecar model works, but it has real costs. Every pod gets an extra container. That container uses CPU and memory. It adds latency to every request. It requires operational expertise to configure and troubleshoot. And the sidecar lifecycle is tied to the pod lifecycle, which creates edge cases during startup and shutdown.
Microsoft's ambient mesh approach, now advancing through the Istio project as ztunnel and waypoint proxies, moves mesh functionality out of the sidecar and into per-node and per-namespace infrastructure. The application pod runs without a proxy sidecar. The node-level ztunnel handles L4 traffic (mTLS, traffic routing). Optional waypoint proxies handle L7 policies (retries, circuit breaking, header manipulation) at the namespace level.
What You Get
Less overhead. Without sidecar containers, pod density increases and per-request latency decreases. For large clusters, this is measurable.
Simpler operations. You manage the mesh infrastructure separately from application deployments. Rolling out mesh changes does not require restarting application pods.
Gradual adoption. Services can opt in to L7 policies selectively while all services get baseline L4 security automatically.
What You Give Up
Visibility. The sidecar model, for all its overhead, is explicit. Every pod has a proxy. You can inspect it, configure it, and understand what it is doing. When the proxy is abstracted into node-level infrastructure, the debugging surface changes. Problems that used to be visible in the sidecar proxy logs are now in the ztunnel logs, which require understanding the node-level architecture to interpret.
This is the trade-off that ambient mesh makes: less overhead in exchange for more abstraction. For teams that find the sidecar model operationally burdensome, it is a good trade. For teams that rely on per-pod proxy visibility for debugging, it changes the mental model.
Where This Is Heading
Ambient mesh is production-ready in Istio 1.21 and is the direction Istio is moving for new deployments. Microsoft's contributions to the project reflect their investment in making Kubernetes networking more approachable for enterprise customers who find the current mesh options too complex to operate.
If you are evaluating service mesh options for a new cluster, ambient mode is worth serious consideration. If you have an existing Istio installation with sidecar injection, the migration path exists but requires careful planning.