Istio Ambient Mesh Architecture Diagram: Ztunnel L4 & Waypoint L7 Data Plane

Istio’s ambient data-plane documentation sorts every workload into one of three categories, and this evergreen Istio ambient mesh architecture diagram should do the same. Out of mesh means a normal pod: ambient is not enabled. In mesh means Layer 4 interception by a node-local ztunnel, turned on with the label istio.io/dataplane-mode=ambient. Waypoint enabled means that pod is also in the mesh and a waypoint proxy is deployed for Layer 7 policy, selected with istio.io/use-waypoint. The control-plane page adds the other half: ambient still uses Istio’s control plane, and istiod talks to the ztunnel on each node. Neither page is marked preview or beta in the sections used here.

What this Istio ambient mesh architecture diagram shows

Ambient uses one ztunnel per node, not a sidecar in every pod. The L4 example uses a single ztunnel on each of two nodes, with mTLS inside HBONE and SPIFFE identities for the workloads. The figure looks like a tunnel between ztunnels, but encapsulation happens in the source pod network namespace and decapsulation in the destination namespace. Ztunnel still handles HBONE from inside those namespaces. Same-node traffic also hits the local ztunnel, so L4 policy and telemetry still apply. L7 is an optional hop.

The problem this architecture is solving

The control-plane page contrasts one ztunnel per node with a sidecar in every pod, and it points at a smaller xDS set from istiod as the reason that shape is easier to push and debug. The data-plane problem is getting mTLS and L4 policy without forcing every connection through L7. The doc says a waypoint is unnecessary unless you need L7. On this figure that hop is optional.

Main components and trust boundaries

Ztunnel terminates redirected traffic for pods on its node and does not use its own identity for workload mTLS. It holds a certificate per service account of the node-local pods it proxies. It authenticates to the CA as itself, then requests the workload identity. The CA must reject identities not running on that node. Istio’s CA uses a Kubernetes Service Account JWT that encodes pod information; any other CA must enforce the same rule, so a compromised node does not become the whole mesh. Certificates rotate near expiry. A newly seen identity is fetched at low priority unless a live request needs it now.

A waypoint only accepts HBONE. It checks that the traffic is for a pod or Service that uses it, then enforces L7 policies the doc names: AuthorizationPolicy, RequestAuthentication, WasmPlugin, Telemetry, and similar. istiod is the control plane. Ztunnel uses xDS both for configuration and to obtain those mTLS certificates. The control-plane page does not inventory every xDS type; it says the set is simplified relative to sidecars.

Request or data path, step by step

Outbound from an in-mesh pod is transparently redirected to the node-local ztunnel, which chooses where to forward. Routing matches Kubernetes defaults: a Service goes to one of its endpoints, and a pod IP goes to that IP. If the destination is in the mesh, or otherwise has an Istio proxy such as a sidecar, the request is upgraded to an encrypted HBONE tunnel. If the destination has a waypoint, the request is also forwarded there for L7 policy. A Service with a waypoint gets that hop for L7; a direct pod IP does too when that pod has a waypoint. The doc notes that labels can differ across pods in one Deployment so only some use a waypoint, and it recommends avoiding that case.

Inbound traffic is redirected to the local ztunnel, which forwards only if authorization policy passes. HBONE and plaintext are both accepted by default. Out-of-mesh sources have no peer identity, skip any waypoint, and can be blocked by a policy that requires an identity. Sidecars and gateways also skip waypoints today; the doc says they will learn about waypoints in a future release. A waypoint then applies L7 policy, forwards a pod request directly, and load-balances a Service unless a route overrides it. The doc’s HTTPRoute sends the echo Service to echo-v1 on port 80. The waypoint need not share a node with either pod.

The diagram: labeled boxes and failure or isolation edges

Three states: out of mesh, in-mesh L4, and waypoint-enabled. Solid arrows are the pod redirect to the node ztunnel, HBONE from that ztunnel to the peer node ztunnel, and istiod config into the node ztunnel and the waypoint. The waypoint box is dashed. Two dashed paths are optional and labeled L7 only, from the node ztunnel into the waypoint and from the waypoint into the peer node ztunnel. The control-plane page documents istiod and xDS with ztunnel. It does not state that istiod configures the waypoint. The figure has no rejected-certificate marks, no plaintext-skip marks, and no sidecar or gateway marks. Ztunnel emits Istio standard TCP metrics.

What the source does not claim (preview, case study, or limits)

Neither page publishes latency or CPU savings. “Improved performance” means a smaller xDS set, not a measured speedup. Waypoint awareness for sidecars and gateways is a future release. A waypoint is optional. Ztunnel’s own identity is not the application’s mTLS peer. Mixed waypoint labels in one Deployment are an advanced case the doc says to avoid.

How this differs from a nearby pattern on ByteDiagram

A Kubernetes cluster architecture diagram is a map of the cluster itself. This page is the sidecarless ambient data plane inside a cluster: node ztunnel for L4, optional waypoint for L7, and istiod over xDS. It does not replace a live Istio article on ByteDiagram. None is live. Ambient on this page is not a sidecar-per-pod mesh, and the cluster guide is not the source for HBONE or waypoint rules.

FAQ

What are the three workload categories in an Istio ambient mesh?

The data-plane doc lists out of mesh (ambient off), in mesh (L4 interception by ztunnel when istio.io/dataplane-mode=ambient), and in mesh with a waypoint (L7 policy when istio.io/use-waypoint is set). L4 mTLS and L4 policy do not require a waypoint.

Whose identity does ztunnel use for workload mTLS?

Not its own. Ztunnel keeps a certificate per workload service account on the node and uses those identities for HBONE mTLS. It authenticates to the CA as itself, and the CA must refuse identities that are not running on that node. Istio enforces that with a Kubernetes Service Account JWT.

Do sidecars and gateways send traffic through an ambient waypoint?

Not today. The data-plane doc says out-of-mesh clients, sidecars, and gateways send requests directly to the destination even if a waypoint is configured. It says sidecars and gateways will be made aware of waypoint proxies in a future release.

Conclusion

The figure shows out of mesh, in-mesh L4, and optional waypoint L7. The control-plane page shows istiod configuring ztunnel over xDS. Sidecar and gateway awareness of waypoints is a future release in the data-plane doc. Browse more on the ByteDiagram blog.