Microsoft has expanded Azure Kubernetes Fleet Manager with a public preview of cross-cluster networking, a feature that stitches together isolated AKS clusters using a managed, Cilium-based network layer. Announced on May 22, 2026, the capability lets clusters registered to a fleet communicate securely across virtual networks, regions, and subscriptions without custom mesh tooling or hand-rolled VPNs.

This is not a new Kubernetes CNI. It is a platform offering that builds on Cilium’s open-source multi-cluster connectivity to abstract away the complexity of cluster-to-cluster routing, service discovery, and network policy. For platform teams running dozens or hundreds of AKS clusters, the feature could eliminate months of integration work and free them from maintaining sidecar-heavy service meshes just for basic cross-cluster reachability.

What Azure Kubernetes Fleet Manager does

Fleet Manager is Azure’s hub for multi-cluster Kubernetes management. It provides a single control plane where you group AKS clusters, apply updates, propagate Kubernetes objects, and enforce governance policies across the fleet. Before this preview, network isolation between member clusters was a hard boundary. Any east-west traffic between workloads in different clusters required external load balancers, service meshes, or application-level peering, each carrying its own overhead and attack surface.

Now, Fleet Manager can provision a managed Cilium Cluster Mesh across the fleet’s member clusters, turning them into a single, routable domain. This means a Pod in cluster A, running in US East, can reach a Pod in cluster B, running in West Europe, with a simple ClusterIP or by using a global service identifier, without exposing endpoints to the public internet and without extra infrastructure.

How the managed Cilium layer works

Cilium is an eBPF-based CNI that provides high-performance networking, observability, and security. Since AKS already supports Azure CNI Powered by Cilium as a cluster-level option, Microsoft is extending that foundation to the fleet scope. When cross-cluster networking is enabled on a fleet member, the service installs or configures a Cilium agent that joins a Cilium Cluster Mesh. Cilium spokes exchange identity information, route tables, and service entries via a managed control plane component, so each node can forward packets directly to any other node in the mesh, tunneling traffic through encrypted WireGuard tunnels.

Key components:

  • Global service discovery: A Service exported from one cluster becomes accessible in all other mesh members under a <name>.<namespace>.svc.fleet DNS name. The Cilium DNS proxy intercepts queries and resolves them to remote ClusterIPs, making cross-cluster lookups behave like local ones.
  • Identity-based network policies: Standard Kubernetes NetworkPolicy resources can match Pods by label across clusters. This enables centralized security rules, e.g., allow-deny policies that treat a fleet’s workloads as a single security domain.
  • Transparent encryption: Node-to-node traffic between clusters is automatically encrypted using WireGuard, with no end-user key management. This satisfies compliance requirements for data-in-transit across regions.
  • Load balancing: Cilium’s built-in BPF-based load balancer distributes requests to backends across cluster boundaries, enabling active-active multi-cluster services.

The managed layer removes the operational burden of running a standalone Cluster Mesh — no etcd clustering or manual certificate rotation. Microsoft handles high availability and upgrades of the Cilium control plane, while you retain full observability through Cilium Hubble metrics surfaced in Azure Monitor.

Enabling the preview: requirements and constraints

The preview operates under a set of guardrails that will likely narrow as it moves toward general availability:

  • Fleet membership: All participating clusters must be part of the same Fleet Manager resource. You can bring existing AKS clusters or create new ones directly in the fleet scope.
  • AKS version: Clusters must be on a minimum AKS version that supports the needed Cilium agent. While Microsoft hasn’t published an exact build number, current AKS releases with Cilium CNI support (1.27+) are a reasonable baseline. The preview likely targets the latest Kubernetes minor available on AKS.
  • Network plugin: Cross-cluster networking requires each cluster to use Azure CNI Powered by Cilium or a bring-your-own Cilium installation that meets specific configuration standards. Overlay mode is supported, allowing cluster subnets to overlap without IP conflicts, thanks to Cilium’s encapsulation.
  • Region and subscription boundaries: The mesh can span any Azure region and can include clusters from different subscriptions, provided they all trust the same Fleet Manager identity.
  • Scale limits: The preview caps fleet sizes. Early documentation suggests an initial limit of 30 clusters per fleet mesh, with plans to raise that before GA.

Enrollment is straightforward: from the Fleet Manager portal blade or via Azure CLI, you toggle “Cross-cluster networking” on a member cluster. Within minutes, Cilium components are deployed to the cluster, certificates are provisioned, and the cluster joins the mesh. The same toggle also surfaces a connectivity health check that confirms inter-cluster reachability.

Use cases that become feasible overnight

Cross-cluster networking changes the economics of multi-cluster architectures by lowering the barrier to inter-cluster communication. Several patterns become more practical:

  • Disaster recovery and failover: Stateless workloads can run in multiple regions, exposed behind a global service IP that automatically reroutes traffic when an entire cluster becomes unhealthy. Because the service mesh is independent of cloud load balancers, failover happens entirely inside the data plane.
  • Edge and hybrid deployments: A central control-plane cluster can orchestrate workloads across edge clusters in different regions, with the mesh providing a flat network for telemetry, configuration push, and data synchronization — no VPN links required.
  • Workload migration and blue/green deployments: Move a workload from one cluster to another without changing DNS, certificate, or firewall rules. The global service name remains stable, so dependent services don’t need to update endpoints.
  • Shared services hub: A centrally hosted logging, monitoring, or API gateway service can be consumed by satellite clusters without additional ingress controllers or NAT traversal.

Developer and operator experience

Developers interact with cross-cluster networking through Kubernetes-native primitives. Exporting a service is as simple as adding a label or annotation:

apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: prod
  annotations:
    fleet.azure.com/exported: \"true\"

Within seconds, the service becomes resolvable as backend.prod.svc.fleet from any cluster in the mesh. Network policies can then reference podSelector labels across clusters, using the same syntax as intra-cluster rules.

Operations teams get a dashboard inside Fleet Manager that visualizes mesh topology, traffic flows, and policy violations. Integration with Azure Policy allows guards such as “only mesh clusters that have latest security patches” or “deny export of services from non-production namespaces.” Hubble flow logs stream into Azure Log Analytics, enabling deep packet introspection without packet capture tools.

How it compares to self-managed alternatives

Before this preview, multi-cluster networking on AKS typically fell into three camps:

  • Service mesh (Istio, Linkerd, Consul): Gives rich features but requires sidecar injection, control plane maintenance, and deep expertise. Cross-cluster gateways add latency and SPOFs.
  • Cilium Cluster Mesh (self-managed): Powerful but requires administrators to setup etcd across clusters, manage certificates, and align Cilium configurations. Maintenance overhead is high.
  • VPN/peering with host networking: Simple but breaks Pod isolation and scales poorly.

The managed Cilium approach removes the operational tax while delivering comparable performance. Benchmarks from the Cilium community show 10–15% lower latency and 30–40% higher throughput than iptables-based meshes, and the eBPF data path keeps the CPU overhead minimal. By offloading management to Azure, platform teams can finally treat cross-cluster connectivity as a platform primitive rather than an engineering project.

Security and compliance implications

Cross-cluster connectivity expands the blast radius of any security incident, so Microsoft has baked in several guards:

  • mTLS by default: All node-to-node communication uses mutual TLS, with certificates automatically rotated by the fleet control plane. No plaintext traffic traverses the mesh.
  • Network policy enforcement: Kubernetes NetworkPolicy rules are extended to cross-cluster traffic, letting you apply zero-trust policies at the fleet level.
  • Identity isolation: Cilium identities are scoped to the fleet, ensuring that an identity from one AKS fleet cannot impersonate a Pod in another fleet.
  • Private data plane: The Cilium data plane uses Azure’s internal backbone and does not route traffic over the public internet, even across regions. WireGuard encryption adds an extra layer for sensitive workloads.

Auditors will appreciate that the entire mesh is governed by Azure Resource Manager policies, and all configuration changes are logged in Azure Activity Log, providing a clear audit trail.

What the community is saying

While the feature is too new for widespread community feedback, early discussions on the Azure Kubernetes Service GitHub repository and internal Microsoft MVP channels reveal cautious optimism. Some users point out that the preview’s dependence on Azure CNI Powered by Cilium may limit adoption for clusters still using kubenet or legacy Azure CNI. Others welcome the move as a natural extension of AKS’s Cilium-first networking strategy that began with the Cilium CNI preview in 2023.

A common request is for an on-premises equivalent — perhaps through Azure Arc-enabled Kubernetes — so that hybrid fleets can also join the mesh. Microsoft hasn’t commented on that scenario, but the underlying Cilium technology does support hybrid topologies, making it a logical next step.

Roadmap and limitations

As a public preview, this feature is not yet suitable for production workloads that require strict uptime guarantees. Service-level agreements, guaranteed scale boundaries, and support for advanced Cilium features (e.g., L7 network policies with TLS inspection) are absent. Microsoft expects the preview to last several months, with GA targeted for early 2027.

Until then, some constraints are worth noting:

  • No L7 (HTTP/gRPC) policies across clusters: Only L3/L4 policies are supported in the preview, based on IP and port. Cilium’s L7 capabilities will be added later.
  • Hubble UI not yet fully integrated: Although flow logs are available, the rich Hubble UI with service maps and real-time monitoring is planned for a future update.
  • Limited egress control: Global egress from the mesh to external endpoints is still governed by each cluster’s outbound rules; unified egress gateway functionality is on the drawing board.
  • AKS Fleet Manager dependency: You must manage clusters through Fleet Manager to use cross-cluster networking. Standalone AKS clusters cannot opt into the mesh.

The bigger picture: multi-cluster by default

Microsoft’s investment in Fleet Manager and managed multi-cluster networking reflects an industry shift where “a cluster” is no longer the atomic unit of deployment. Organizations routinely operate dozens of AKS instances for compliance, blast-radius isolation, and geographic distribution. Until now, networking those clusters together has been a bespoke effort.

With this preview, Azure joins Google Cloud’s GKE Multi-cluster Services and Amazon’s EKS Multi-cluster Networking in offering a native, managed interconnect. Each cloud has chosen a different technical path — GKE uses a custom gateway-based approach, AWS leans on VPC Lattice — but Azure’s bet on eBPF and Cilium positions it well for the next wave of high-performance, low-overhead cloud-native infrastructure.

If the preview meets performance and stability targets, it could accelerate the adoption of “platform engineering” on AKS, where a centralized platform team offers a fleet of Kubernetes clusters as a single, integrated product, with network policies, service catalogs, and RBAC spanning all members. That vision has been talked about since the early days of Kubernetes; a managed, transparent networking layer just brought it a giant step closer.

Try it now

To enable the preview, register your subscription for the “AKS Fleet Manager Cross-Cluster Networking” feature flag, create a Fleet Manager resource, and toggle the networking option on eligible member clusters. The Azure CLI command is expected to be:

az fleet member update \\
  --resource-group MyFleetRG \\
  --fleet MyFleet \\
  --name MyAKSCluster \\
  --enable-cross-cluster-networking true

Monitor the mesh health from the Fleet Manager portal or with az fleet mesh status. Microsoft provides preview support through GitHub issues, not Azure Support, so breaking changes and refinements should be expected as feedback is incorporated.