Network topologies

This page explains the supported network topologies for establishing cluster peering connections in HCP Consul. The location of services across clusters, HashiCorp Virtual Networks, and cloud providers affect the network connectivity requirements, which are determined by the cluster tier you select when deploying a HashiCorp-managed cluster.

Peer HCP-managed clusters on same HVN

If you have two HCP-managed clusters on the same HVN, they already share network connectivity. As a result, you can establish cluster peering between the clusters.

This diagram describes the cluster peering topology for HCP-managed standard tier clusters deployed in a single HVN.

Peer HCP-managed clusters on different HVNs

If you have HCP-managed clusters deployed on two different HVNs, the HVNs will be automatically peered when establishing a cluster peering connection.

If the HVNs are in different regions, both cluster tiers must be Plus or higher. In non-production settings, you can also use development tier clusters to evaluate and test multi-region cluster peering connections.

This diagram describes the cluster peering topology for HCP-managed plus tier clusters deployed on AWS in two HVNs in different regions.

Peer HCP-managed clusters and self-managed clusters (single-cloud)

If you have an HCP-managed cluster and a self-managed cluster deployed on the same cloud provide, you must peer the HVN and the cloud network (VPC or VNet) before you can establish cluster peering connections. Refer to HCP AWS peering connections or HCP Azure peering connections to learn how to peer the HVN.

If the HVN and your cloud network are in the same region, both cluster tiers must be Standard or higher. If the HVN and your cloud network are in different regions, both cluster tiers must be Plus or higher.

This diagram describes the cluster peering topology for HCP-managed and self-managed plus tier clusters deployed on AWS in two different regions.

Peer Consul clusters on different clouds (multi-cloud)

There are two ways to peer HCP-managed and self-managed clusters on AWS and Azure.

• Peer Consul clusters through public IPs. This method is best for networks that require public access.
• Peer Consul clusters through mesh gateways. This method is the most secure method for production environments.

Because the Consul clusters are deployed in different clouds, both cluster tiers must be Premium. In non-production settings, you can also use development tier clusters to evaluate and test multi-cloud cluster peering connections.

Peer Consul clusters through public IP

If you have two publicly accessible Consul clusters deployed in AWS and Azure, you can establish a cluster peering connection between the clusters using their public IPs. This option is best suited for connecting two development tier clusters to evaluate cluster peering with HCP clusters. You can also secure your clusters with IP allowlist to limit connections between the peered clusters according to IP CIDRs.

When you create a cluster peering connection using HCP Consul's management plane, you have the option to include one or more server addresses. This address is the public IP where the server is available. This field auto-populates for public clusters.

When using self-managed clusters, an alternative option is to expose the cluster to the outside network through external load balancers. Then, you can use the loadbalancer's DNS or IP address when creating a peering token. Refer to the ServerExternalAddresses documentation for more information.

This diagram describes the cluster peering topology for two HCP-managed premium tier clusters deployed to separate HVNs on AWS and Azure, with a public IP connection between the two.

Peer Consul clusters through mesh gateways

If you have Consul clusters deployed separately in AWS and Azure that you want to connect without exposing them to the public network, establish a cluster peering connection through mesh gateways deployed to each environment. This method supports connections between two HCP-managed clusters in different clouds, connections between HCP-managed and self-managed clusters, and connections between two self-managed clusters. Mesh gateways must be deployed to the default partition in both workload environments.

To use cluster peering through mesh gateways, you must first peer the HVNs and your cloud networks. Refer to HCP AWS peering connections or HCP Azure peering connections to learn how to peer the HVN.

This diagram describes the cluster peering topology for two HCP-managed premium tier clusters deployed to separate HVNs on AWS and Azure that are connected between mesh gateways. Each mesh gateway is deployed to the default partition in the VPC or VNet that has an established connection to the HVN.

If you use Consul on Kubernetes, you must enable peerThroughMeshGateways in the Mesh CRD and set the mode to local in the ProxyDefaults CRD. Refer to the following configuration examples:

apiVersion: consul.hashicorp.com/v1alpha1
kind: Mesh
metadata:
  name: mesh
spec:
  peering:
    peerThroughMeshGateways: true

apiVersion: consul.hashicorp.com/v1alpha1
kind: ProxyDefaults
metadata:
  name: global
  namespace: consul
spec:
  config:
    protocol: http
  expose: {}
    meshGateway:
      mode: local

Refer to mesh gateway configuration for Kubernetes for more information.