The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting development, the reality is more nuanced. It is more than likely that a sidecar-based mesh is still a better fit for your workload and organization.
In this post, we compare ambient mesh to traditional sidecar-based meshes in terms of security, observability, traffic efficiency, maturity, and operational cost, allowing you to make an informed decision about the architectural implementation for your service mesh.
One of the most widely discussed benefits of ambient mesh is its potential to reduce resource usage by eliminating sidecars from every pod. Without a sidecar proxy running alongside each workload, clusters can achieve significant savings in CPU and memory — especially in high-density environments where many small services are co-located on a node. L4 traffic, in particular, benefits from this approach, as it is handled efficiently by a single ztunnel daemon running on each node. This shared proxy manages mutual TLS and routing for all pods, reducing redundancy and centralizing responsibility for low-level traffic handling.
However, this resource efficiency at the data plane level comes with new operational trade-offs. L7 traffic, which includes HTTP routing, authorization policies, and retries, must still pass through centralized Waypoint proxies. These Waypoints are deployed per namespace or service account, and they introduce an extra hop in the traffic path. They also bring back the need for proxy capacity planning — but now in a centralized, shared form. You must monitor, colocate, and autoscale these components carefully to avoid bottlenecks. The shared nature of these proxies increases the potential blast radius of configuration errors or capacity shortfalls, especially when multiple workloads rely on a single Waypoint instance.
By contrast, sidecar-based meshes incur a higher total resource footprint because each pod runs its own Envoy proxy. But this model brings advantages that go beyond performance. Each workload scales independently, with no need to centrally manage proxy pools. Isolation is naturally achieved, telemetry is workload-specific, and policies can be applied, tested, and rolled out at the level of individual services.
Operationally, the sidecar model offers a more deterministic and modular system, where failures and configuration changes are scoped to a single pod, not an entire node or namespace.
Ultimately, the cost equation is not just about CPU and memory. It’s about predictability, visibility, and the ability to troubleshoot and operate at scale. For environments where operational simplicity, compliance, or team autonomy are critical, the higher resource use of sidecars often translates into lower operational risk and overhead in the long run.
Use sidecars when you need strong multi-tenant isolation or granular zero trust enforcement.
Sidecar meshes excel when deep troubleshooting, workload-level metrics, and tracing clarity are critical.
Ambient mesh works well for L4-only or low-complexity L7 policy requirements. Sidecars still win for high-volume L7 traffic that scales with the number of pods.
For mission-critical platforms, compliance, and hybrid/multi-cloud, sidecars remain the enterprise-grade option.
Choose ambient mesh if:
Choose sidecar-based mesh if:
Ambient mesh seems, on the face of it, like a compelling evolution of service mesh design promising reduced resource usage and simpler onboarding for lightweight, L4-dominant applications. But that simplicity comes at the cost of operational complexity, L7 capability gaps, and reduced isolation. In many engineering tasks and disciplines simplicity often wins out over pure efficiency, and it’s no different with service mesh. The “neater” sidecar-based approach is easier to reason about, easier to deploy, and is easier to operate – particularly with Kong Mesh, built with enterprises and platform teams in mind.
At Kong we have taken a deliberate wait-and-see approach to investing in the sidecar-less ambient mesh approach. It’s still an early-stage technology, and even the proponents of ambient mesh like Istio aren’t recommending it yet for mission-critical environments, only for single-cluster environments. A recent blog post from Tetrate, a commercial distributor of Istio, presents similar arguments.
For almost all enterprise production environments — particularly those with diverse services, high compliance needs, or multiple teams — sidecar-based service meshes are still the right approach and provide the clarity, control, and maturity our customers can count on.
Here’s some more reading material on Kong Mesh:
Discover how API management and service mesh can go hand in hand toward secured platforms Over the last ten years, Kongers have witnessed hundreds of companies adopting a full lifecycle API management platform and have been working with the peop
In this post, Nathaniel Reynolds, Associate Director of Informatics Architecture & DevOps at Moderna Therapeutics, talks about service mesh, removing limitations with open source, and how AI helps developers do more. No one can predict the future,
Kong Mesh (and Kuma , the open source project upon which Kong Mesh is built) supports multiple zones and meshes. What is the difference between a zone and a mesh, though? And when should one use a zone versus a mesh or vice versa? By the time you'
Kubernetes is hard. Last year, we started the developer experience product at American Airlines. As we transitioned into the later half of 2020 and into 2021, we wanted to tackle Kubernetes app deployments. We aimed to make it easy for the users to
In this episode of Kongcast , I spoke with Scott Lowe , principal field engineer at Kong , about what a service mesh does and when to use it, among other common mesh-related questions. Check out the transcript and video from our conversation belo
Service Mesh is an infrastructure layer that has become a common architectural pattern for intra-service transparent communication. By combining Kubernetes a container orchestration framework, you can form a powerful platform for your microservice