open-consul/website/content/docs/connect/cluster-peering/index.mdx

---
layout: docs
page_title: Service Mesh - What is Cluster Peering?
description: >-
  Cluster peering establishes communication between independent clusters in Consul, allowing services to interact across datacenters. Learn about the cluster peering process, differences with WAN federation for multi-datacenter deployments, and technical constraints.  
---

# What is Cluster Peering?

You can create peering connections between two or more independent clusters so that services deployed to different partitions or datacenters can communicate.

## Overview

Cluster peering is a process that allows Consul clusters to communicate with each other. The cluster peering process consists of the following steps:

1. Create a peering token in one cluster.
1. Use the peering token to establish peering with a second cluster.
1. Export services between clusters.
1. Create intentions to authorize services for peers.

This process establishes cluster peering between two [admin partitions](/consul/docs/enterprise/admin-partitions). Deployments without an Enterprise license can still use cluster peering because every datacenter automatically includes a `default` partition.

For detailed instructions on establishing cluster peering connections, refer to [Create and Manage Peering Connections](/consul/docs/connect/cluster-peering/create-manage-peering).

> To learn how to peer clusters and connect services across peers in AWS Elastic Kubernetes Service (EKS) environments, complete the [Consul Cluster Peering on Kubernetes tutorial](/consul/tutorials/developer-mesh/cluster-peering-aws?utm_source=docs).

### Differences between WAN federation and cluster peering

WAN federation and cluster peering are different ways to connect Consul deployments. WAN federation connects multiple datacenters to make them function as if they were a single cluster, while cluster peering treats each datacenter as a separate cluster. As a result, WAN federation requires a primary datacenter to maintain and replicate global states such as ACLs and configuration entries, but cluster peering does not.

Regardless of whether you connect your clusters through WAN federation or cluster peering, human and machine users can use either method to discover services in other clusters or dial them through the service mesh.

|                                                    | WAN Federation | Cluster Peering |
| :------------------------------------------------- | :------------: | :-------------: |
| Connects clusters across datacenters               |    ✅     |    ✅      |
| Shares support queries and service endpoints       |    ✅     |    ✅      |
| Connects clusters owned by different operators     |    ❌    |    ✅      |
| Functions without declaring primary datacenter     |    ❌    |    ✅      |
| Replicates exported services for service discovery |    ❌    |    ✅      |
| Gossip protocol: Requires LAN gossip only          |    ❌    |    ✅      |
| Forwards service requests for service discovery    |    ✅     |    ❌     |
| Shares key/value stores                            |    ✅     |    ❌     |
| Can replicate ACL tokens, policies, and roles      |    ✅     |    ❌     |

## Important Cluster Peering Constraints

Consider the following technical constraints:

- Services with node, instance, and check definitions totaling more than 8MB cannot be exported to a peer.
- Two admin partitions in the same datacenter cannot be peered. Use [`exported-services`](/consul/docs/connect/config-entries/exported-services#exporting-services-to-peered-clusters) directly.
- The `consul intention` CLI command is not supported. To manage intentions that specify services in peered clusters, use [configuration entries](/consul/docs/connect/config-entries/service-intentions).
- Accessing key/value stores across peers is not supported.