Is Ambient Better Than Sidecar If You Use Istio? — Why People Are Moving to Ambient

To get straight to the point, if you are introducing Istio to a new Kubernetes environment, there is now ample reason to consider Ambient first. However, Ambient is not a “technology that eliminates L7 proxies.” It’s a structure that removes the Envoy sidecar attached to every Pod, centralizes L4 security with node-local ztunnels, and places waypoint Envoys only where L7 functionalities like HTTP and gRPC are needed.

When considering Istio, the most familiar picture is still an Envoy sidecar attached next to the application container. This structure has been operated and thoroughly validated for a long time, consistently providing everything from mTLS to fine-grained L7 traffic control.

However, as the number of services and Pods increases, questions arise. Does every Pod really need its own dedicated L7 proxy? Is an Envoy capable of interpreting HTTP always necessary for database connections or simple internal TCP communications? Is a structure where the platform team has to restart application Pods to upgrade proxies the best approach?

Istio Ambient Mesh directly addresses these issues. It reached stable status in Istio 1.24 in November 2024, and the Istio project explains that not only new users but also existing sidecar users are actively considering switching to Ambient. This does not mean sidecars are being deprecated. The official roadmap clearly states that sidecars will not be deprecated and that the transition is voluntary.

In this article, we will systematically examine what Ambient actually changes, why people are drawn to this approach, and in which environments sidecar remains a safer choice.

First Misconception to Correct: Ambient is Not a Proxy-less Mesh

The term “sidecarless” can easily lead to understanding Ambient as a proxy-less service mesh. However, Ambient still has proxies. It merely changes the location and responsibility of the proxies.


Layer	Sidecar Mode	Ambient Mode
L4 Security·Transport	Handled by each Pod’s Envoy	Handled by each node’s ztunnel
L7 HTTP·gRPC Processing	Always available in each Pod’s Envoy	Handled by waypoints for necessary services·namespaces
Deployment Unit	One per application Pod	ztunnel per node + optional waypoints
Proxy Implementation	Envoy	ztunnel in Rust, waypoint in Envoy
Operational Responsibility	Strongly coupled with application deployment	Separated as platform components

ztunnel is a lightweight node proxy that handles only L3·L4. It is responsible for workload identity-based mTLS, L4 authorization, TCP observability, and encrypted tunnels. It does not terminate HTTP requests or read headers.

On the other hand, a waypoint is an Envoy-based L7 proxy. It is used when L7 functionalities like HTTP header-based routing, retries, timeouts, circuit breaking, fault injection, L7 authorization, request-level metrics, and tracing are needed. It is typically shared across security boundaries like namespaces or services and is installed and scaled separately outside of application Pods.

Therefore, the accurate statement is not “Ambient eliminates L7 proxies” but rather “Ambient does not force an L7 proxy on every workload.”

Figure: Ambient L7 data path via ztunnel and waypoint · Source: Istio Ambient data plane official documentation, Apache-2.0

First Reason People Want to Move to Ambient: The Unit of Proxy Cost Changes

In Sidecar mode, when one Pod is added, one Envoy is also added. If there are 20 applications and each service runs with 10 Pods, there will be 200 proxies. Each proxy requests CPU and memory, receives configurations, and handles connections and telemetry.

The advantage of this approach is clear isolation. Since each workload has its own proxy, the scope of load and failure is divided per Pod. However, even for Pods with low actual traffic, proxy resources must be reserved considering worst-case scenarios, leading to an accumulation of unused spare resources in environments with many replicas and high traffic variability.

Ambient changes the unit of cost.

ztunnel runs once per node.
Workloads that do not require L7 use only ztunnel.
Only services that require L7 use waypoints.
Waypoints can be shared by multiple workloads and scaled horizontally like a regular Kubernetes Deployment.

In other words, the cost doesn’t disappear; rather, the fixed cost per Pod shifts to a shared cost per node and per L7 boundary. Platform teams can plan ztunnel and waypoint capacity independently, based on actual L4 and L7 traffic volumes.

In the official Istio 1.24 benchmark, when processing 1,000 1KB HTTP requests per second, one 2-worker sidecar used approximately 0.20 vCPU and 60MB, one waypoint used approximately 0.25 vCPU and 60MB, and one ztunnel used approximately 0.06 vCPU and 12MB. These figures are reference values for specific hardware and test conditions and do not guarantee performance in production environments. What’s important is the structure that allows ztunnel and waypoints to be deployed independently, rather than the individual numbers.

Figure: Istio 1.24 official HTTP/1.1 P99 latency comparison. Results from a specific benchmark environment, not a general performance guarantee · Source: Istio Performance and Scalability official documentation, Apache-2.0

Second Reason: Decoupling Mesh Adoption from Application Restarts

Sidecar injection changes the shape of application Pods. Even if an injection label is applied to a namespace, sidecars will not appear in already running Pods, requiring a restart. When changing proxy versions or injection templates, rolling restarts of workloads must also be managed.

In Ambient, simply applying an ambient label to a namespace or workload allows running Pods to be registered within the L4 mesh. It does not change the application container’s spec or add a sidecar.

This change is particularly important for the following:

Stateful workloads with high restart costs
Jobs with short execution times that are prone to conflicts with sidecar startup/shutdown
Clusters where hundreds of Deployments are managed by multiple teams
Organizations where platform teams want to upgrade the mesh independently of application releases

However, when migrating from an existing sidecar to Ambient, the order must be followed. The official guide recommends the sequence of waypoint activation, ambient registration, sidecar injection removal, and existing Pod restart. While Ambient registration itself does not require a restart, removing an already running sidecar from an existing Pod ultimately requires replacing the Pod once.

Third Reason: Gradual Introduction of L4 Security and L7 Features

Traditional sidecars are feature-rich but are essentially bundled products. Even if only mTLS is needed, each Pod gets the entire Envoy capable of performing HTTP routing and retries.

Ambient divides mesh adoption into two stages:

First, apply workload identity, mTLS, L4 authorization, and TCP telemetry with ztunnel.
Then, add waypoints only to namespaces or services that actually require HTTP awareness.

This approach provides a realistic entry point for organizations that find it difficult to apply a service mesh across the entire enterprise at once. Initially, they can achieve the goal of “encrypting internal cluster communication with identity-based mTLS and unifying L4 policies,” and then selectively add services that require canary routing or L7 authorization.

Typical cases where L7 features are needed include:

URL, header, and method-based routing and authorization
HTTP retries, timeouts, and circuit breaking
Traffic splitting and fault injection
Request-level metrics, access logs, and distributed tracing

The appeal of Ambient is not in abandoning L7. It is in making the reasons and costs for L7 explicit on a per-service basis.

Fourth Reason: Clearer Separation of Responsibilities Between Platform and Application Teams

Sidecars reside within application Pods but are mostly managed by platform teams. This ambiguous position creates operational conflicts.

Application teams must accept unrequested containers and resource reservations.
Platform teams must coordinate with application deployment schedules to upgrade proxies.
When a failure occurs, both application and sidecar must be investigated to determine the cause.
Behaviors like HPA, startup probes, and Job termination can be affected by the sidecar’s lifecycle.

Ambient’s ztunnel and waypoints are explicit infrastructure components located outside the application Pod. Platform teams are responsible for proxy deployment, scaling, and upgrades, while application teams declare what L4 and L7 policies are needed.

The fact that waypoints use the Kubernetes Gateway API is also important. Waypoints themselves are deployed as Gateway resources, and policies like HTTPRoute and AuthorizationPolicy are attached to target services. This allows for separating proxy topology from application deployment, creating an operational model closer to Kubernetes standards.

Fifth Reason: Reducing the Number of Times L7 Requests Pass Through a Proxy

In Sidecar mode, when service A calls service B, the request typically passes through A’s sidecar and then B’s sidecar. L7 processing occurs at both the origin and destination.

In Ambient, L7 policies are primarily handled by the destination waypoint. A’s ztunnel sends the request to the waypoint responsible for B, the waypoint processes the policy, and then forwards it to B’s node’s ztunnel. This structure allows L7 Envoy to be traversed only once for the same request.

This does not always mean it’s faster. Results can vary depending on the network path to the waypoint, the load on the shared proxy, connection reuse, packet size, and policy complexity. However, it clearly offers the potential to simplify the path, which previously repeated the same L7 processing on both sidecars, to a single destination-centric point.

When evaluating performance, it’s better to measure the following in your actual environment rather than relying on average values from product whitepapers:

p50·p95·p99 latency for L4-only paths and L4+L7 paths
CPU·memory usage of services with and without waypoints
Changes in connections and error rates during waypoint horizontal scaling
Impact scope of a failed ztunnel or waypoint
Cost changes based on telemetry level

Security Doesn’t Necessarily Improve; Trust Boundaries Change

Stating unequivocally that Ambient is “safer than sidecar” misses important tradeoffs.

Sidecar mode provides the most granular isolation, with each workload having its own proxy and identity key, assuming the proxy itself is not compromised. However, application containers and sidecars share the same Pod’s network and security boundaries. If an application Pod is fully compromised, an attacker risks accessing sidecar communications or mesh credentials.

In Ambient, mesh keys are not placed in application Pods. The ztunnel handles the identity and traffic of workloads on its node, making it difficult for a compromised general application container to directly obtain mesh credentials.

Conversely, ztunnel is shared by multiple workloads on a node. If a ztunnel is compromised, the network and keys of workloads on that node could be affected. Thus, Ambient separates the trust boundary between application Pods and proxies, but in doing so, it makes the node-level shared proxy a critical security boundary.


Security Perspective	Sidecar	Ambient
Mesh Key Location	Sidecar of each application Pod	Node’s ztunnel
Upon Application Compromise	Risk of accessing proxy·keys in the same Pod	Mesh keys are outside the application Pod
Impact of Proxy Compromise	Centered on the affected workload	Potentially extends to workloads on that node
Isolation Unit	Pod	ztunnel is node-level, waypoint is selected boundary

Which is safer depends on the threat model. If “application containers are considered untrusted boundaries,” Ambient’s separation is a strength. If “minimizing the blast radius of a shared node proxy is paramount,” sidecar’s per-Pod isolation might be more familiar.

So, Is Ambient-first the Right Answer for New Istio Deployments?

If many of the following conditions apply, it is reasonable to consider Ambient as the primary candidate:

It is a new Kubernetes-centric Istio environment.
The primary required features are mTLS, workload identity, and L4 authorization.
L7 policies are only needed for some namespaces or services.
You want to avoid the operational burden of injecting sidecars into Pods and Jobs and restarting them.
The platform team wants to manage the mesh data plane independently of application releases.
There are plans to standardize traffic policies around the Gateway API.
There are many small Pods, leading to significant inefficiency in per-Pod proxy resource reservation.

Especially if you “want to adopt a service mesh but don’t want to impose the operational burden of sidecars on all teams,” Ambient offers significant value. This is because it can first provide an L4 security foundation, and L7 can be added when actual needs arise.

When Sidecar Remains a More Conservative Choice

Even though Ambient has reached stable status, not all Istio features have migrated with the same maturity. In the following conditions, it is safer to retain sidecars or transition after thorough validation:

1. VM Workloads Must Be Included in the Mesh

Currently, Ambient does not support VM workloads. If integrating Kubernetes Pods and VMs into the same mesh is a core requirement, sidecar-based Istio is more suitable.

2. Complex Multi-cluster·Multi-network Configurations Are Critical

Ambient’s multi-network, multi-primary multicluster is available as Beta from Istio 1.29. However, it does not support primary-remote topologies, and single-network configurations are not currently the focus of official installation paths. If you have a mix of multiple CNIs, VMs, and complex topologies, the long operational experience of sidecars is safer.

3. Heavy Reliance on EnvoyFilter or Special Extensions

EnvoyFilter targeting waypoints is not currently supported. If custom Envoy filters, special Wasm extensions, or fine-grained proxy tuning are critical, you should first check feature compatibility.

4. Existing VirtualServices Are Very Complex

In the Ambient migration guide, VirtualService support is marked as Alpha, and migrating to Gateway API’s HTTPRoute is recommended. Mixing VirtualService and HTTPRoute for the same workload is also not possible. If many complex policies are built on proprietary APIs, the cost of conversion and regression testing can be high.

5. No Momentary Gap in L7 Authorization Can Be Tolerated

Sidecars and Ambient can coexist in the same cluster and can be rolled back at the namespace level. However, a complete zero-downtime migration for existing workloads using L7 policies is currently difficult. A brief gap in policy enforcement may occur during the transition, so if continuous L7 enforcement is essential, a maintenance window is required.

Migration Pitfalls to Watch Out For in Existing Sidecar Environments

Ambient can be adopted incrementally, but it’s not a matter of simply applying a label.

Check for Waypoint Bypass Possibilities in Mixed Zones

Traffic originating from a sidecar might bypass the destination waypoint during migration. Even if a waypoint-based L7 AuthorizationPolicy is created at the destination, the expected policy might not be applied if the originating workload still has a sidecar.

Traffic from Ingress Also Bypasses Waypoints by Default

Requests sent by an Ingress gateway to a backend do not pass through waypoints by default. To enforce L7 policies at the waypoint, the istio.io/ingress-use-waypoint setting should be reviewed.

Policy Targeting Methods Change

Ambient’s L7 AuthorizationPolicy specifies waypoints or services using targetRefs instead of selectors. RequestAuthentication and WasmPlugin also need to be attached to waypoints. Simply porting existing YAMLs might result in policies being applied at unintended layers.

Observability Shape Also Changes

Moving from sidecar to ztunnel and waypoint changes reporter labels, metric collection locations, and tracing span formats. Do not assume that existing Grafana dashboards and alerts can be maintained as-is. istioctl proxy-status also does not show ztunnel status, so Ambient-specific inspection methods like istioctl ztunnel-config workloads should be incorporated into operational procedures.

Decision Table: What’s Right for Our Team?


Question	Answer Favorable to Ambient	Answer Favorable to Sidecar
Is L7 needed for all workloads?	Only for some	Needed for almost all
Do you want to decouple platform and app releases?	Strongly desired	Current coupling is fine
Are VMs central to the mesh?	No	Yes
High dependency on existing EnvoyFilter?	Low	High
Can you move to Gateway API?	Possible	Need to maintain complex VirtualService
Are you ready to operate shared proxies?	Waypoint capacity·failure isolation possible	Per-Pod isolation is more familiar
Can you tolerate a momentary gap in existing L7 policies?	Maintenance window can be secured	No transition gap allowed
Is it a new deployment?	Consider Ambient-first	Clear requirement for proven sidecar

The practical default can be summarized as follows:

For a new Kubernetes mesh, first establish an L4 foundation with Ambient, and add waypoints only at boundaries where L7 is needed. For existing sidecar environments, design namespace-unit migrations based on policy, observability, and security enforcement paths rather than a feature list.

Checklist for Validating Ambient

It is recommended to actually validate the following items in a small namespace before production:

Features

Do mTLS and L4 AuthorizationPolicy work as expected when using only ztunnel?
Are HTTPRoute, retries, and timeouts applied correctly after adding waypoints?
Do ingress, egress, and cross-namespace calls pass through waypoints as expected?
Which existing VirtualService, DestinationRule, and EnvoyFilter need to be replaced?

Security

Are the policy boundaries clear between L4-only segments without waypoints and L7 segments with waypoints?
Does the combination of STRICT PeerAuthentication and AuthorizationPolicy work as intended?
Are there no bypass paths during the coexistence period of sidecar and Ambient?
Are the permissions of ztunnel and waypoint service accounts minimized?

Operations

What is the impact scope and recovery time in case of ztunnel or waypoint failure?
Are the waypoint autoscaling criteria and minimum replica count appropriate?
Can upgrades and rollbacks be performed without application deployment?
Do existing Grafana dashboards, alerts, and traces reflect the new data path?

Performance

What are the p95·p99 latencies for L4 and L4+L7 paths?
How do waypoint CPU·memory and queue change under concentrated traffic?
How do total reserved resources and actual usage on the node change compared to sidecar?
Does large-scale configuration deployment and endpoint changes converge stably?

Conclusion: Ambient is Not the Deletion of Sidecar, but a Redistribution of Roles

People want to move to Ambient not simply to eliminate one sidecar container.

Ambient re-divides the responsibilities of a service mesh. Identity, mTLS, and L4 policies, which are commonly needed by all workloads, are consolidated into the node’s ztunnel, while more costly L7 processing is placed only on waypoints for services that actually require it. It decouples the proxy’s lifecycle from application deployment, allowing platform teams to operate it as shared infrastructure.

Therefore, Ambient-first is becoming a natural default candidate for new Kubernetes-centric environments. This is because it offers an operational model that is easier to manage than sidecars in terms of resource reservation, Pod restarts, Job compatibility, configuration deployment scale, and team responsibility boundaries.

However, Ambient is not a complete superset of sidecar. Requirements such as VMs, complex multicluster, EnvoyFilter, existing VirtualService, and zero-downtime L7 policy transitions still require caution. The failure and security boundaries created by shared ztunnels and waypoints also need to be redesigned.

The best choice is not to follow trends but to explicitly define the data path. You must first answer how much of your workload is sufficient with L4, which services require L7, who will operate the proxies, and what policy gaps can be tolerated during the transition. When those answers are clear, Ambient becomes not just “Istio without sidecars” but a more phased and operable service mesh design.