Istio 1.24 ambient mode and the sidecarless decision

Istio 1.24 reaches general availability for ambient mode. This release marks the final stage in the feature phase progression for the project. The Istio TOC marked the ztunnel, waypoints, and APIs as stable. The community spent 26 months developing this mode with contributions from Solo.io, Google, Microsoft, Intel, Aviatrix, Huawei, IBM, and Red Hat. The ambient model splits processing into two distinct layers. The lightweight, shared L4 node proxy is the ztunnel. The L7 proxies are called waypoints. Waypoints run outside of application deployments and scale independently for the entire namespace or for multiple services within a namespace. This setup allows users to start with the secure L4 overlay for mTLS, authorization policy, and telemetry. Users can then enable complex L7 handling like retries and traffic splitting on a case-by-case basis. This approach avoids the binary "all-in" injection of sidecars.

I see a major risk in the shared nature of the ztunnel. Because the ztunnel is a node-local component, a single ztunnel failure affects all ambient workloads on that node. In contrast, a sidecar failure only affects one pod. The ztunnel uses the HBONE protocol over HTTP CONNECT. If you see a 503 error in a waypoint, it may be a general catch-all. I also note the ztunnel image has reached 1 million downloads on Docker Hub, with approximately 63,000 pulls in the last week alone.

Choosing between Istio, Linkerd, and Cilium requires matching your operational profile to the tool. Istio provides the most features. It includes weighted routing, header-based routing, fault injection, mirroring, and rate limiting. Linkerd uses a Rust-based proxy called linkerd2-proxy. It provides a smaller footprint. Linkerd sidecar memory stays around 10-20MB per pod, while Istio sidecar memory hits 50-100MB per pod. Cilium uses eBPF at the kernel level to handle network policies and telemetry.

The decision depends on your service count and cluster scale. If you have over 1,000 pods, sidecar overhead becomes a massive cost. Ambient mode mitigates this. You should check your pod count before you decide. If you have a platform team with Envoy experience, Istio is the strongest option. If your team lacks the dedicated platform engineering bandwidth to manage the complex configuration of Istio, I suggest you look at Linkerd instead because it provides reliable mTLS and golden-signal observability without the same operational weight. Linkerd is the choice for teams that want a small footprint and easy operation. Cilium is the best if you want to consolidate your CNI and mesh.

I see a gap in Cilium’s maturity for complex L7 traffic management. It may struggle with sophisticated retry budgets or weighted routing across multiple backends compared to Istio. Istio 1.24 also includes new status messages for Services and AuthorizationPolicies. These help you understand the current state of an object. You can also attach policies directly to ServiceEntrys. This simplifies egress gateway setups.

If you migrate from AWS App Mesh to Istio ambient mode, you can slash about 45% of running containers by removing sidecars and SPIRE agent DaemonSets. This reduces compute costs and observability costs. However, migration is not a small task. You must update labels on a namespace and potentially restart pods. I would warn you that the configuration models differ entirely between meshes. A migration from Istio to Linkerd requires weeks of work and a parallel-run period. You should pick once and plan to live with the choice for at least three years.

The transition from sidecar to sidecarless is a manageable path with Istio. You can build your infrastructure and keep sidecars if you need them. They remain first-class citizens. If you have less than 20 services and a small team, do not adopt a mesh. Use mTLS at the ingress and cert-manager for certificates instead. Use OpenTelemetry directly from applications for observability. In Istio 1.24, the default policy of retrying 503 errors was removed to prevent negative side effects on certain applications. Automatic retries have also improved because the system can now detect and retry on the server sidecar automatically when a backend closes a connection. If your applications handle retries and timeouts, you do not need a mesh. Do you really need a mesh for twenty services?