When deploying microservices, one component that is not usually considered is operations between the services running in the cluster. Most times, the only consideration is how the services will communicate with one another. But it goes beyond communication. All the operations and systems considered for services exposed to the internet should be given the same consideration as services running within the cluster. Systems such as Secured Communication, Traffic Routing, Throttling, Circuit breaker, Graceful Deployments, and more. Adding these as part of the internal operations of microservices improves the resilience, security, and availability of the internal components running in the cluster. This concept is known as a Service Mesh. But deploying the common service mesh technologies is usually expensive because of the sidecar implementation that enforces a pod running beside your application. This introduces extra operational complexities in managing the life cycle of your workload because the sidecar needs to be taken into consideration as they are both managed in the same pod/deployment, but as different containers. Any change to your deployment means a re-deployment of your application and the sidecar. What about upgrades? They can become hectic as an upgrade to the control plane and data plane of the service mesh means a total re-deployment of all workloads. Finally the cost implications, a sidecar could cost twice the worker nodes needed for the original workloads due to its resource requirements. All these makes Service Mesh implementation seem like an expensive feature to deploy for Kubernetes workloads. The Istio Ambient mode is here to remove these complexities and make service mesh deployment, maintenance and scaling much easier. Lets do a little recap into a service mesh and then delve deep into the Istio Ambient mode of Service Mesh deployment.
What is a Service Mesh ?
According to Wikipedia; it is a dedicated communication layer can provide numerous benefits, such as providing observability into communications, providing secure connections, and automating retries and backoff for failed requests. A service mesh consists of network proxies paired with each service in an application and a set of task-management processes. The proxies are called the data plane and the management processes are called the control plane. The data plane intercepts calls between different services and processes them; the control plane is the brain of the mesh that coordinates the behavior of proxies and provides APIs for operations and maintenance personnel to manipulate and observe the entire network.
There is a detailed article on service mesh, its components and features here. If you are new to Istio, there is an article that explains what Istio is and how deploy it here.
Cost of Istio Sidecar Mode
Before getting into the details of the Istio Ambient mode, what it is, how it works and how it is better, lets first break-down the cost of what it takes to run Istio in sidecar mode, which is the default mode for Istio. Lets say we have an EKS cluster with three worker nodes (t3.medium), with a bunch of pods running in the worker nodes. Then, we decide to deploy the Istio to the cluster. Here is a breakdown of the cost, before and after Istio.
t3.medium Instance Overview (baseline)
- vCPU: 2
- RAM: 4 GB
- Pricing (On-Demand, US East): ~$0.0416 per hour
- Monthly Cost per Node: $0.0416 × 24 hours × 30 days ≈ $29.95
- For 3 nodes: ~$90/month total compute cost (baseline, no sidecars).
When You Add Istio Sidecars
Each Kubernetes pod now gets an Envoy proxy sidecar, which:
- Consumes ~100–300 MB of RAM per pod (realistically, assume ~200 MB)
- Consumes ~0.1–0.2 vCPU (depending on traffic)
- Scales linearly: Every application pod gets a sidecar
Let’s assume you’re running 30 pods total across your 3 nodes (10 per node), which is modest for t3.medium.
With sidecars, that becomes:
- 30 additional Envoy sidecar containers
- Memory increase: 30 × 200 MB = ~6 GB RAM
- CPU increase: 30 × 0.15 vCPU = ~4.5 vCPU
Your 3 t3.medium nodes collectively have:
- 6 vCPUs and 12 GB RAM total
That means:
- You’re exceeding both CPU and RAM limits, even if just by a bit.
- Kubernetes will start evicting pods or you’ll have performance bottlenecks.
Cost Impact Summary
To handle the overhead, you’d likely need to add at least 1 more node, or scale up your existing nodes to something like t3.large:
Option 1: Add 1 more t3.medium
- Cost increase: + ~$30/month (25–30%)
Option 2: Upgrade to t3.large (2 vCPU, 8 GB RAM)
- t3.large cost: ~$0.0832/hour → ~$60/month per node
- For 3 upgraded nodes: $180/month total
- Increase over original cost (~$90): + $90/month (100% increase)
Adding Istio sidecars to a modest cluster running t3.medium EC2s can double your infrastructure cost, especially if you’re running a decent number of pods. The overhead from sidecars adds up quickly, particularly in memory-constrained environments. In a larger scenario where the worker nodes are 10 or 20 this cost can quickly sky-rocket due to Istio sidecar implementation. But can this be totally evaded ? The answer is yes. Let’s see how the Ambient mode can help to eradicate this huge cost and other operational overhead and still maintain all the benefits of the Istio service mesh.
What is Istio Ambient Mode?
This is an innovative evolution of the Istio service mesh architecture, designed to eliminate the need for sidecar proxies in application pods. Jointly developed by Solo.io and Google, Ambient Mode addresses many of the operational challenges associated with traditional service mesh deployments, making it significantly easier to adopt, manage, and scale Istio within modern cloud-native environments. This new architecture aims to streamline the service mesh experience by decoupling the data plane from the application layer, thereby offering increased flexibility, improved performance, enhanced security, and reduced operational overhead.
Traditionally, Istio’s service mesh capabilities such as; traffic management, security policies, telemetry collection, and observability, have been delivered through sidecar proxies (usually Envoy) injected into each application pod. While effective and widely used, this model introduces a number of limitations and inefficiencies, particularly at scale. Sidecar injection is an intrusive process that requires restarting application pods and modifying deployment configurations. This coupling of the application lifecycle with the mesh infrastructure not only increases complexity but also impacts reliability, performance, and transparency. For example, auto-injection modifies the pod spec at runtime, which can deviate from the original deployment manifests used in CI/CD pipelines, posing risks for reproducibility and compliance.
In addition, sidecars consume memory and CPU resources for each workload independently, leading to considerable overhead in large-scale environments. Upgrading the data plane often necessitates restarting all workloads that use sidecars, resulting in potential service disruption. Moreover, sidecars can pose security concerns; if an application is compromised, its co-located sidecar and the sensitive credentials it holds could also be at risk. Finally, adopting Istio’s features has historically been an “all-or-nothing” decision: enabling something like mutual TLS (mTLS) means adopting the entire sidecar stack, including complex Layer 7 processing that may not be needed.
Architecture of Ambient Mode
Istio Ambient Mode introduces a fresh, sidecar-less approach to service mesh architecture that dramatically simplifies how services are connected, secured, and observed. Unlike the traditional model where each application pod includes a sidecar proxy (usually Envoy) to handle networking tasks, Ambient Mode completely decouples the service mesh data plane from the application pods. This is made possible by breaking the data plane into two distinct layers: the secure overlay layer and the L7 waypoint proxy layer.
At the heart of the secure overlay layer is a lightweight component called ztunnel, written in Rust for high performance and low resource usage. It’s deployed as a DaemonSet on every Kubernetes node, acting as a shared Layer 4 (L4) proxy for all the pods on that node. Ztunnel handles tasks like mutual TLS (mTLS), identity enforcement, and basic telemetry, replacing what sidecars would typically do, but in a centralized and much more efficient way. This shared nature eliminates the need to run dozens or hundreds of separate sidecars, saving considerable memory and CPU resources.
To transparently route traffic to and from pods without modifying the application containers, Istio Ambient relies on the Istio CNI plug-in. This plug-in sets up in-pod network redirection rules using iptables or eBPF, redirecting traffic to the ztunnel without altering the pod spec or requiring restarts. Importantly, this keeps the service mesh completely invisible to application code and lets workloads be added to the mesh dynamically with just a namespace or pod label.
For advanced Layer 7 (L7) traffic management; like routing, retries, observability, and access control based on HTTP headers. Ambient Mode introduces optional waypoint proxies. These are shared Envoy-based proxies deployed per namespace or per service account. Unlike sidecars, waypoint proxies only handle L7 traffic when needed, and can be scaled independently based on actual request load, avoiding overprovisioning.
Behind the scenes, traffic between ztunnel and waypoint proxies flows over a specialized protocol called HBONE (HTTP-Based Overlay Network Environment), built on HTTP/2 CONNECT. It allows efficient, encrypted tunnels for service-to-service communication, supporting modern use cases like server-first protocols and avoiding common sidecar pitfalls.
In essence, Istio Ambient Mode offers a clean separation of concerns: lightweight L4 capabilities are handled by ztunnel and network-level policies, while optional L7 behaviors are offloaded to waypoint proxies when required. This modular, non-intrusive design improves performance, enhances security by isolating the mesh from the app, lowers costs by reducing resource consumption, and simplifies onboarding and upgrades. It’s designed for large-scale, zero-trust environments and is a significant evolution over the sidecar model—making service mesh adoption more accessible and manageable for modern Kubernetes workloads.
What are the benefits of this new implementation ?
Benefits of Ambient Mode
By decoupling application workloads from the mesh infrastructure, Ambient Mode provides several key advantages:
Simplified Onboarding: Applications can be added to the mesh dynamically using Kubernetes labels—either at the pod or namespace level—without changing application manifests or restarting workloads.
Improved Resource Efficiency: Eliminating sidecars means fewer running proxies, which drastically reduces memory and CPU consumption. Reports suggest that this approach can cut service mesh costs by over 90%.
Better Performance: For workloads that only require secure communication (L4), traffic bypasses Layer 7 processing entirely, resulting in lower latency and higher throughput.
Enhanced Security: The separation of concerns means that application containers no longer share runtime environments with security-sensitive components like proxies and certificates. This isolation strengthens the overall security posture of the mesh.
Seamless Upgrades: Mesh infrastructure can be upgraded independently of the applications, eliminating the need to redeploy or restart workloads during data plane updates.
More Flexible Feature Adoption: Users can incrementally adopt only the mesh features they need. For instance, if mTLS is required for compliance, it can be enabled via the secure overlay without enabling the full suite of L7 traffic controls.
Comparison: Sidecar vs Ambient Mode
The following table summarizes the difference between Sidecar and Ambient Mode:
Deploying in Ambient Mode
Similar to the sidecar approach, it can either be deployed with the istioctl command line or Helm. Both require the ambient flag to ensure Istio is not deployed in the sidecar mode
Istioctl Deployment
- Install istioctl from the official package registry and install by running the following command
curl -L https://istio.io/downloadIstio | sh -
- Navigate to the package that was just downloaded depending on the latest version as at the time of running the command, it should have a name istio-xxx (where xx represents the latest version that has been dowloaded)
- The directory contains; Sample application in samples/ directory, istioctl client library in the bin/ directory
- Add the istioctl binary file to your executable directory of your operating system (Linux/Mac/Windows)
export PATH=$PWD/bin:$PATH
- Run the command to install Istio Ambient Mode
istioctl install --set profile=ambient --skip-confirmation
This command installs the ambient profile on the cluster defined by your Kubernetes configuration.
The other option is the Helm option which is more suitable for automation and Infrastructure as Code setups.
Helm Deployment
Ensure Helm binary is installed properly and a Kubernetes cluster is also available and Helm can communicate with it seamlessly. Then use the following steps to install Istio Ambient mode
- Configure the Helm repository
helm repo add istio https://istio-release.storage.googleapis.com/charts helm repo update
- Install Control Plane and Base Components
helm install istio-base istio/base -n istio-system --create-namespace --wait
- Install isitod in the Kubernetes cluster
helm install istiod istio/istiod --namespace istio-system --set profile=ambient --wait
Notice in the command, there is a flag profile=ambient. This flag is what makes the Istio deployment different and facilities the sidecarless setup.
- Install the Istio CNI agent which is reponsible for detecting pods that belong to the ambient mesh and configuring the traffic redirection between pods and the ztunnel node proxy
helm install istio-cni istio/cni -n istio-system --set profile=ambient --wait
- Install the ztunnel Daemonset, the node proxy component of Istio’s ambient mode
helm install ztunnel istio/ztunnel -n istio-system --wait
After this deployment, Istio needs to be enabled for the specific namespace that needs it. Use the following command to enable Istio
kubectl label namespace <your-app-namespace> istio.io/dataplane-mode=ambient
This will enable automatic interception of all traffic within that namespace via ztunnel, which replaces the sidecar option. Ztunnel runs as a Daemonset in the cluster which means it will sits on every node and can intercept traffic for every pod in every node. At this point, all workloads in the namespace specified can use the features of Istio without re-deployment.
Conclusion
The Istio Ambient mode is an affordable, simpler, and faster approach to deployment and management of a service mesh. It removes all the complexities of sidecars and saves the huge operational and capital expenses involved in using a Service Mesh. It does all these without losing all the features of the sidecar mode, which makes it a better implementation mode of the Istio Service Mesh.
