Is Ambient Mesh the Future of Service Mesh?
A Practical Look at When (and When Not) to Use Ambient Mesh
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.
Resource cost vs. operational agility
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.
Security & isolation
Use sidecars when you need strong multi-tenant isolation or granular zero trust enforcement.
Debugging & observability
Sidecar meshes excel when deep troubleshooting, workload-level metrics, and tracing clarity are critical.
Traffic efficiency
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.
Platform operations & maturity
For mission-critical platforms, compliance, and hybrid/multi-cloud, sidecars remain the enterprise-grade option.
Ambient Mesh vs. Service Mesh: When to use each model
Choose ambient mesh if:
- You mostly need L4 security (mTLS) and basic policies
- You're running high-density clusters and infrastructure cost reduction is your highest priority
- You're working in single-zone Kubernetes environments
- You’re supporting non-regulated or lower-tier environments
- You have one team managing both platform and services (shared proxy components)
Choose sidecar-based mesh if:
- You require fine-grained security, observability, and policy enforcement
- You operate in multi-zone, hybrid, or regulated environments
- You support multiple teams with self-service mesh configuration
- You run L7-heavy or latency-sensitive workloads
- You prioritize isolation and operational predictability over theoretical efficiency
Final thoughts
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:
Mesh your services together effortlessly with Kong
