Deploy Istio Waypoint Proxies in Ambient Mesh Mode (2026)

Ambient mode transforms Istio from a sidecar-centric mesh into a transparent network proxy layer.

Let’s see it in action. Imagine we have two services, productpage and details, both running in Kubernetes pods. In a traditional Istio setup, each pod would have an Envoy sidecar injected. In ambient mode, we don’t inject sidecars into application pods. Instead, we deploy dedicated "waypoint" proxies.

Here’s a simplified view of the network flow:

1. Pod A (productpage) wants to talk to Pod B (details).
2. Pod A’s traffic is automatically routed by the Kubernetes network (via CNI) to the ambient waypoint proxy for its namespace.
3. The waypoint proxy inspects the traffic, applies any relevant Istio policies (e.g., authorization, telemetry), and then forwards it to the ambient waypoint proxy for Pod B’s namespace.
4. The waypoint proxy for Pod B then routes the traffic to the actual Pod B (details) container.

This means the application pods are unaware of Istio. They simply send traffic to other IPs, and the network layer, augmented by Istio’s ambient proxies, handles the rest.

The core problem ambient mode solves is the operational overhead and complexity of sidecar injection. Sidecars consume resources on every application pod, require application restarts or pod recreations to inject/update, and can complicate debugging because you’re dealing with two containers per pod. Ambient mode centralizes this intelligence into dedicated waypoint proxies, simplifying application deployments and management.

Internally, ambient mode leverages a combination of Kubernetes Network Policies and Envoy’s IPtables redirection capabilities. When you enable ambient mode in a namespace, Istio’s control plane configures the network to redirect ingress and egress traffic from pods to the designated waypoint proxy for that namespace. The waypoint proxy then acts as a full-fledged Envoy proxy, capable of performing all Istio’s traffic management, security, and observability functions.

The key components are:

• Application Pods: Standard pods with no sidecars.
• Waypoint Proxies: Dedicated Envoy pods deployed by Istio. These are the "ambient" proxies that handle traffic for pods in their namespace.
• ztunnel (Zero-trust tunnel): In some Istio versions and configurations, ztunnel acts as the initial hop for all traffic entering or leaving a namespace in ambient mode, establishing mTLS and routing to the appropriate waypoint.
• Kubernetes Network: Responsible for routing traffic to the ztunnel or waypoint proxies based on Istio’s network policies.

Your primary lever for controlling behavior is Istio’s Gateway and VirtualService resources, but applied to the waypoint proxy context rather than a traditional sidecar. For example, to define an ingress gateway for traffic entering your ambient mesh, you’d configure a Gateway resource that specifies the waypoint proxy to use.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-ambient-ingress
  namespace: istio-system # Or where your waypoint is deployed
spec:
  selector:
    istio: ambient-waypoint # This label points to your waypoint proxy deployment
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

This Gateway resource tells Istio that the waypoint proxy labeled istio: ambient-waypoint should be configured to listen on port 80 for all hosts, acting as the entry point for external traffic into the ambient mesh. You then use VirtualService resources to route this incoming traffic to your services.

The most surprising thing is how Istio achieves true network transparency without modifying application containers. It leverages the underlying Kubernetes networking infrastructure and Envoy’s powerful IPtables manipulation to intercept and redirect traffic at the network layer before it even reaches the application’s network stack or after it leaves. This means applications don’t need to be aware they are part of a service mesh; they just send IP packets, and Istio’s ambient proxies handle the rest, applying policies, encrypting traffic, and collecting telemetry.

The next concept to explore is how to secure communication between namespaces within the ambient mesh using ztunnel and automatic mTLS.