Ambient Mesh

Ambient Mesh is a sidecar-less service mesh data plane architecture that splits L4 (mTLS, identity) and L7 (HTTP routing, policy) concerns into two separate node-level and per-namespace proxy layers instead of injecting a proxy into every pod. It matters because it decouples mesh adoption from pod lifecycle and resource overhead, letting operators enroll workloads into a mesh without redeploying application containers.

Practical example

A platform team enrolls 400 namespaces into Istio Ambient to enforce mesh-wide mTLS via ztunnel with near-zero per-pod overhead, then deploys waypoint proxies only for the dozen namespaces that need HTTP header-based authorization or fault-injection testing.

Traditional sidecar-based meshes (Istio classic, Linkerd) inject an Envoy or similar proxy container into every application pod, intercepting all ingress/egress traffic via iptables or eBPF redirection. This gives per-pod isolation but multiplies memory/CPU footprint linearly with pod count, complicates upgrades (every sidecar must be rolled), and breaks assumptions in tools that inspect pod network namespaces or count containers per pod. Ambient Mesh removes the per-pod proxy entirely and instead runs a shared ztunnel (zero-trust tunnel) DaemonSet per node, which handles L4 concerns for all pods on that node: mTLS origination/termination, workload identity via SPIFFE-style certificates, and basic L4 authorization policy.

L7 features — HTTP-level routing, retries, circuit breaking, header-based authorization — are handled by an optional, separately scaled waypoint proxy, deployed per namespace or per service account rather than per pod. Traffic flows from a source pod, through the local node’s ztunnel over an HBONE (HTTP-Based Overlay Network Environment) tunnel, to the destination node’s ztunnel, and only detours through a waypoint if L7 policy is actually attached to that workload. This means the vast majority of east-west traffic that only needs mTLS and L4 policy never touches an L7 proxy at all, which is the core latency and resource win over sidecar meshes where every packet always traverses two full Envoy instances.

Under the hood, ztunnel uses the kernel’s socket redirection (via eBPF or iptables, depending on CNI integration) to capture traffic transparently without modifying the pod spec, and workload identity is established via SDS-issued certificates pulled from the mesh CA, similar in spirit to SPIFFE but scoped to the ztunnel process rather than per-pod. Edge cases that bite operators in practice: (1) HBONE tunneling adds a double-encapsulation cost that shows up in packet-capture-based debugging, since raw pod-to-pod pcaps show tunnel headers, not application protocol frames directly; (2) waypoint proxies become a shared blast radius — a namespace-scoped waypoint outage affects every workload with L7 policy in that namespace, unlike sidecar failures which are isolated per pod; (3) node-level ztunnel is a single point of mTLS termination per node, so a compromised node has broader traffic visibility than a compromised sidecar would; (4) partial migration states (some namespaces on ambient, others on sidecar) require careful cross-mode routing configuration, since HBONE and sidecar iptables interception are not automatically interoperable.

Architecturally, Ambient Mesh trades per-workload fault isolation for a dramatic reduction in per-pod overhead and operational friction, making it viable to mesh large multi-tenant clusters where sidecar injection was previously cost-prohibitive; the tradeoff decision ultimately hinges on whether the security and blast-radius benefits of sidecar-level isolation outweigh the resource and upgrade-velocity gains of a shared node/namespace proxy tier.