Solo Enterprise for Istio

From microservices to agents. One mesh for everything at any scale

Your platform spans clouds, clusters, and now agentic workloads. Solo Enterprise for Istio extends Ambient Mesh to meet all of it — one control plane from microservices to MCP.

Enterprise capabilities

100M+

Pods tested

Sidecars required

Multicluster Peering

Two architectures.
One seamless mesh.

Gateway-routed mTLS peering across VPCs and clouds — no shared secrets. Direct pod-to-pod flat networking within a VPC for minimal latency. Mix both per cluster pair.

No API Server Access

Control planes peer via gateways — no shared K8s secrets.

Sub-100ms Propagation

Even at 100M pod scale across 2,000 clusters.

Resilient By Design

Tolerates peer downtime — no single point of failure.

A technical diagram comparing two Multicluster Mesh Topologies. The top section, Cross-Network, shows Cluster 1 and Cluster 2 communicating via dedicated Gateways with secure, encrypted links. The bottom section, Flat Network (Same VPC), shows Pod-to-Pod communication across Cluster 3, Cluster 4, and Cluster N. In both scenarios, Istio manages secure connections (represented by lock icons) between clusters, ensuring identity-based encryption whether the traffic passes through a gateway or directly between pods in a shared network.

100M Pod Scale Test

Multicluster Peering Docs

Global Service Discovery

One Global service name. Any cluster. Any instance.

Stop hardcoding cluster endpoints. With Solo Enterprise for Istio, every service is reachable from everywhere — automatic routing to the nearest healthy instance.

# From any cluster, any namespace:
curl http://orders.mesh.internal/api/v1/status

# Automatic routing to nearest healthy instance
# across us-east-1, eu-west-1, or ap-south-1

No Gateway Hops

Direct pod-to-pod across clusters.

Automatic Failover

Locality-aware load balancing built-in.

Unified Namespace

One DNS resolves to any cluster endpoint.

A network diagram shows three service pods in the US-EAST-1 region, all of which are part of an "orders" service. These pods connect to a "Global Service DNS" that is accessible through the address orders.mesh.internal. This DNS can be accessed by any pod in any cluster.

See Multi-Cluster in Action

Node-based L7 Observability

HTTP visibility.
Without the overhead.

Get full Layer 7 observability — HTTP methods, paths, response codes, and traces — directly from the node proxy. No waypoints required. No per-service sidecars. Just instant visibility with near-zero performance impact.

Ultra-High Performance

Less than 1% latency overhead with streaming HTTP parsing.

Safety First Design

Written in Rust for memory safety — observes without modifying traffic.

Full L7 Metrics

Request counts, latencies, response codes — all without waypoints.

Explore L7 Observability

Multicluster Peering

See everything.
Across every cluster.

Unified service graph, tracing, and metrics across all your clusters. Understand traffic flows, identify bottlenecks, and troubleshoot issues — all from a single pane of glass.

Real-Time Service Graph

Visualize dependencies and traffic flow across clusters.

Application Metrics Without Sidecars

HTTP metrics, latency, and error rates — no waypoints required.

Distributed Tracing

End-to-end request tracing across cluster boundaries.

SOLO.IO dashboard showing observability graph with two connected clusters, us-east-cluster1 and us-west-cluster2, each containing system and bookinfo namespaces with services like gloo-ingress-https, ext-auth, rate-limit, productpage-v1, and loadgen.

Segments

Your org structure.
Every tenant.
In your mesh.

Segments partition a mesh into logical boundaries that match how your teams actually work. Each segment gets its own domain — so mesh.platform, mesh.alpha, and mesh.bravo resolve independently, even with identical service names.

Team Isolation

Multiple teams with overlapping namespace conventions — each gets its own segment. No renaming, no conflicts.

Multi-Cluster, One Team

One segment spans multiple clusters across regions. Service discovery works across all of them as a single mesh.

Shared Platform Services

Platform team exposes auth, gateway, and monitoring across all segments. Product teams consume without collision.

A technical diagram titled "ONE MESH" showcasing a multi-tenant service mesh architecture. On the left, a Platform cluster provides shared services like Auth, Gateway, and Monitoring (labeled "Shared to all") via the mesh.platform namespace. On the right, two independent teams are shown: Team Alpha, managing Checkout, Catalog, and Cart services across two clusters (US-East and EU-West) in a single segment (mesh.alpha), and Team Bravo, managing Checkout, Billing, and Invoicing in one US-East cluster (mesh.bravo). The bottom caption notes: "Every team owns their segment · Same service names, zero conflicts · Platform services shared to all.

Create Segments Guide

Learn About Segments

Runtime Extensions

Beyond Kubernetes.
Into your entire stack.

Extend your ambient mesh to workloads running anywhere — Amazon ECS containers, virtual machines, or legacy infrastructure. One unified mesh with mTLS security, traffic management, and observability across all your runtimes.

Amazon ECS Integration

Auto-bootstrap ECS tasks with ztunnel sidecars via simple CLI command.

Virtual Machine Support

Deploy ztunnel on any VM to join the mesh with full mTLS encryption.

AWS Lambda & Serverless

Extend mesh policies and observability to serverless functions.

Unified Security & Policies

Same L4 authorization policies work across Kubernetes, ECS, and VMs.

A technical diagram showing the expansion of Ambient Mesh across different computing environments. On the left, a large box represents Kubernetes with existing workloads utilizing mTLS, L4 Auth, and Observability via the Mesh Core. On the right, three smaller boxes show the integration of Amazon ECS (using ztunnel and auto-bootstrap), Serverless platforms like AWS Lambda (using mesh extensions and policies), and Virtual Machines (using ztunnel for full mTLS). The footer emphasizes the unified approach: "One mesh · Every runtime · Same security and policies everywhere."

VM Integration Guide

ECS Integration Guide

SPIRE Integration

Identity you can prove. Not just assert.

Replace Istio's default identity model with SPIRE's hardware-rooted workload attestation. Every mTLS certificate is backed by cryptographic proof — not just a Kubernetes service account.

Node Attestation

SPIRE agent verifies workload identity via kernel-level checks.

Zero Pod Changes

No socket mounts or volumes — ztunnel acts as trusted SPIRE delegate.

Multicluster Ready

Shared root CA across clusters with per-cluster SPIRE agents.

A technical diagram illustrating identity issuance in a Kubernetes node using SPIRE and Istio Ambient Mesh.

The flow shows a SPIRE Agent performing workload attestation for an Ambient Trusted Delegate, which identifies a Workload by its PID. The SPIRE Server (Root CA) verifies the agent and issues a SPIFFE x509 SVID (mTLS certificate). This certificate is then used by the Ambient layer to establish Secure mTLS Connections for the workload.

Read the Blog Post

SPIRE Integration Docs

Agent Mesh

Your mesh just learned
to speak AI.

Deploy agentgateway as a waypoint proxy in Ambient Mesh. Get native MCP and A2A protocol awareness, context-aware security policies, and full agentic observability — all enforced by the mesh so no client can bypass it.

Context-Aware AuthZ

Policies that inspect MCP tool names, A2A agent capabilities, and JWT claims — not just source IPs.

Native Protocol Support

Built-in MCP and A2A awareness — agentgateway understands agentic flows, not just HTTP.

Rust-Powered Performance

Dramatically lower memory and CPU than Envoy — purpose-built in Rust for AI-native workloads.

Mesh-Enforced Security

Ambient mesh ensures all calls to MCP servers route through agentgateway — no bypass possible.

A diagram titled "AMBIENT MESH" illustrating the architecture of an agentic networking system.

At the center is the "agentgateway", identified as a Waypoint Proxy. This gateway acts as a central hub, containing components for MCP, A2A, CEL AuthZ (Authorization), and Telemetry.

The gateway connects several components:

On the left, an A2A / MCP client "Agent" connects into the gateway.

On the right, the gateway connects to two separate MCP Servers: one for "Tools & Data" and another for "APIs & Actions".

At the bottom, a dashed line connects the gateway to an LLM Provider (listing examples like OpenAI and Anthropic).

At the bottom of the image, a caption states: "Mesh enforces: all traffic → agentgateway · no bypass possible."

Context-Aware Security Blog

agentgateway Docs

Ready to see it in action?

Talk to our team about how Solo Enterprise for Istio can transform your platform — or try it yourself with a hands-on workshop.

Get Started

Hands-On Labs

Discover more

Resources to help you succeed with Istio and Ambient Mesh.

BLOG

Latest Insights & Updates

Stay up to date with the latest news, tutorials, and best practices.

Read the Blog

WEBINARS

Expert-Led Sessions

Join live webinars and watch on-demand sessions from Istio experts.

Watch Webinars

LABS

Hands-On Learning

Get hands-on experience with guided labs and workshops.

Read

Two architectures.One seamless mesh.