Scaling Across Clusters: How Ambient Supports Multi-Cluster Mesh in Istio
In this post, we explore how Istio’s ambient mode introduces architectural changes for multi-cluster service mesh, simplifying mesh expansion and onboarding while supporting hybrid deployment models.
Tetrate 
In our previous blog, we introduced how Istio’s ambient mode offers a more infrastructure-oriented approach to observability. In this follow-up, we focus on another area where ambient introduces architectural change: multi-cluster service mesh.
Istio has long supported multi-cluster topologies, but operationalizing them can be complex—especially at scale. As organizations expand across regions, clouds, or teams, managing multiple clusters often involves coordination around control planes, sidecars, service discovery, and trust domains.
Ambient mode introduces a different approach to multi-cluster mesh by shifting core data plane functionality—like encryption, routing, and telemetry—from sidecars in each pod to shared infrastructure components that operate at the node or namespace level.
This post outlines how ambient works in multi-cluster environments, where it may offer benefits, and how it fits into a broader hybrid Istio strategy.
Multi-Cluster Mesh with Sidecars: Tradeoffs to Consider
In a traditional Istio deployment, each pod includes a sidecar proxy that handles service communication, security, telemetry, and routing. When multiple clusters are involved, this model typically includes:
- Managing sidecar injection across clusters
- Synchronizing or federating control planes
- Maintaining trust domains and certificates
- Configuring service discovery between clusters
This approach provides fine-grained visibility, Layer 7 control, and per-pod enforcement—but may also introduce operational complexity, particularly as the number of clusters increases or the environment includes heterogeneous infrastructure (e.g., Kubernetes and VMs).
How Ambient Mode Approaches Multi-Cluster
Ambient mode introduces shared infrastructure components that decouple mesh functionality from individual workloads:
- zTunnel (Layer 4): Enables mutual TLS and identity-based communication between workloads
- Waypoint Proxy (optional, Layer 7): Handles traffic routing and policy enforcement at the namespace level
This shift introduces several design implications for multi-cluster mesh:
Lower Friction for Mesh Expansion
Ambient mode can make it easier to extend the mesh to new clusters or workloads by removing the need for sidecar injection and per-pod modifications. This helps reduce configuration overhead during onboarding.
Easier Incremental Onboarding
Compared to sidecar mode, ambient can make it easier to bring new clusters or workloads into the mesh. Since there’s no need for per-pod injection, teams can onboard services gradually—by namespace, team, or application—without major workload changes. This may help reduce some of the operational tradeoffs noted earlier.
Supports Common Multi-Cluster Topologies
Like sidecar mode, ambient can be used with shared, replicated, or independent control planes. Its infrastructure-level design may reduce the coordination required between clusters in some topologies.
Simplified Trust Configuration
By centralizing identity in the zTunnel, ambient mode can reduce the complexity of setting up trust between clusters—especially in environments with multiple trust domains.
Sidecars and Ambient: Complementary Approaches
It’s important to clarify that ambient mode and sidecars are not designed to run together in the same cluster today—each cluster is configured as either ambient or sidecar-based. However, at the mesh level, organizations can adopt a hybrid model by running some clusters in ambient mode and others with sidecars, depending on the needs of their workloads.
In many cases, a hybrid deployment model may be appropriate. Ambient can be used for services or clusters where operational simplicity is prioritized, while sidecars can remain in place where more advanced mesh capabilities are needed.
Where Ambient May Fit in a Multi-Cluster Strategy
Some environments where ambient mode may be considered include:
- Internal-facing or less critical workloads, where baseline encryption and discovery are sufficient
- Environments with dynamic clusters, such as ephemeral or CI/CD clusters
- Teams or services new to the mesh, where sidecar injection may be a longer-term goal
- VM-heavy clusters, where sidecar deployment may be more operationally challenging
This flexibility allows platform teams to consider ambient as an option when designing mesh expansion across multiple clusters.
Designing for Optionality
Ambient mode introduces new architectural choices for service mesh, especially in multi-cluster environments. Rather than a full replacement for sidecars, ambient offers an additional deployment option—one that may align with specific performance, operational, or scaling goals.
A hybrid model enables organizations to apply the level of mesh capability that fits their services—balancing depth with manageability, and aligning mesh adoption with the realities of distributed systems.
What’s Next
If you’re evaluating service mesh across multiple clusters, ambient may offer a way to adjust the operational model to better fit your architecture and team structure.
In our next post, we’ll explore how ambient mode handles waypoint configurations and upgrades.
Ready to Assess Your Istio Strategy?
Try the advisor now! Get personalized recommendations for your environment:
Tetrate 
