In April 2025, the ACA Cloud team visited Kubecon + CloudNativeCon 2025 in London. In this blog, we dive into the key takeaways from the conference, focussing on Istio ambient mode, and how it will significantly simplify and accelerate Istio adoption for ACA and our customers.
Istio acts as a proxy between the different applications (services) within a Kubernetes cluster, ensuring that every request flows through a component of Istio. This layer, responsible for communication between all applications, is called a service mesh.
Istio provides traffic management, security, observability and simplified communications for all of the applications within the cluster.
Istio enables detailed traffic management, allowing developers to easily route, distribute, and control traffic between different versions of their services.
With built-in mTLS encryption, Role-Based Access Control (RBAC), and centralized authentication policies, Istio ensures secure communication between services—without needing to manage certificates or security logic at the application level.
Through built-in instrumentation, Istio offers metrics, logs, and traces, providing deep visibility into how services perform and interact. This allows IT teams to quickly identify bottlenecks and debug issues in complex environments.
By abstracting service-to-service communication, Istio removes networking concerns from application code. Developers can focus on features, while the mesh handles routing, security, and reliability behind the scenes.
Want to know more about Istio? Check our other blogs:
For all official Istio documentation, go to https://istio.io/latest/.
Istio ensures that every request within the cluster passes through one of its components (the envoy proxy). This allows Istio to inspect, manage and secure all requests. It's essential for enabling features like request tracing and enforcing encryption between services.
A request that uses all components follows this path :
All gateways and proxy sidecars are running the envoy proxy. The sidecar envoy proxy containers are running within the Kubernetes pod for each application.
Istio is an interesting tool that offers a lot of added benefits, but the current sidecar model does have a few downsides:
Despite the above limitations, ACA has successfully deployed Istio in a few customer environments. And with a redesign, a lot of these concerns might be resolved.
Before we get into the details of the redesign with ambient mode, let us explain which Istio features we use most and why.
Istio enables end-to-end request tracing, helping us:
Most setups and implementations for non-Istio clusters require reconfiguration and managing certificates on an ingress-controller and application level. Using Istio, all pod-to-pod and node-to-node traffic is encrypted by default. This meets regulatory standards (like NIS2) and prevents the need for custom TLS setups in every application.
Istio also simplifies our development flow. For one of our customers, we moved all authentication configuration to Istio using RequestAuthentication objects. Istio will handle authentication with Auth0 using jwt tokens. This means developers don’t need to handle authentication in the application, which leads to less code and faster development. On top of that, Istio takes care of authentication in a consistent way across all services.
Istio also offers additional features for traffic control, like:
Although we have not used this features yet, it is convenient to have them in place as needs evolve.
As mentioned above, the current sidecar model of Istio comes with a few downsides.
The goal of ambient mode is to create a new architecture where a new layer is added, that replaces the sidecars.
Ambient mode introduces a ztunnel (Zero Trust Tunnel), running on each Kubernetes node. It manages:
All traffic will flow through this layer, even if the traffic goes to a container on the same node.
If you need Layer 7 features like advanced traffic control, you’ll also need to deploy a waypoint proxy. This is an envoy proxy that handles the same advanced traffic management tasks as the traditional sidecar mode.
Ambient mode uses fewer resources and decouples Istio from the applications themselves. As a result, changes like upgrades or configuration updates no longer require application restarts. Even better, ambient mode still provides the same powerful features we had with sidecar mode.
While ambient mode is a promising step forward, it’s still under active development. The traditional sidecar setup remains fully supported, and not all features have been migrated yet. For the most up-to-date status, checkIstio’s official documentation.
We’re excited to begin transitioning our current environments to ambient mode and to roll out Istio in clusters that haven’t yet adopted a service mesh. Stay tuned—we’ll be sharing more updates on our journey soon!
Whether you're considering Istio for the first time or looking to modernize your current setup, our cloud experts are happy to explore the possibilities with you.