Ambient Mesh

Istio Ambient Mesh is Istio’s sidecar-less deployment mode. Instead of injecting an Envoy sidecar into every workload pod, Ambient Mesh splits proxy responsibilities across two purpose-built components — reducing per-pod overhead and simplifying proxy management while still providing secure, observable, and controllable traffic. Key benefits

Sidecar-less architecture reduces CPU/memory overhead and the number of proxies to manage.
Transparent Layer 4 controls remain available for all workloads.
Layer 7 capabilities are provided on-demand using per-namespace Waypoint proxies.

Core components

ztunnel — a Rust-based transparent proxy deployed as a DaemonSet (one per node). It intercepts inbound and outbound traffic for the node’s workloads and provides mTLS, authentication/authorization checks, and telemetry for pod traffic on that node.
Waypoint — an Envoy-based proxy deployed as a standalone pod in a namespace when Layer 7 features are required. It handles application-layer routing and policies without being injected as a per-pod sidecar.

ztunnel is a Rust-based transparent proxy running as a DaemonSet (one per node). Waypoint is an Envoy-based proxy deployed as a pod (per-namespace) when L7 features are required.

Layer responsibilities

ztunnel (Layer 4)
- Transparent interception of TCP/UDP traffic for all workloads on the node
- mTLS (encryption/decryption)
- Node-level authentication/authorization and telemetry
- Basic routing to healthy endpoints
Waypoint (Layer 7)
- Application-level routing (path/header matches, rewrites)
- Traffic splitting, fault injection, delays, aborts
- Advanced L7 features where required (deployed per-namespace)

The image provides information about "Waypoint," describing it as a proxy deployed as a pod, a standalone workload, handling Layer 7 policies, deployed per namespace, and not supporting timeouts, retries, or mirroring.

When to use each component

If you only need secure transport and basic connectivity controls, ztunnel (Layer 4) covers most use cases with minimal overhead.
If you need application-layer routing, policy enforcement, header/path-based behavior, or traffic-splitting, deploy Waypoint in the target namespace to enable L7 capabilities for those workloads.

Gateway API and HTTPRoute Ambient Mesh often relies on Kubernetes-native APIs for expressing Layer 7 routing. The Gateway API — specifically HTTPRoute — is a common pattern for L7 routing in ambient deployments, and integrates with Waypoint when application-layer features are required. Example: HTTPRoute splitting traffic between two service backends

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: hello-http-route
  namespace: hello
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: mesh-gateway
  rules:
    - backendRefs:
        - name: helloworld-v1
          port: 5000
          weight: 5
        - name: helloworld-v2
          port: 5000
          weight: 95

The Gateway API approach differs from Istio’s sidecar-based VirtualService and DestinationRule model. For the Prep Course - Istio Certified Associate (ICA) Certification, installing Ambient mode and labeling namespaces is the primary requirement — in-depth Gateway API and Waypoint configuration is outside the exam scope. For current feature details and roadmap, see the Istio Ambient Mesh docs.

Architecture overview

Ambient Mesh removes the per-pod sidecar. ztunnels run on each node to handle Layer 4 traffic; Waypoint proxies are deployed per-namespace only when L7 functionality is required. Make sure to label namespaces appropriately so Ambient behavior applies to workloads in those namespaces.

The image depicts a sidecar-less service mesh architecture within a Kubernetes environment, showcasing three nodes with different apps, services, namespaces, and zTunnels connected by Waypoints.

Feature parity and limitations

Not all sidecar-mode features are yet available in Ambient Mesh. Some fine-grained timeout/retry/mirroring semantics and specific L7 behaviors may be absent or different in Waypoint.
The Istio project is actively evolving Ambient Mesh; consult the official docs for the latest information: https://istio.io/latest/docs/ops/deployment/ambient/

Quick comparison

Component	Layer	Deployed as	Primary responsibilities	When to use
ztunnel	Layer 4 (transport)	DaemonSet (one per node)	Transparent interception, mTLS, node-level authN/authZ, telemetry, routing to endpoints	Default for all workloads to provide secure transport
Waypoint	Layer 7 (application)	Deployment/Pod (per-namespace)	Path/header routing, traffic splitting, rewrites, fault injection	Deploy when application-layer policies or routing are required

Benefits summary

Reduced proxy footprint (fewer proxies overall vs. sidecar-per-pod)
Lower resource usage per node and per-cluster
Simpler operational model for many deployment patterns

The image highlights a benefit of using Istio Ambient Mesh over traditional Istio Service Mesh, emphasizing fewer proxies to manage, accompanied by a small graphic.

Closing Ambient Mesh offers a compelling, sidecar-less alternative to traditional Istio deployments by moving transport concerns to a per-node proxy (ztunnel) and enabling L7 features only when needed (Waypoint). For deployment guidance, configuration examples, and compatibility notes, reference the Istio documentation and the Gateway API project:

Istio Ambient Mesh docs: https://istio.io/latest/docs/ops/deployment/ambient/
Gateway API: https://gateway-api.sigs.k8s.io/

Following this introduction, you will find a summary and hands-on configuration and installation tasks to practice Ambient mode setup and namespace labeling.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

Watch Video