In the evolving landscape of service mesh architectures, understanding the network costs associated with different deployment modes is crucial for optimizing performance and resource efficiency. This blog post will compare the network costs of Istio’s Sidecar mode and Ambient mode, drawing insights from my recent article, Service Mesh Data Plane Deployment Modes Explanation.

Sidecar Mode

Istio’s Sidecar mode operates by intercepting traffic between services through a sidecar proxy deployed alongside each pod. This architecture introduces additional network hops, which can lead to increased latency and higher compute utilization. However, it also incorporates a significant performance optimization feature: locality awareness.

The following figure shows the traffic path for Application 1 in Istio Sidecar mode to access Application 2 located in a different availability zone (AZ).

Locality Awareness

Each sidecar proxy is configured to prioritize routing traffic to services within the same availability zone (AZ) or region. This design choice effectively reduces unnecessary cross-AZ traffic, which is often associated with higher latency and costs due to increased data transmission overhead. By limiting traffic to local zones, Sidecar mode optimizes the network path and mitigates the risk of cross-region bottlenecks.

Despite the compute-intensive nature of the sidecar architecture, the locality awareness feature plays a crucial role in maintaining efficient traffic routing. This is particularly beneficial in multi-zone or multi-region cloud deployments, where minimizing cross-region traffic is essential for both performance and cost management.

Ambient Mode

In contrast, Ambient mode utilizes a different approach with its ztunnel and waypoint proxies. Ztunnel ensures locality-aware traffic routing, similar to Sidecar mode, by preferentially routing traffic within the same AZ whenever possible. This helps limit cross-AZ traffic and reduces associated network costs.

The following figure shows the traffic path for Application 1 in Istio Ambient mode to access Application 2 located in a different availability zone (AZ).

Waypoint Proxies

However, waypoint proxies, which are deployed per namespace, are not inherently AZ-aware. This limitation means that traffic routed through waypoint proxies may incur cross-AZ network costs, especially in cloud environments where inter-zone traffic is metered. Therefore, managing waypoint scaling across multiple availability zones becomes critical in Ambient mode.

To optimize costs and performance, waypoint proxies should ideally be distributed across AZs to handle traffic locally. Additionally, communication between ztunnel and waypoints is designed to be proximity-aware, ensuring that traffic is routed to the nearest waypoint proxy. This feature further minimizes cross-AZ charges and reduces latency.

Conclusion

When comparing the network costs of Istio’s Sidecar mode and Ambient mode, both architectures offer locality-aware routing to mitigate cross-AZ traffic. However, Sidecar mode provides a more robust solution with its inherent AZ awareness for each proxy, while Ambient mode requires careful management of waypoint proxies to avoid unnecessary costs.

For a deeper dive into the four primary service mesh data plane deployment models, I encourage you to read the full article here.