Quite understandably, a common question about Istio's ambient mode is "does it scale". While the answer is yes, the question isn't quite right. Almost anything can be made to scale with enough pain and suffering - a better question is "how much effort does it take to meet my scale requirements"?
Scaling sidecars
Istio sidecars scale, and have been used at massive scale by thousands of enterprises. However, achieve a high level of scalability is often extremely expensive -- not only in compute costs, but also operational burden.
Fundamentally, the sidecar architecture suffers from an N^2 problem. Because most configuration is applied on outbound traffic, each sidecar needs configuration to know how to reach every other service. This configuration includes all the services, all of their endpoints, all routing rules, etc.
Here we can see a tiny cluster, each app needs configuration to reach each other app. This ends up with 16 sets of configuration total (4 on each app, as an app is configured to be able to reach itself as well).
As an N^2 problem this quickly becomes untenable.
Instead, users must painstakingly map out their dependencies and manually configure which applications can communicate with others. Assuming most applications only need to communicate with a few others, this enables users to scale Istio to massive clusters (or even multiple clusters). However, it comes at an immense operational cost.
Scaling ambient mode
Unlike sidecars, ambient mode can scale to extremely large clusters (hundreds of thousands of pods) out of the box without any operational toil. This means that on top of the major compute savings, you can spend your time delivering value instead of tinkering with your service mesh.
So how does it work?
Ambient mode has a subtle, but fundamentally different configuration pattern: rather than pushing configuration to each client, the configuration is owned and operated by the service producer, local to the service. This naturally scopes the configuration, rather than relying on the user to do so manually.
Here you can see our waypoint only needs configuration for the 2 apps it is serving! With even as small 25 services with 10 pods each in 2 namespaces, we would see a 100x reduction in configuration size compared to sidecars! Of course, since the scaling behavior of sidecar is polynomial with sidecars while linear with waypoints, the difference gets larger and larger as scale increases.
One analogy here is if we consider reaching google.com.
Google doesn't push down the set of backend endpoints, routing rules, etc down to every users browser -- that would be ridiculous.
Instead, the browser just knows how to reach Google's frontend, which handles everything else from there.
Wondering about how Ztunnel scales? See more from my KubeCon talk where I go in depth on this topic.
Conclusion
While both Istio sidecar mode and Istio ambient mode can be run at large scales, fundamental differences in the architecture impact how easily they scale. While sidecars incur a high operational burden to enable large scale deployments, ambient can handle large scale deployments out of the box with zero configuration or tuning.