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?

~> **Cluster peering is currently in beta**: Functionality associated with cluster peering is subject to change. You should never use the beta release in secure environments or production scenarios. Features in beta may have performance issues, scaling issues, and limited support. <br/><br/>Cluster peering is not currently available in the HCP Consul offering.

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.
2. Use the peering token to establish peering with a second cluster.
3. Export services between clusters.
4. Create intentions to authorize services for peers.

For detailed instructions on establishing cluster peering connections, refer to [Create and Manage Peering Connections](/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](https://learn.hashicorp.com/tutorials/consul/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               |    &#9989;     |    &#9989;      |
| Shares support queries and service endpoints       |    &#9989;     |    &#9989;      |
| Connects clusters owned by different operators     |    &#10060;    |    &#9989;      |
| Functions without declaring primary datacenter     |    &#10060;    |    &#9989;      |
| Replicates exported services for service discovery |    &#10060;    |    &#9989;      |
| Gossip protocol: Requires LAN gossip only          |    &#10060;    |    &#9989;      |
| Forwards service requests for service discovery    |    &#9989;     |    &#10060;     |
| Shares key/value stores                            |    &#9989;     |    &#10060;     |

## Beta release features and constraints

The cluster peering beta release includes the following features and functionality:

- **Consul v1.14 beta only**: Dynamic traffic control with a service resolver config entry can target failover and redirects to service instances in a peered cluster.
- Consul datacenters that are already federated stay federated. You do not need to migrate WAN federated clusters to cluster peering.
- Mesh gateways for _service to service traffic_ between clusters are available. For more information on configuring mesh gateways across peers, refer to [Service-to-service Traffic Across Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers).
- You can generate peering tokens, establish, list, read, and delete peerings, and manage intentions for peering connections with both the API and the UI.
- You can configure [transparent proxies](/docs/connect/transparent-proxy) for peered services.
- You can use the [`peering` rule for ACL enforcement](/docs/security/acl/acl-rules#peering) of peering APIs.

Not all features and functionality are available in the beta release. In particular, consider the following technical constraints:

- Mesh gateways for _server to server traffic_ are not available.
- Services with node, instance, and check definitions totaling more than 4MB cannot be exported to a peer.
- The `service-splitter` and `service-router` config entry kinds cannot directly target a peer. To split or route traffic to a service instance on a peer, you must supplement your desired dynamic routing definition with a `service-resolver` config entry on the dialing cluster. Refer to [L7 traffic management between peers](/docs/connect/cluster-peering/create-manage-peering#L7-traffic) for more information.
- The `consul intention` CLI command is not supported. To manage intentions that specify services in peered clusters, use [configuration entries](/docs/connect/config-entries/service-intentions).
- Accessing key/value stores across peers is not supported.
- Because non-Enterprise Consul instances are restricted to the `default` namespace, Consul Enterprise instances cannot export services from outside of the `default` namespace to non-Enterprise peers.
- Cross-cluster mesh gateways are supported in `remote` mode only.