Welcome to my blog post — “Beyond Sidecar: A Deep Dive into Istio Ambient Mode Traffic Mechanism and Cost Efficiency.”

This post is based on my talk at KCD Beijing and focuses on Istio’s newly introduced data plane model — Ambient Mode. Its core idea is to remove the Sidecar proxy to reduce resource overhead and operational complexity.

In this article, I’ll explain Ambient Mode’s background, core components, traffic routing mechanisms, and a comparison with the existing Sidecar model. The goal is to help you evaluate this new feature and confidently adopt it.

Click here to view the slides.

Why Care About Ambient Mode?

Let’s start with a question: why should we care about—or even consider adopting—this new mode? Sidecar proxies have been working well in service meshes for years, so why remove them now?

To answer that, let’s look at some of the challenges service meshes currently face.

Challenges with Service Mesh

• Resource overhead and operational complexity introduced by sidecar proxies
• Upgrading or restarting Envoy often requires restarting all Pods
• Growing demand for high performance and lower costs

Thought exercise: Is there a way to retain the core capabilities of a service mesh—security, observability, traffic control—while reducing the per-Pod intrusion and extra resource consumption?

Common Service Mesh Deployment Models

The architecture of service meshes has long been exploring different proxy deployment strategies, such as:

• Sidecar: Runs an Envoy proxy inside each Pod
• Ambient: Moves the proxy out of Pods to the node level (which this post focuses on)
• Cilium Mesh: Uses eBPF in the kernel space for L4, combined with Envoy for L7 capabilities
• gRPC: Embeds mesh functionality directly into application SDKs

Each of these models has trade-offs in terms of functionality, security, performance, and operational complexity. Istio Ambient Mode is a new attempt to address the Sidecar model’s overhead and operational burdens.

The Birth of Ambient Mode

• A next-generation Istio architecture that removes the Sidecar, using ztunnel + Waypoint Proxy to simplify the data plane
• Saves resources and reduces operational complexity
• Still supports mTLS and policy enforcement, with Waypoint Proxy optionally providing L7 capabilities

The following table provides a quick comparison of some common service mesh deployment models:

Core Concepts of Istio Ambient Mode

Let’s now move into the second part of our discussion, where we’ll explore the core components of Ambient Mode, including ztunnel, Waypoint Proxy, and the role of Istio CNI.

Key Components of Ambient Mode

1. ztunnel (L4)

   • Runs as a node-level proxy
   • Responsible for transparent traffic interception and mTLS encryption
   • Handles most traffic that only requires L4 forwarding

2. Waypoint Proxy (L7)

   • Optionally deployed (configurable by namespace, service, or pod granularity)
   • Handles advanced functionality like HTTP/gRPC authentication, routing, and observability

3. Istio CNI

   • Replaces the istio-init container and handles traffic redirection
   • Supports both Sidecar and Ambient modes
   • Enables traffic redirection in unprivileged mode for enhanced security

Overview of Ambient Mode Architecture

In Ambient Mode, the Istio data plane is split into two layers:

1. Security Layer (ztunnel): A lightweight L4 proxy is deployed on each node
2. Optional L7 Layer (Waypoint Proxy): Deployed only when HTTP/gRPC proxying is needed

The control plane is still managed by Istiod, which distributes configurations and certificates to both ztunnel and Waypoint proxies.

Deployment Strategies for Waypoint Proxy

• Namespace-level (default): Applies to all workloads in the namespace
• Service-level: For services that require L7 processing only
• Pod-level: Offers fine-grained control
• Cross-namespace: Enables sharing via Gateway resources

Istio CNI

• Traffic Interception: Replaces the istio-init container, simplifying the installation process
• Dual-mode Support: Compatible with both Sidecar and Ambient modes
• Unprivileged Mode Compatibility: Enables traffic redirection for Pods running without elevated privileges
• CNI Chaining: Adds Istio CNI as an additional plugin in the existing CNI configuration
• In-Pod Traffic Redirection (Ambient Mode):
  • Uses iptables REDIRECT rules inside the Pod’s network namespace
  • Creates a local socket within the Pod to intercept and proxy traffic

The following diagram illustrates how Istio CNI integrates with Kubernetes network plugins like Calico or Cilium. Istio CNI modifies the node’s CNI configuration by appending itself to the CNI chain. After Kubernetes assigns a Pod IP, Istio CNI executes its interception logic and injects traffic redirection rules into the Pod’s network namespace.

It applies different iptables rules depending on whether the Pod runs in Sidecar or Ambient mode, forming a chained CNI workflow that complements—rather than conflicts with—the existing network policies.

How the Istio CNI Plugin Works

The following diagram illustrates in detail what the Istio CNI does when a Pod starts:

1. It enters the Pod’s network namespace and creates a set of iptables rules to redirect traffic to the socket where ztunnel is listening.
2. There’s no longer a need to inject an init container into each Pod, nor are elevated privileges required. This results in a cleaner and more secure deployment.
3. ztunnel creates a socket inside each Pod’s network namespace, and does so for every Pod on the node.

Traffic Flow and Core Mechanisms

After understanding the components, let’s dive into the heart of Ambient Mode: the traffic path. How do zTunnel and Waypoint intercept and forward traffic? We’ll examine this through the lens of transparent traffic interception and the HBONE protocol.

Transparent Traffic Interception

In Ambient Mode, Istio CNI injects iptables rules into each Pod’s network namespace to transparently intercept outbound traffic and redirect it to the local ztunnel process on the node. zTunnel then decides whether to forward traffic at L4 or send it to the Waypoint Proxy for L7 processing.

As shown in the diagram, when Kubelet starts a Pod on the node, this event is observed by the Istio CNI Agent. The agent enters the Pod’s network namespace, sets up iptables rules to redirect traffic to a local socket, and passes the Pod’s file descriptor (FD) to zTunnel. Once zTunnel receives the FD, it creates a socket within the Pod’s namespace.

When the Pod sends traffic, it normally would go directly to the destination address. But because of the iptables rules, the traffic is intercepted and redirected to the local zTunnel process. zTunnel then determines whether the traffic needs L7 processing via Waypoint:

• If not, it encrypts and forwards the traffic at L4 directly to the destination Pod.
• If L7 functionality is needed (e.g., for authentication), it tunnels the traffic to the Waypoint Proxy.

Packet Lifecycle Overview

1. Pod → ztunnel: Traffic from the Pod is intercepted by the CNI and redirected to the local ztunnel on the same node.
2. ztunnel: Resolves the destination address and applies mTLS encryption.
3. (If L7 policy is needed) ztunnel → Waypoint Proxy: Handles HTTP authentication, routing, etc.
4. Waypoint Proxy: After L7 processing, traffic is sent back to ztunnel.
5. ztunnel: Decapsulates or forwards the traffic to the destination node’s ztunnel.
6. To the target Pod: The destination ztunnel finally delivers the traffic to the target Pod.

The HBONE Protocol

In Ambient Mode, ztunnel and Waypoint Proxy use the HBONE (HTTP/2 + CONNECT) protocol to establish a secure tunnel. This enables mTLS encryption and multiplexing, reducing connection overhead and simplifying proxy forwarding logic.

Below is a simplified example of an HBONE CONNECT request, which uses headers like x-envoy-original-dst-host and x-istio-auth-userinfo to pass routing and authentication context:

:method: CONNECT
:scheme: https
:authority: Pod_B_IP:9080
:path: /api/v1/users?id=123
x-envoy-original-dst-host: Pod_B_IP:9080
x-forwarded-proto: hbone
x-istio-attributes: ...
...

In this example, assume ztunnel A is sending traffic to node B. The outer TCP connection is actually from ztunnel_A_IP:52368 to Node_B_IP:15008, where port 15008 is the HBONE listener on the destination node.

At the HTTP/2 layer, a CONNECT request is initiated. The :authority field shows Pod_B_IP:9080, indicating the actual destination port of Pod B. The x-envoy-original-dst-host header carries the same target.

You’ll also notice custom headers like x-forwarded-proto and x-istio-attributes, which carry routing context and security metadata for the receiving ztunnel or downstream proxy.

Think of this as an “inner tunnel” built on top of HTTP/2 CONNECT: the application-layer request (e.g., /api/v1/users?id=123) is encapsulated inside, then unpacked by ztunnel B and forwarded to Pod B.

This entire process is transparent to the application. But by inspecting the CONNECT headers, we gain insight into how Ambient Mode performs traffic routing and identity verification at the HTTP/2 layer. This flexibility makes HBONE a more adaptable alternative to traditional Sidecar-to-Sidecar communication, especially for implementing mTLS and L7 extensions.

Encrypted Traffic on the Same Node

If the source Pod and destination Pod happen to be on the same node, traffic goes through the ztunnel’s L4 encryption path.

As shown here, ztunnel is deployed as a DaemonSet on each node and runs in the host network, sharing the host’s network namespace. Istio CNI intercepts the Pod’s outbound traffic and redirects it to ztunnel’s port 15001. When both the source and destination Pods are on the same node, ztunnel performs encryption and decryption internally and directly forwards the traffic to the destination Pod.

If L7 traffic handling is required (e.g., authentication), ztunnel establishes an HBONE tunnel with the Waypoint proxy, and traffic is routed through the Waypoint before reaching the destination Pod.

Encrypted Traffic Across Nodes (L4)

This is the cross-node scenario, which is also the most common case:

The source node’s ztunnel encrypts the traffic via an HBONE tunnel and sends it to the destination node’s ztunnel. The destination ztunnel decapsulates the traffic and forwards it as plaintext to the destination Pod. As long as the traffic remains purely L4 and does not require L7 features, it avoids additional hops through a Waypoint proxy—reducing the proxy chain and improving efficiency.

Encrypted Traffic Across Nodes (L7)

When L7 processing is required, the traffic passes through an additional Waypoint proxy, following this flow:

• The source ztunnel tunnels the traffic to the Waypoint proxy.
• The Waypoint handles L7 logic like authentication and routing.
• The Waypoint re-tunnels the traffic using HBONE to the destination ztunnel.
• The destination ztunnel decapsulates the traffic and delivers it to the destination Pod.

This process adds one extra proxy hop compared to L4-only traffic, but the benefit is that only traffic requiring L7 handling goes through this additional step—reducing unnecessary overhead.

Catch-All Traffic (Preventing Traffic Escape)

For traffic originating outside the Istio mesh that tries to access a Pod directly via its IP and port, Istio still needs to ensure such traffic is intercepted and managed by ztunnel to prevent it from bypassing the mesh.

If the traffic targets an application port, ztunnel checks whether the packet includes the 0x539 mark. If not, it redirects the traffic to port 15006, a plaintext port monitored by ztunnel. After processing, ztunnel adds the 0x539 mark and forwards it to the application port.

If the destination port is 15008, the packet is treated as HBONE traffic and directly handled by ztunnel.

Differences Between L4 and L7 Traffic

For most traffic that only needs encryption and forwarding at the TCP layer, Ambient Mode relies solely on ztunnel. Only when HTTP-layer policies are required does the traffic get routed through the Waypoint proxy.

Ambient Mode vs. Sidecar Mode

Now that we understand Ambient Mode, it’s important to compare it with the traditional Sidecar model to evaluate which scenarios best fit each and what gaps remain.

Limitations of Ambient Mode

Compared to the traditional Sidecar model, Ambient Mode still has some limitations:

• When mixing Ambient and Sidecar modes, it’s difficult to apply fine-grained proxy configurations (e.g., EnvoyFilter) to individual Pods.
• Support for multi-cluster, multi-network, and VM workloads is not yet mature and requires caution in production environments.
• Some advanced customizations, such as WASM plugins, cannot be applied directly on a per-Pod basis in Ambient Mode.

Feature and Behavior Comparison

Recommendations

1. If you’re already using the Sidecar model and rely heavily on mature features, you can continue with Sidecar for now.
2. If your priority is resource savings and operational simplicity, and most of your traffic is L4, try Ambient Mode.
3. For hybrid needs, consider mixed deployment, but make sure to plan clearly around boundaries and policies for Sidecar vs. Ambient workloads.

Conclusion

Let’s wrap up with a summary of Ambient Mode’s pros, cons, and where it fits best.

Key Takeaways

1. Ambient Mode reduces per-Pod proxy overhead by removing the Sidecar, significantly lowering resource and operational costs.
2. ztunnel + Waypoint architecture: L7 functionality is only activated when necessary; all other traffic is forwarded efficiently at L4.
3. Although Ambient Mode has reached GA, features like multi-cluster / VM / multi-network support still need further testing and validation.
4. Recommended for: large-scale clusters, primarily L4 traffic, and teams with high demands on resource efficiency and centralized management.

You can find more cloud-native articles and practical insights on my blog at jimmysong.io. If you have any questions about this post or Istio in general, feel free to leave a comment or join the community discussion. Thank you!