Service mesh adoption has always had a tension at its core: the features it provides (mTLS, traffic management, observability) are genuinely valuable, but the operational cost of running a sidecar proxy alongside every workload pod has been a persistent obstacle. Memory overhead, injection complexity, upgrade coordination, and debug difficulty — these are real costs that have kept many teams from adopting Istio at scale.
Istio's ambient mode addresses this at the architectural level. Instead of injecting an Envoy sidecar into each pod, ambient mode uses two shared components: a per-node Layer 4 proxy (ztunnel) and an optional per-namespace Layer 7 waypoint proxy. The practical result is service mesh capability at a fraction of the resource cost.
At KubeCon EU 2026 in Amsterdam, the Istio project announced three new features that push ambient mode further into production territory: Ambient Multicluster Beta, Gateway API Inference Extension Beta, and experimental Agentgateway support. Taken together, these signal that ambient mode is no longer an experimental track — it's becoming the recommended deployment model.
How Ambient Mode Works
Understanding the architecture helps you reason about where it fits and where it doesn't.
ztunnel (Layer 4): Each Kubernetes node runs a single ztunnel instance. This handles identity verification, mTLS encryption, and basic traffic routing for all workloads on the node. Because it runs at the node level rather than the pod level, you get zero-trust networking for all pod-to-pod traffic without any per-pod injection.
Waypoint proxy (Layer 7): For services that need HTTP traffic management — routing rules, retries, header manipulation, advanced authorization policies — you deploy a waypoint proxy at the namespace level. This is still Envoy under the hood, but it's shared across all workloads in the namespace rather than duplicated per pod.
What this means for resource consumption: In sidecar mode, each pod carries a full Envoy instance. Across a cluster with hundreds of services and multiple replicas each, this adds up to significant steady-state memory consumption — often gigabytes of overhead across the cluster. Ambient mode reduces this dramatically. Observed reductions of over 90% in memory and over 50% in CPU compared to sidecar mode have been reported in production evaluations.
KubeCon EU 2026 Announcements
The three features announced at KubeCon EU 2026 each address a different gap in the ambient mode story.
Ambient Multicluster Beta: Previously, ambient mode had limited support for multi-cluster scenarios — a significant gap for organizations running services across multiple Kubernetes clusters (a common pattern for high availability or geographic distribution). The multicluster beta brings ambient-mode traffic management and mTLS to cross-cluster traffic, using the same ztunnel + waypoint model.
Gateway API Inference Extension Beta: This is particularly relevant for teams running AI/ML workloads. As GPU-backed inference services become more common in Kubernetes clusters, traffic routing for inference endpoints has specific requirements: model-aware load balancing, request priority, and connection pooling optimized for long-running inference requests. The inference extension adds these capabilities to Gateway API resources, making Istio ambient mode a more capable platform for AI serving infrastructure.
Agentgateway (experimental): Agentgateway extends ambient mode's traffic management to AI agent communication — allowing Istio to route, authenticate, and observe traffic between AI agents in a mesh. This is early-stage, but it reflects where Kubernetes networking is heading as agentic AI workloads move into production.
Migration Path from Sidecar Mode
If you're currently running Istio with sidecars, the migration to ambient mode is not a lift-and-shift. The two modes can coexist in a cluster during transition, which makes incremental migration possible.
A practical migration sequence:
- Install the ambient components: Deploy ztunnel as a DaemonSet and the istiod version that supports ambient mode.
- Label namespaces for ambient: Add
istio.io/dataplane-mode: ambientto namespaces where you want ambient mode. Existing sidecar-injected pods continue to work. - Deploy waypoint proxies selectively: For services that require L7 policies, deploy a waypoint proxy in the namespace. For L4-only requirements (mTLS, basic authorization), ztunnel alone is sufficient.
- Remove sidecar injection: Once all workloads in a namespace are covered by ambient mode, disable sidecar injection for that namespace and restart pods to remove existing sidecars.
Red Hat's inclusion of ambient mode as GA in OpenShift Service Mesh 3.2 is a useful signal here. Enterprise Kubernetes distributions shipping a feature as GA typically means the migration tooling and operational playbooks are mature enough for production use.
Practical Considerations
A few things to verify before adopting ambient mode:
Istio version: Ambient multicluster and the latest features require Istio 1.22 or later. Check your current version and plan the upgrade path if needed.
CNI compatibility: Ambient mode's ztunnel component uses eBPF-based traffic interception, which has compatibility requirements with your CNI plugin. Calico, Cilium, and Flannel are all supported, but verify your specific version combination against Istio's compatibility matrix.
L7 policy inventory: Audit which of your current Istio configurations require Layer 7 processing (VirtualService, HTTP routing rules, header-based auth). These require waypoint proxy deployment in ambient mode. L4 policies (PeerAuthentication for mTLS, basic AuthorizationPolicy) work with ztunnel alone.
Observability continuity: Your existing Kiali, Jaeger, or Prometheus integrations should continue working in ambient mode — the telemetry model is compatible. However, verify your dashboard queries aren't relying on sidecar-specific metrics labels that might differ.
Webhani's Perspective
Service mesh has been a recurring architectural conversation with our clients — often deferred because the operational cost felt high relative to the benefit at their current scale. Ambient mode changes that calculation meaningfully.
For new Kubernetes deployments, ambient mode is now our default recommendation for any cluster that needs mTLS between services. The resource savings are significant, the operational model is simpler, and the feature set covers most production requirements.
For existing sidecar-based deployments, the migration is worth planning for in your next infrastructure cycle. The incremental namespace-by-namespace migration path makes it possible to do without a big-bang cutover.
The KubeCon EU 2026 announcements — particularly the inference extension — also signal that Istio ambient is being positioned as the standard networking layer for AI/ML workloads in Kubernetes. If your infrastructure roadmap includes expanding GPU-based inference services, getting familiar with ambient mode now will pay off.