# Manage Private Networking for Cluster Linking on Confluent Cloud The following sections describe supported cluster combinations, commands, configurations, use cases, and walkthroughs for private networking on Confluent Cloud. ## Supported cluster combinations Cluster Linking is fundamentally a networking feature: it copies data over the network. As such, Cluster Linking requires that at least one of the clusters involved has connectivity to the other cluster. The networking parameters of each cluster determines whether the two clusters can be linked, and whether the destination cluster or the source cluster must initiate the connection. By default, the destination cluster initiates the connection. A special mode called “source-initiated links” allows the source cluster to initiate the connection of the cluster link. Submit source and destination cluster types in the compatibility checkers below to quickly determine if a given combination is supported, or consult the detailed tables that follow for more guidance. ### Confluent Cloud source and destination clusters Use the combos checker wizard or the table below to determine supported Cluster Linking combinations across Confluent Cloud clusters. #### Confluent Cloud combinations (wizard)
Confluent Cloud Clusters Compatibility Checker

Cloud providers Amazon Web Services (AWS), Microsoft Azure, and Google Cloud are all supported. See also, supported regions for each Cloud provider.

Select cluster types and click "Check Compatibility" to see the result.
#### Confluent Cloud combinations (table) | Source cluster | Destination cluster | Possible? | Notes | |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | [Basic](../../clusters/cluster-types.md#basic-cluster), [Standard](../../clusters/cluster-types.md#standard-cluster),
or [Dedicated](../../clusters/cluster-types.md#dedicated-cluster) with secure public endpoints [1](#f1) | Any Enterprise cluster with private networking, or Dedicated cluster | Yes | - Source and destination clusters can be on the same or different cloud providers
- Source and destination clusters can be on the same or different Confluent Cloud Organization | | Public Dedicated cluster on any supported cloud provider | Public Dedicated cluster on any supported cloud provider | Yes | - Source and destination clusters can be on the same or different cloud providers
- Source and destination clusters can be on the same or different Confluent Cloud Organization | | Public Dedicated cluster on any supported cloud provider | Private Dedicated cluster on any supported cloud provider | Yes | - Using destination-initiated, source-initiated, or bidirectional links
- Source and destination clusters can be on the same or different Confluent Cloud Organization | | Privately networked [Enterprise](../../clusters/cluster-types.md#enterprise-cluster) cluster on any supported cloud provider [1](#f1) | Public Dedicated cluster on any supported cloud provider | Yes | - Must use a source-initiated link as described in [Private to public Cluster Linking](#cluster-linking-private-to-public)
- Source and destination clusters can be on the same or different Confluent Cloud Organization | | Public Dedicated cluster on any supported cloud provider [1](#f1) | Privately networked Enterprise cluster on any supported cloud provider | Yes | - Source and destination clusters can be on the same or different Confluent Cloud Organization | | Enterprise cluster with AWS, Azure, or Google Cloud private networking [2](#f2) [3](#f3) [4](#f4) [6](#f6) | Enterprise cluster with AWS, Azure, or Google Cloud private networking | Yes | - Clusters must be in the same Confluent Cloud Organization | | Enterprise cluster with AWS, Azure, or Google Cloud private networking [2](#f2) [3](#f3) [4](#f4) [6](#f6) | Dedicated cluster with AWS, Azure, or Google Cloud private networking | Yes | - Clusters must be in the same Confluent Cloud Organization | | Dedicated cluster with AWS, Azure, or Google Cloud private networking [2](#f2) [3](#f3) [4](#f4) [6](#f6) | Enterprise cluster with AWS, Azure, or Google Cloud private networking | Yes | - Clusters must be in the same Confluent Cloud Organization | | Dedicated cluster with AWS, Azure, or Google Cloud private networking [2](#f2) [3](#f3) [4](#f4) [6](#f6) | Dedicated cluster with AWS, Azure, or Google Cloud private networking | Yes | - Clusters must be in the same Confluent Cloud Organization | | Dedicated cluster with private networking | Dedicated cluster with public networking | Yes | - Must use a source-initiated link as described in [Private to public Cluster Linking](#cluster-linking-private-to-public)
- Not available to create in Confluent Cloud Console
- Source and destination clusters can be on the same or different Confluent Cloud Organization
- Dedicated clusters with Transit Gateway networking is only available/applicable on AWS | | Any Kafka cluster on AWS, Azure, or Google Cloud with public or private networking or Freight [7](#f7) on AWS with private
networking. | [Freight](../../clusters/cluster-types.md#freight-cluster) cluster on AWS with private networking | Yes | - If the source cluster is private, it must be in the same Confluent Cloud organization as the destination.
- Dedicated clusters with Transit Gateway networking is only available/applicable on AWS | | [Basic](../../clusters/cluster-types.md#basic-cluster), [Standard](../../clusters/cluster-types.md#standard-cluster) cluster | Basic or Standard cluster | No | - Cluster Linking to a Basic or Standard cluster as a destination is **not supported**. | | (Legacy) Dedicated cluster with AWS Transit Gateway networking [5](#f5) | (Legacy) Dedicated cluster with AWS Transit Gateway networking | Yes | - Requires proper [Transit Gateway configuration](#cluster-linking-aws-tgw)
- Neither cluster can use the CIDR 198.18.0.0/15
- Clusters must be in the same Confluent Cloud Organization
- Dedicated clusters with Transit Gateway networking is only available/applicable on AWS | * **[1]** Basic, Standard, Dedicated, and Enterprise cluster types are described in [Supported cluster types](index.md#cloud-cluster-linking-supported-types). Enterprise clusters are always privately networked. Bidirectional links on Enterprise clusters do not work when both clusters are in the same region (these are supported for cross-region only). Basic and Standard clusters can be source of destination initiated links, but cannot be used as the source of source-initiated links. * **[2]** Currently available in a subset of Azure regions only, as described in [Supported Azure Regions](#cluster-link-private-network-azure-regions). * **[3]** Currently available in these AWS regions only, as described in [Supported AWS Regions](#cluster-link-private-network-aws-regions). * **[4]** Currently available in a subset of Google Cloud regions only, as described in [Supported Google Cloud Regions](#cluster-link-private-network-google-cloud-regions). * **[5]** [Classless Inter-Domain Routing (CIDR)](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) is explained in the AWS documentation. * **[6]** Supported Private networking configurations for Cluster Linking can be found in: [Azure Networking Overview on Confluent Cloud](../../networking/azure-overview.md#cloud-networking-azure-overview), [AWS Networking Overview on Confluent Cloud](../../networking/aws-overview.md#cloud-networking-aws-overview), and [Google Cloud Networking Overview on Confluent Cloud](../../networking/gcp-overview.md#cloud-networking-gc-overview). * **[7]** Freight clusters are only supported as a source or destination for Cluster Linking on AWS in private networks (not public). #### NOTE - When using the [Confluent Cloud Console to create cluster links](#cloud-cluster-link-how-to-use-for-private-networking), you will see only linkable clusters in the drop-down options. Clusters that cannot be linked are filtered out. - To learn more about all available Confluent Cloud cluster types, see [Kafka Cluster Types in Confluent Cloud](../../clusters/cluster-types.md#cloud-cluster-types). The above table shows supported cluster types for this particular Cluster Linking scenario (private networking). For a more general overview of supported cluster types for Cluster Linking, see [Supported cluster types](index.md#cloud-cluster-linking-supported-types). - Cluster Linking across Basic or Standard clusters as a destination is not supported. ### Confluent Platform and Confluent Cloud Use the combos checker wizard or the table below to determine supported Cluster Linking combinations across Confluent Platform and Confluent Cloud. #### Confluent Platform and Confluent Cloud combinations (wizard)
Confluent Platform & Confluent Cloud Compatibility Checker

Choose one each of Confluent Platform and Confluent Cloud cluster types for source and destination on either side of the link. Confluent Cloud supported cluster types are Dedicated, Enterprise, and Freight. Cloud providers Amazon Web Services (AWS), Microsoft Azure, and Google Cloud are all supported, execept where otherwise noted. See also, supported regions for each Cloud provider.

Select cluster types and click "Check Compatibility" to see the result.
#### Confluent Platform and Confluent Cloud combinations (table) | Source cluster | Destination cluster | Possible? | Notes | |--------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Confluent Platform 7.1.0 or later | Confluent Cloud - Any Enterprise cluster with private networking, Freight
cluster on AWS with private networking, or Dedicated cluster | Yes | - Must use a source-initiated link
- Source Confluent Platform cluster must have connectivity to the
destination cluster
- Brokers must be Confluent Server | | Confluent Platform 5.4+ with public endpoints on all brokers | Confluent Cloud - Any Enterprise cluster with private networking, Freight
cluster on AWS with private networking or Dedicated cluster | Yes | - For AWS only. If egress static IP addresses are used, a
firewall in front of Confluent Platform can filter on those IP addresses
- Cluster link must use SASL/PLAIN, SASL/SCRAM, and/or
[mTLS](security-cloud.md#cloud-cluster-linking-mtls) | | Confluent Platform 5.4+ without public endpoints | Confluent Cloud - A privately networked Enterprise or Freight cluster
(AWS only if Freight), or Dedicated cluster
with VPC Peering, VNet Peering, or Transit Gateway | Yes | - Destination Confluent Cloud cluster must have connectivity to
the source Confluent Cloud cluster
- Cluster link must use SASL/PLAIN, SASL/SCRAM, and/or
[mTLS](security-cloud.md#cloud-cluster-linking-mtls)
- Your cloud networking must be configured to allow the
Confluent Cloud cluster to reach the brokers on the source cluster | | Confluent Cloud - A Basic or Standard cluster, or a
Dedicated cluster with secure public endpoints | Confluent Platform 7.0.0 or later | Yes | | | Confluent Cloud - A cluster with private networking | Confluent Platform 7.0.0 or later | Yes | - Destination Confluent Platform cluster must have connectivity to
the source Confluent Cloud cluster | For details on Confluent Platform only supported combinations, see [Supported platform and tools compatibilities](/platform/current/multi-dc-deployments/cluster-linking/index.html#supported-platform-and-tools-compatibilities) ### Confluent Cloud and Kafka The following combinations are supported for private networking with Confluent Cloud and Apache Kafka®. | Source cluster | Destination cluster | Possible? | Notes | |-----------------------------------------------------------|------------------------------------------------------------------------------------------------|-------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Kafka 2.4 or later with public endpoints on all brokers | Confluent Cloud - Any Dedicated or Enterprise cluster | Yes | - If egress static IP addresses are used, a
firewall in front of Confluent Platform can filter on those IP addresses
- Cluster link must use SASL/PLAIN, SASL/SCRAM, and/or
[mTLS](security-cloud.md#cloud-cluster-linking-mtls) | | Kafka 2.4 or later without public endpoints | Confluent Cloud - Any Dedicated cluster with
VPC Peering, VNet Peering, or Transit Gateway | Yes | - Destination Confluent Cloud cluster must have connectivity to
the source Kafka cluster
- Cluster link must use SASL/PLAIN, SASL/SCRAM, and/or
[mTLS](security-cloud.md#cloud-cluster-linking-mtls)
- Your cloud networking must be configured to allow the
Confluent Cloud cluster to reach the brokers on the source cluster | | Kafka 2.4 or later in an AWS VPC (including MSK clusters) | Confluent Cloud - Any Enterprise cluster | Yes | - External Cluster Linking over PrivateLink is supported using AWS.
Azure is not currently supported for this workflow.
To learn more, see [Link external clusters to Confluent Cloud over a private network](#cloud-link-external-clusters-on-private-networking). | ### Limitations and Summary The matrices of supported and non-supported cluster combinations above are a bit complex. To simplify at a high level, keep in mind these more generalized, shorthand tips. The following cluster combinations are **supported** for cross-cloud scenarios; that is, clusters can be in different cloud providers: - Any public cluster can connect to private networking. - “Public to Public” using destination-initiated, source-initiated, or bidirectional links is supported across organizations and cloud providers. - “Public to Private” using destination-initiated, source-initiated, or bidirectional links is supported across organizations and cloud providers. - “Private to Public” using source-initiated or bidirectional links is supported across organizations and cloud providers. (This is not supported with destination-initiated links.) - “Private to Private” clusters across cloud providers Azure, AWS, and Google Cloud are supported. It is **not** supported across organizations. Conversely, the following combinations are **not supported** for cross-cloud scenarios: - “Private to Public” with destination-initiated links is not supported across organizations or cloud providers. This is only supported with source-initiated links. ## Diagrams of supported combinations for private networking ### Confluent Cloud to Confluent Cloud ![image](images/cluster-link-private-net-cloud-to-cloud.png) ### Confluent Cloud to Confluent Platform/Kafka ![image](images/cluster-link-private-net-cloud-to-cp-kafka.png) ## Supported regions - [AWS](#cluster-link-private-network-aws-regions) - [Azure](#cluster-link-private-network-azure-regions) - [Google Cloud](#cluster-link-private-network-google-cloud-regions) ### Supported AWS Regions The following [AWS regions](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions) are supported in the current release. #### The Americas and Canada | Code | Region | |--------------|---------------------------| | ca-central-1 | Canada (Central) | | ca-west-1 | Canada (West) | | us-west-2 | US West (Oregon) | | us-east-1 | US East (N. Virginia) | | us-east-2 | US East (Ohio) | | sa-east-1 | South America (São Paulo) | #### Europe | Code | Region | |--------------|--------------------| | eu-north-1 | Europe (Stockholm) | | eu-south-1 | Europe (Milan) | | eu-south-2 | Europe (Spain) | | eu-central-1 | Europe (Frankfurt) | | eu-central-2 | Europe (Zurich) | | eu-west-1 | Europe (Ireland) | | eu-west-2 | Europe (London) | | eu-west-3 | Europe (Paris) | #### Middle East | Code | Region | |--------------|-----------------------| | me-central-1 | Middle East (UAE) | | me-south-1 | Middle East (Bahrain) | | il-central-1 | Israel (Tel Aviv) | #### Africa | Code | Region | |------------|--------------------| | af-south-1 | Africa (Cape Town) | #### Asia Pacific | Code | Region | |----------------|--------------------------| | ap-south-1 | Asia Pacific (Mumbai) | | ap-south-2 | Asia Pacific (Hyderabad) | | ap-east-1 | Asia Pacific (Hong Kong) | | ap-northeast-1 | Asia Pacific (Tokyo) | | ap-northeast-2 | Asia Pacific (Seoul) | | ap-northeast-3 | Asia Pacific (Osaka) | | ap-southeast-1 | Asia Pacific (Singapore) | | ap-southeast-2 | Asia Pacific (Sydney) | | ap-southeast-3 | Asia Pacific (Jakarta) | | ap-southeast-4 | Asia Pacific (Melbourne) | | ap-southeast-7 | Asia Pacific (Bangkok) | ### Supported Azure Regions The following [Azure regions](https://learn.microsoft.com/en-us/azure/reliability/regions-list) are supported in the current release. #### The Americas and Canada | Code | Region | |----------------|----------------------------| | canadacentral | Canada (Central) | | eastus | United States (Virginia) | | eastus2 | United States (Virginia) | | centralus | United States (Iowa) | | southcentralus | United States (Texas) | | westus2 | United States (Washington) | | westus3 | United States (Phoenix) | | mexicocentral | Mexico (Central) | | brazilsouth | Brazil (São Paulo State) | #### Europe and Scandinavia | Code | Region | |--------------------|-------------------------| | austriaeast | Austria (Vienna) | | uksouth | United Kingdom (London) | | germanywestcentral | Germany (Frankfurt) | | francecentral | France (Paris) | | italynorth | Italy (Milan) | | spaincentral | Spain (Madrid) | | westeurope | Europe (Netherlands) | | northeurope | Europe (Ireland) | | switzerlandnorth | Switzerland (Zurich) | | norwayeast | Norway (Oslo) | | swedencentral | Sweden (Gävle) | #### Middle East, Asia Pacific, and Africa | Code | Region | |------------------|------------------------------| | uaenorth | United Arab Emirates (Dubai) | | japaneast | Japan (Tokyo) | | southeastasia | Asia Pacific (Singapore) | | eastasia | Asia Pacific (Hong Kong) | | southafricanorth | South Africa (Johannesburg) | | centralindia | India (Pune) | | australiaeast | Australia (New South Wales) | ### Supported Google Cloud Regions The following [Google Cloud regions](https://cloud.google.com/about/locations#regions) are currently supported. #### The Americas and Canada | Code | Region | |-------------------------|--------------------------------------| | us-central1 | Iowa (United States) | | us-east1 | South Carolina (United States) | | us-east4 | Northern Virginia (United States) | | us-west1 | Oregon (United States) | | us-west2 | Los Angeles (United States) | | us-west3 | Salt Lake City, Utah (United States) | | us-west4 | Las Vegas, Nevada (United States) | | us-south1 | Dallas (Texas) (United States) | | northamerica-northeast1 | Montreal (Canada) | | northamerica-northeast2 | Toronto (Canada) | | southamerica-east1 | São Paulo (Brazil) | | southamerica-west1 | Santiago (Chile) | #### Europe and Scandinavia | Code | Region | |-------------------|----------------------| | europe-west1 | Belgium (Europe) | | europe-west2 | London (Europe) | | europe-west3 | Frankfurt (Germany) | | europe-west4 | Netherlands (Europe) | | europe-west6 | Zurich (Switzerland) | | europe-west8 | Milan (Italy) | | europe-west9 | Paris (France) | | europe-west12 | Turin (Italy) | | europe-north1 | Finland (Finland) | | europe-central2 | Warsaw (Poland) | | europe-southwest1 | Madrid (Spain) | #### Middle East and Asia Pacific | Code | Region | |----------------------|--------------------------| | me-central1 | Doha (Qatar) | | me-central2 | Dammam (Saudi Arabia) | | me-west1 | Tel Aviv (Israel) | | asia-east1 | Hong Kong (Asia Pacific) | | asia-east2 | Hong Kong (Asia Pacific) | | asia-northeast1 | Tokyo (Japan) | | asia-northeast2 | Osaka (Japan) | | asia-northeast3 | Seoul (Korea) | | asia-south1 | Mumbai (India) | | asia-south2 | Delhi (India) | | asia-southeast1 | Singapore (Asia Pacific) | | asia-southeast2 | Jakarta (Indonesia) | | australia-southeast1 | Sydney (Australia) | | australia-southeast2 | Melbourne (Australia) | ## How to use cluster links with private networking ### Using the Confluent Cloud Console for Cluster Linking with private networking To view, create, and modify cluster links and mirror topics in the Confluent Cloud Console, the cluster link’s destination cluster must be accessible from your browser. If your destination cluster is a Confluent Cloud cluster with private networking, you must have completed the setup described in [Use the Confluent Cloud Console with Private Networking](../../networking/ccloud-console-access.md#ccloud-console-access-networking). If your browser cannot access the destination cluster, you will not see any cluster links on that cluster, nor an indication of which topics are mirror topics. You will not be able to create a cluster link with that cluster as its destination cluster. If your source cluster is also a Confluent Cloud cluster with private networking, then some features of the Confluent Cloud Console require your browser to be able to reach your source cluster, also: - Creating a “Confluent Cloud to Confluent Cloud” cluster link as an OrganizationAdmin, which creates ACLs and an API key on the source cluster. - Viewing the source cluster topics’ throughput metric on a cluster link - Using the drop-down menu of source cluster topic names to create a mirror topic. Topic names must be entered manually. When creating a cluster link in the Confluent Cloud Console, rest assured that the drop-down menus automatically filter for source clusters and destination clusters that can be linked. If you see a drop-down option for the cluster, then a cluster link is possible and generally available. Preview cases are excluded from the drop-downs, and require using the [Confluent CLI](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/link/) or the [Confluent Cloud REST API](https://docs.confluent.io/cloud/current/api.html) to create a cluster link. ### Running Cluster Linking API and CLI commands with private networking Cluster Linking commands require that the location where you are running them has access to the destination cluster of the cluster link: - Creating, updating, listing, describing, and deleting cluster links - Creating, listing, and describing mirror topics For example, when running the Confluent CLI command, the shell must have access to the destination cluster. If your destination cluster has private networking, one way to achieve this is to SSH into a virtual machine that has network connectivity (by means of Private Link, Transit Gateway, or Peering) to the destination cluster. ### Managing cluster links with private networking Aside from the above mentioned requirements, the user experience when using a cluster link with private networking is the same as when using a cluster link with public networking. The same commands work in the same ways. That means you can follow the same Cluster Linking tutorials using the same steps, regardless of whether your clusters use public or private networking. **Exception:** When Cluster Linking from a cluster with private networking to a cluster with public networking, a source-initiated link is required. This introduces different configurations and an extra step. ### Cluster Linking between Confluent Cloud clusters using Azure, AWS, or Google Cloud private networking Cluster Linking over private networking is supported within a single cloud (AWS to AWS, Azure to Azure, or Google Cloud to Google Cloud) or across cloud providers (AWS to Azure or vice versa, Google Cloud to AWS or vice versa, Google Cloud to Azure or vice versa) and works across all private networking options supported by your source and destination clusters. #### Requirements To implement Azure, AWS, or Google Cloud private networking on Confluent Cloud, you must have an active Confluent Cloud organization containing: - One or more users with these RBAC roles: - OrganizationAdmin, or - EnvironmentAdmin, or - CloudClusterAdmin - Two clusters with Azure, AWS, or Google Cloud private networking; these can be [Dedicated](../../clusters/cluster-types.md#dedicated-cluster) or [Enterprise](../../clusters/cluster-types.md#enterprise-cluster) Confluent Cloud clusters on either cloud provider. For more information, see [Azure Networking Overview on Confluent Cloud](../../networking/azure-overview.md#cloud-networking-azure-overview), [AWS Networking Overview on Confluent Cloud](../../networking/aws-overview.md#cloud-networking-aws-overview), or [Google Cloud Networking Overview on Confluent Cloud](../../networking/gcp-overview.md#cloud-networking-gc-overview). - Connectivity to your privately networked clusters via Confluent Cloud Console, REST API, the Confluent CLI, and/or Terraform #### Limitations - Dedicated and Enterprise clusters with Azure private networking is supported, but currently only in a subset of regions, as described in [Supported Azure Regions](#cluster-link-private-network-azure-regions). - Supported private networking options for Azure are described in [Azure Networking Overview on Confluent Cloud](../../networking/azure-overview.md#cloud-networking-azure-overview). - Dedicated and Enterprise clusters with AWS private networking is supported, but currently only in a subset of regions, as described in [Supported AWS Regions](#cluster-link-private-network-aws-regions). - Supported private networking options for AWS are described in [AWS Networking Overview on Confluent Cloud](../../networking/aws-overview.md#cloud-networking-aws-overview). - Dedicated and Enterprise clusters with Google Cloud private networking is supported, but currently only in a subset of regions, as described in [Supported Google Cloud Regions](#cluster-link-private-network-google-cloud-regions). - Supported private networking options for Google Cloud are described in [Google Cloud Networking Overview on Confluent Cloud](../../networking/gcp-overview.md#cloud-networking-gc-overview). - Cluster links must be between clusters in the same Confluent Cloud Organization. Cross-organization cluster linking between private networking clusters is not supported. - If using either the [Confluent CLI](https://docs.confluent.io/confluent-cli/current/command-reference/overview.html) (`confluent kafka cluster link create`) or the [Apache Kafka CLI](https://docs.confluent.io/kafka/operations-tools/kafka-tools.html) (`kafka-cluster-links --create`) to create a cluster link in Confluent Cloud between two clusters with private networking, you must provide the source cluster ID with the `--cluster-id` flag for the link to be created successfully. #### Tutorial: Create a Cluster Link Decide on the source cluster and destination cluster for the cluster link. You will need the following information about these clusters: - Environment ID containing the source cluster - Environment ID containing the destination cluster - Cloud API key(s) for user(s) with RBAC role authorization over the source cluster, either: - OrganizationAdmin, or - EnvironmentAdmin, or - CloudClusterAdmin - Cloud API key(s) for user(s) with RBAC role authorization over the destination cluster, either: - OrganizationAdmin, or - EnvironmentAdmin, or - CloudClusterAdmin ##### Create the Cluster Link Create a cluster link using your preferred method. The Confluent Cloud Console, the [Confluent CLI](https://docs.confluent.io/confluent-cli/current/command-reference-index.html), REST API, or Terraform are all valid methods to create a cluster link. Following is an example of how to create one using the Confluent CLI. 1. Create or retrieve an API key for the source cluster. The API key should correspond to a Service Account that has [appropriate read permissions](security-cloud.md#cloud-cluster-link-security) on the source cluster. [Copy-paste command examples](security-cloud.md#cluster-link-read-permissions-on-source-cluster-cc) are available in the [Cluster Linking security tutorial](security-cloud.md#cluster-link-lifecycle-and-permissions). 2. From a network that has network access to the Destination cluster, use the command to create a cluster link: ```bash confluent kafka link create \ --cluster \ --source-cluster \ --source-bootstrap-server \ --source-api-key \ --source-api-secret ``` (As an alternative to explicitly providing the destination cluster ID in the above command, you could first run `confluent kafka cluster use ` to establish the destination cluster ID as the context for subsequent commands. Another example of creating a cluster link is provided in the [basic topic data sharing tutorial](topic-data-sharing.md#cloud-create-cluster-link). Although those steps are not specific to private networking, the syntax for creating the cluster link is the same.) At this point, you have successfully created a link from a Azure Private Link Confluent Cloud cluster. To learn more, these resources describe how to create a cluster link step-by-step for various use cases: - [Cluster Linking Quick Start on Confluent Cloud](quickstart.md#cloud-cluster-link-quickstart) is a fast-paced tutorial - The [Cluster Linking Data Sharing tutorial](topic-data-sharing.md#cloud-cluster-link-topic-data-sharing) is an in-depth tutorial - The [Disaster Recovery Whitepaper](https://www.confluent.io/resources/white-paper/best-practices-disaster-recovery/) covers how to architect an active-passive DR setup in Confluent Cloud - The [Cluster Linking Disaster Recovery page](dr-failover.md#cloud-cluster-linking-dr) gives a basic overview of Cluster Linking for Disaster Recovery To learn more about Confluent Cloud and mirror topics, see the [Cluster Linking docs and examples](index.md#cloud-cluster-linking). #### Delete the cluster links If you want to remove cluster links and stop accruing charges, you can delete them in any order with the following command: ```bash confluent kafka link delete --cluster ``` Alternatively, you can use the Confluent Cloud Console, the REST API, or Terraform. #### Stopping the data flow Deleting any one resource–cluster link will stop data from being mirrored from source to destination cluster. ## Link external clusters to Confluent Cloud over a private network You can use Cluster Linking to link external clusters to Confluent Cloud clusters over a private network. This can serve various use cases, including high availability data replication, disaster recovery, or data migration. Cluster Linking over private networking preserves offsets from your external sources to destination Confluent Cloud clusters, and provides an efficient, secure, and seamless experience. Organizations can replicate data from self-hosted or managed Kafka clusters, including Amazon MSK and other Kafka compatible services in AWS, and self-managed Kafka running in Azure virtual networks, without exposing brokers to the public internet or performing manual offset translation. Confluent supports some of the most sensitive workloads across financial services, healthcare, and insurance. Cluster Linking enables business-critical workloads with high security demands to make their way into the cloud securely and quickly, without compromising security controls, data integrity, or timelines. ### What problem does this solve? Kafka migrations are notoriously difficult, especially when clusters live behind firewalls in secure, private networks. Not only are there risks of data loss, but orchestrating migration requires copying configurations, managing offsets, and coordinating application switchover, or potentially exposing data to the public internet in contradiction to security best practices. Alternatives such as MirrorMaker2 require you to manage the VMs, offsets, networking, and all the associated infrastructure. ### How does it work? External Cluster Linking uses direct, private connections to remote Kafka clusters, using AWS PrivateLink on AWS and Azure Private Link on Azure. Cluster Linking Kafka native, byte-for-byte replication, simplifies multi-cluster architectures and cluster migrations while eliminating the complexities and risks of external tooling or exposing data to the public internet. Teams operating open-source Apache Kafka or Amazon MSK clusters can configure Confluent access points which attach to VPC Endpoint Services in your virtual private cloud (VPC). Cluster Linking can then use this private connection and start replicating data while preserving topic configurations, ACLs, and synchronizing consumer offsets automatically. ![image](images/msk-private-link-ccloud.png) Keep in mind the following points related to this solution: - A single network load balancer (NLB) per-broker is required because a single NLB cannot route requests to the correct brokers without knowledge of Kafka partition leadership. Generic NLBs are not Kafka-aware, so a NLB would be insufficient. - Each NLB has one single target–an IP address corresponding to a single Kafka broker. In the diagram, this is represented as an Elastic Network Interface (ENI) that could be attached to a variety of different things. - Each NLB is configured to listen on a specified port corresponding to a Kafka listener port and maps to the same specified port on the target. - Each NLB is associated to a Kafka broker-specific VPC Endpoint Service. - Kafka broker-specific Confluent access points attach to each VPC Endpoint Service. - Kafka broker-specific Confluent DNS records point to each Confluent Access Point. This setup creates a sort of “virtual endpoint” for each Kafka broker in the Confluent Cloud Network, making the entire Kafka cluster reachable by Cluster Linking. For efficiency, you can follow the tutorial below using Terraform module provided by Confluent. On Azure, the architecture uses the same pattern with Azure-native components: each Kafka broker sits behind its own Azure Load Balancer and a Private Link Service, which serves the same role as a VPC Endpoint Service on AWS. Confluent access points attach to each broker’s Private Link Service, and broker-specific Confluent DNS records point to each access point. ### Limitations - Destination clusters on Google Cloud are not supported. - Linking external clusters to Confluent Cloud cannot be accomplished with only Terraform. Terraform is not supported for the end-to-end workflow. ### Tutorial: Link external clusters to Confluent Cloud This tutorial demonstrates use of Terraform to provision networking resources, but creating the cluster link itself requires the Confluent CLI or REST API. An end-to-end Terraform-only workflow is not currently supported. ### AWS ### Prerequisites and assumptions - An active Confluent Cloud account, and access to Confluent Cloud Console. - An existing Enterprise cluster running on Confluent Cloud. - A source Kafka cluster running on AWS with PrivateLink enabled. This tutorial uses a managed AWS MSK cluster with accessible endpoints as the example source cluster. - [Confluent CLI](https://docs.confluent.io/confluent-cli/current/install.html) installed, configured, and [up-to-date](https://docs.confluent.io/confluent-cli/current/command-reference/confluent_update.html). - Terraform, with access to the Terraform CLI. - Terraform public module: [module-clusterlinking-outbound-private](https://github.com/confluentinc/cc-terraform-module-clusterlinking-outbound-private). - AWS CLI installed and configured with [credentials](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) files. For an explanation of this requirement, see the Terraform module README. ### Step 1. Add a Terraform module 1. Create a new Terraform configuration, or use an existing configuration. 2. Collect or reference the required variable values in a new module block, as shown in the following example. ```terraform module "cluster-linking-aws-msk-private-link" { source = "git::https://github.com/confluentinc/cc-terraform-module-clusterlinking-outbound-private.git" name_prefix = "msk" use_aws = true aws_region = "eu-south-2" aws_vpc_id = "vpc-01234567891011120" aws_region = "eu-south-2" aws_vpc_id = "vpc-01234567891011120" aws_kafka_brokers = [ { id = "1" subnet_id = "subnet-0123456789101112a" endpoints = [ { host = "b-1.mskcluster.a1b2c3.c3.kafka.eu-south-2.amazonaws.com" port = 9096 ip = "10.0.1.101" } ] }, { id = "2" subnet_id = "subnet-0123456789101112b" endpoints = [ { host = "b-2.mskcluster.a1b2c3.c3.kafka.eu-south-2.amazonaws.com" port = 9096 ip = "10.0.2.102" } ] }, { id = "3" subnet_id = "subnet-0123456789101112c" endpoints = [ { host = "b-3.mskcluster.a1b2c3.c3.kafka.eu-south-2.amazonaws.com" port = 9096 ip = "10.0.3.103" } ] } ] cc_env_id = "env-012345" cc_cluster_id = "lkc-012345" } ``` 3. Initialize and install the new module in your new or existing Terraform configuration. ```bash terraform init -upgrade ``` ### Step 2. Apply the configuration 1. Generate a new plan to uncover any configuration issues and prepare to apply the configuration. ```bash terraform plan ``` The output of this command previews the resources that will be created. ```text ... module.cluster-linking-outbound-private.module.aws_networking["main"].aws_vpc_endpoint_service.brokers["broker-3"] will be created + resource "aws_vpc_endpoint_service" "brokers" { + acceptance_required = false + allowed_principals = [ + "arn:aws:iam::123456789101:role/env-a1b2c3-role", ] + arn = (known after apply) + availability_zones = (known after apply) + base_endpoint_dns_names = (known after apply) + id = (known after apply) + manages_vpc_endpoints = (known after apply) + network_load_balancer_arns = (known after apply) + private_dns_name = (known after apply) + private_dns_name_configuration = (known after apply) + region = "eu-south-2" + service_name = (known after apply) + service_type = (known after apply) + state = (known after apply) + supported_ip_address_types = (known after apply) + supported_regions = [ + "eu-south-2", ] + tags = { + "Description" = "VPC Endpoint Service for Kafka broker 3 managed by Terraform" + "Name" = "cl-demo-broker-3-vpces" } } Plan: 23 to add, 0 to change, 0 to destroy. ``` 2. Review the output of the plan command to verify that the resources will be created as expected. Resolve any issues with the configuration. 3. Apply the configuration to create the resources. ```text module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-1"]: Still creating... [0m10s elapsed] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-2"]: Still creating... [0m10s elapsed] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-3"]: Still creating... [0m10s elapsed] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-3"]: Still creating... [0m20s elapsed] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-1"]: Still creating... [0m20s elapsed] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-2"]: Still creating... [0m20s elapsed] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-3"]: Creation complete after 0m29s [id=dnsrec-a1c2b3] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-1"]: Creation complete after 0m29s [id=dnsrec-d4e5f6] module.cluster-linking-outbound-private.confluent_dns_record.aws["broker-2"]: Creation complete after 0m29s [id=dnsrec-g7h8i9] Apply complete! Resources: 23 added, 0 changed, 0 destroyed. ``` 4. In the Confluent Cloud Console ([https://confluent.cloud/login](https://confluent.cloud/login)), navigate to the environment that contains the Confluent access points and select the **Network Management** tab. Find the new or existing gateway you plan to use, and select it. - Click the **Access points** tab, to view the list of per-broker access points, as configured in the Terraform module. ![Access points tab in the Confluent Cloud console listing the per-broker access points created by the Terraform module](images/msk-private-link-access-points-in-ccloud-console.png) - Click the **DNS** tab to view the list of domain names associated with the broker endpoints. ![DNS tab in the Confluent Cloud console listing the domain names associated with the broker endpoints](images/msk-private-link-dns-records-in-ccloud-console.png) ### Step 3. Create a new cluster link 1. Create a new properties file containing the client authentication properties to connect to Amazon MSK. AWS IAM Authentication to MSK is not supported. ```properties # msk-client-auth.properties bootstrap.servers=b-1.mskdemomskclusterprod.sdhx15.c3.kafka.eu-south-2.amazonaws.com:9096,b-2.mskdemomskclusterprod.sdhx15.c3.kafka.eu-south-2.amazonaws.com:9096,b-3.mskdemomskclusterprod.sdhx15.c3.kafka.eu-south-2.amazonaws.com:9096 security.protocol=SASL_SSL sasl.mechanism=SCRAM-SHA-512 sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="" password=""; ``` 2. Use the Confluent CLI to [create a new cluster link](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/link/confluent_kafka_link_create.html). ```bash confluent kafka link create msk-external-link \ --config msk-client-auth.properties \ --destination-cluster lkc-012345 \ --destination-bootstrap-server lkc-012345.eu-south-2.aws.private.confluent.cloud:9092 \ --destination-api-key \ --destination-api-secret ``` Your output should resemble the following. ```text Created cluster link "msk-external-link" with configs: "bootstrap.servers"="b-1.mskdemomskclusterprod.sdhx15.c3.kafka.eu-south-2.amazonaws.com:9096,b-2.mskdemomskclusterprod.sdhx15.c3.kafka.eu-south-2.amazonaws.com:9096,b-3.mskdemomskclusterprod.sdhx15.c3.kafka.eu-south-2.amazonaws.com:9096" "link.mode"="DESTINATION" "sasl.mechanism"="SCRAM-SHA-512" "security.protocol"="SASL_SSL" ``` 3. (Optional) Update the cluster link configuration to automatically create mirror topics for all remote topics. - The updated configuration file should resemble the following. ```properties # cluster-link-update.properties auto.create.mirror.topics.enable=true auto.create.mirror.topics.filters={"topicFilters":[{"name":"*","patternType":"LITERAL","filterType":"INCLUDE"}]} ``` - Run [confluent kafka link configuration update](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/link/configuration/confluent_kafka_link_configuration_update.html) to update the cluster link configuration. ```bash confluent kafka link configuration update msk-external-link --config cluster-link-update.properties ``` ### Step 4. View Cluster Link and mirroring 1. In the Confluent Cloud Console, navigate to the **Cluster Links** tab. Find the cluster link you created, and select it. The cluster link view should resemble the following. Your cluster link may look different from this example, depending on whether there is data being produced to your external cluster and if you chose to auto-create mirror topics. ![Cluster Links tab in the Confluent Cloud console showing the details of the newly created cluster link](images/msk-private-link-external-cluster-on-ccloud-console.png) 2. Select a mirror topic from the list to view the replicated messages. ![Mirror topic view in the Confluent Cloud console showing the messages replicated from the external cluster](images/msk-private-link-mirror-topic-on-ccloud-console.png) ### Azure ### Prerequisites and assumptions - A source Kafka cluster running on broker VMs in an Azure VNet. Brokers must advertise resolvable DNS hostnames in the `advertised.listeners` configuration property. For full networking prerequisites, see the Terraform module README. - An existing Enterprise cluster running on Confluent Cloud in an Azure region. - An existing Azure resource group, VNet, and broker subnet, plus free address space in the VNet for the dedicated Private Link Service NAT subnet that the Terraform module creates. - [Confluent CLI](https://docs.confluent.io/confluent-cli/current/install.html) installed, configured, and [up-to-date](https://docs.confluent.io/confluent-cli/current/command-reference/confluent_update.html). - Azure credentials for the `azurerm` Terraform provider (for example, by signing in with the Azure CLI). - Terraform public module: [module-clusterlinking-outbound-private](https://github.com/confluentinc/cc-terraform-module-clusterlinking-outbound-private), using the Azure entry point (`//modules/azure`). ### Step 1. Add a Terraform module 1. Create a new Terraform configuration, or use an existing configuration. 2. Configure the `azurerm` and `confluent` providers. ```terraform provider "azurerm" { features {} subscription_id = "" } provider "confluent" { cloud_api_key = var.cc_api_key cloud_api_secret = var.cc_api_secret } ``` 3. Collect or reference the required variable values in a new module block, as shown in the following example. Note that the Azure module is a nested entry point, so the module `source` ends with `//modules/azure`. ```terraform module "cluster-linking-azure-private-link" { source = "git::https://github.com/confluentinc/cc-terraform-module-clusterlinking-outbound-private.git//modules/azure" name_prefix = "osk" azure_region = "centralus" azure_resource_group_name = "my-kafka-rg" # existing resource group with the broker VMs azure_vnet_name = "my-kafka-vnet" # existing VNet azure_broker_subnet_id = "/subscriptions/.../subnets/brokers" azure_nat_subnet_cidr = "10.0.250.0/24" # new subnet the module creates for the Private Link Service NAT azure_kafka_brokers = [ { id = "1", host = "broker-1.mykafka.example.com", nic_name = "broker-1-vm-nic", port = 9092 }, { id = "2", host = "broker-2.mykafka.example.com", nic_name = "broker-2-vm-nic", port = 9092 }, { id = "3", host = "broker-3.mykafka.example.com", nic_name = "broker-3-vm-nic", port = 9092 }, ] cc_env_id = "env-012345" cc_cluster_id = "lkc-012345" } ``` 4. Initialize and install the new module in your new or existing Terraform configuration. ```bash terraform init -upgrade ``` ### Step 2. Apply the configuration 1. Generate a new plan to uncover any configuration issues and prepare to apply the configuration. ```bash terraform plan ``` The output of this command previews the resources that will be created: per-broker Azure Load Balancers and Private Link Services, the NAT subnet, and the Confluent egress gateway, access points, and DNS records. ```text ... # module.cluster-linking-azure-private-link.module.networking.azurerm_private_link_service.brokers["broker-3"] will be created + resource "azurerm_private_link_service" "brokers" { + auto_approval_subscription_ids = [ + "a1b2c3d4-0123-4567-8910-a1b2c3d4e5f6", ] + id = (known after apply) + load_balancer_frontend_ip_configuration_ids = (known after apply) + location = "centralus" + name = "osk-broker-3-pls" + visibility_subscription_ids = [ + "a1b2c3d4-0123-4567-8910-a1b2c3d4e5f6", ] } Plan: 25 to add, 0 to change, 0 to destroy. ``` 2. Review the output of the plan command to verify that the resources will be created as expected. Resolve any issues with the configuration. 3. Apply the configuration to create the resources. ```bash terraform apply ``` 4. In the Confluent Cloud Console ([https://confluent.cloud/login](https://confluent.cloud/login)), navigate to the environment that contains the Confluent access points and select the **Network Management** tab. Find the new or existing gateway you plan to use, and select it. - Click the **Access points** tab, to view the list of per-broker access points, as configured in the Terraform module. - Click the **DNS** tab to view the list of domain names associated with the broker endpoints. ### Step 3. Create a new cluster link 1. Create a new properties file containing the client authentication properties to connect to your source Kafka cluster. Use the security protocol and mechanism configured on the broker listener that the cluster link connects to. ```properties # kafka-client-auth.properties bootstrap.servers=broker-1.mykafka.example.com:9092,broker-2.mykafka.example.com:9092,broker-3.mykafka.example.com:9092 security.protocol=SASL_SSL sasl.mechanism=SCRAM-SHA-512 sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="" password=""; ``` 2. Use the Confluent CLI to [create a new cluster link](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/link/confluent_kafka_link_create.html). ```bash confluent kafka link create azure-external-link \ --config kafka-client-auth.properties \ --destination-cluster lkc-012345 \ --destination-bootstrap-server lkc-012345.centralus.azure.private.confluent.cloud:9092 \ --destination-api-key \ --destination-api-secret ``` Your output should resemble the following. ```text Created cluster link "azure-external-link" with configs: "bootstrap.servers"="broker-1.mykafka.example.com:9092,broker-2.mykafka.example.com:9092,broker-3.mykafka.example.com:9092" "link.mode"="DESTINATION" "sasl.mechanism"="SCRAM-SHA-512" "security.protocol"="SASL_SSL" ``` 3. (Optional) Update the cluster link configuration to automatically create mirror topics for all remote topics. - The updated configuration file should resemble the following. ```properties # cluster-link-update.properties auto.create.mirror.topics.enable=true auto.create.mirror.topics.filters={"topicFilters":[{"name":"*","patternType":"LITERAL","filterType":"INCLUDE"}]} ``` - Run [confluent kafka link configuration update](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/link/configuration/confluent_kafka_link_configuration_update.html) to update the cluster link configuration. ```bash confluent kafka link configuration update azure-external-link --config cluster-link-update.properties ``` ### Step 4. View Cluster Link and mirroring 1. In the Confluent Cloud Console, navigate to the **Cluster Links** tab. Find the cluster link you created, and select it. The cluster link view depends on whether there is data being produced to your external cluster and whether you chose to auto-create mirror topics. 2. Select a mirror topic from the list to view the replicated messages. This concludes the tutorial. Congratulations! You have now created a cluster link and mirror topics to replicate data from your external cluster to your Confluent Cloud cluster. ## Private to public Cluster Linking Private to public Cluster Linking has some specific requirements and configurations. These are described below, followed by a walkthrough. ### Requirements These instructions apply to cluster links which fall under this category: | Source Cluster | Dedicated Confluent Cloud cluster with private networking. Any cloud provider, region, and networking type (for example, Private Link, VPC Peering, Transit Gateway, and Private Service\* Connect) | |---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Destination Cluster | Dedicated Confluent Cloud cluster with secure public endpoints. | The clusters can be in the same or different Confluent Cloud organizations. Such a cluster link requires using a “source-initiated link”, which differs from other cluster links in these ways: - First, create a cluster link on the destination with specific configurations that are described below. This **must** be done before the link is created on the source cluster. - After the cluster link is created on the destination cluster, a cluster link object must be created on the source cluster, too. It must have certain configurations (described below). - This type of cluster link cannot be created on the Confluent Cloud Console. It must be created using the cluster REST APIs, the Confluent CLI, Terraform, or Confluent for Kubernetes. - Deleting either cluster link object –- source or destination –- will stop data from being replicated between the clusters. - Both cluster link objects must be deleted in order to stop billing charges. If one is deleted but one remains, hourly billing charges may continue to accrue. - The cluster link’s service account must have a CLUSTER:ALTER ACL on the destination cluster. Alternatively, the service account can have the CloudClusterAdmin RBAC role on the destination cluster. ### Configurations #### Destination cluster The cluster link on the Destination cluster needs these configurations: - `connection.mode=INBOUND` - No bootstrap server, instead, the source cluster’s cluster link object will get this. - No security configuration or authentication credentials; instead, the source cluster’s cluster link object will get these. - Other optional configuration options for this cluster link, such as consumer offset sync, ACL sync, and prefix. #### Source cluster The cluster link on the Source cluster needs these configurations: - `link.mode=SOURCE` - `connection.mode=OUTBOUND` - Bootstrap server set to the Destination cluster’s bootstrap server - Security credentials to authenticate into the Destination cluster. (These can be either API key or OAuth). The Service Account or user with these security credentials must have the CLUSTER:ALTER ACL on the destination (public) cluster, or alternatively the CloudClusterAdmin RBAC role. - Security credentials to authenticate into the Source cluster. (These can be either API key or OAuth.) - The service account or user associated with this API key needs the permissions described in [Permissions for the cluster link to read from the source cluster](security-cloud.md#cluster-link-read-permissions-on-source-cluster-cc). - These configurations must all be prefixed with: `local`. For example, the configuration `security.protocol` should be set as `local.security.protocol`. ### Use the Confluent CLI to create a private to public link The following steps walk through how to create a Private to Public cluster link using the Confluent CLI. #### Private cluster In this walkthrough, information about your private cluster is referred to as ``. You will need the following information about your private cluster: - Cluster ID. This will have the format `lkc-XXXXX`. You can get this using the command [confluent kafka cluster list](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/cluster/confluent_kafka_cluster_list.html). This is referred to as ``. - Cluster bootstrap servers. You can get this by describing the cluster with [confluent kafka cluster describe](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/cluster/confluent_kafka_cluster_describe.html); `confluent kafka cluster describe `. The bootstrap will be in the Endpoint row. This is referred to as ``. #### Public cluster In this walkthrough, information about your public cluster is referred to as ``. You will need the following information about the public cluster: - Cluster ID. This will have the format `lkc-XXXXX`. You can get this using the command [confluent kafka cluster list](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/cluster/confluent_kafka_cluster_list.html). This is referred to as ``. - Cluster bootstrap server. You can get this by describing the cluster with [confluent kafka cluster describe](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/cluster/confluent_kafka_cluster_describe.html); `confluent kafka cluster describe `. The bootstrap will be in the Endpoint row. This is referred to as ``. #### Create the Public half of the link 1. Create a file called `public-destination-link.config` with these contents: ```properties link.mode=DESTINATION connection.mode=INBOUND ``` This configuration tells the cluster link to be the destination half of a “source initiated” cluster link. 2. Create the public half with this command: ```bash confluent kafka link create private-to-public --cluster \ --config public-destination-link.config \ --source-cluster ``` #### Create the Private half of the link 1. Create security credentials for the private half of the link with two sets of API keys. To create the Private half, you’ll need two sets of security credentials: one for each cluster. This is because the Private cluster must authenticate with the Public cluster to establish the cluster link, and then the cluster link must authenticate with the Private cluster to read data. To get security credentials, you need API keys on both clusters. Choose one of the following methods; either for development and testing, or for production. - For **development and testing**, a quick way to do is with this commands: ```bash confluent api-key create --resource ``` This creates an API key with Admin privileges. This is not recommended for production or for clusters with sensitive data. - For **production**, create a Confluent Cloud service account for the cluster link and assign it ACLs on the source cluster (the private cluster), as described in [Permissions for the cluster link to read from the source cluster](security-cloud.md#cluster-link-read-permissions-on-source-cluster-cc). Additionally, assign the service account the CLUSTER:ALTER ACL on the destination cluster (the public cluster): ```bash confluent kafka acl create --allow --service-account --operations alter --cluster-scope --cluster ``` If the clusters belong to two different owners or two different Confluent Cloud organizations, then two different service accounts will be needed: one for the source cluster and one for the destination cluster. Using this service account or these service accounts, create two Kafka API keys, one on each Kafka cluster: ```bash confluent api-key create --resource ``` 2. Create the Private link configuration file. Create a file called `private-source-link.config` that contains all necessary link configurations with the following content: ```properties link.mode=SOURCE connection.mode=OUTBOUND security.protocol=SASL_SSL sasl.mechanism=PLAIN sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username='' password=''; local.security.protocol=SASL_SSL local.sasl.mechanism=PLAIN local.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username='' password=''; ``` This file creates a cluster link and specifies: - this is the source half of a “source initiated” cluster link (top two lines). - where to find the destination cluster and how to authenticate with it (the middle section). - how to authenticate with the source cluster (the bottom section, prefixed with `local`). 3. Run the command to create the private half of the link. ```bash confluent kafka link create private-to-public \ --cluster \ --destination-cluster \ --destination-bootstrap-server \ --config private-source-link.config ``` You should see a success message. If so, you now have a link between your clusters that you can use to create mirror topics. If the command times out after 30 seconds, then the private cluster was unable to reach and authenticate to your destination cluster using the provided information. Make sure you can consume from the destination cluster using the `public-destination-link.config` file. #### Create a mirror topic and replicate data Now that you’ve got a cluster link from your Private cluster to your Public one, you can use the cluster link to create mirror topics as described in [Mirror a topic](/cloud/current/multi-cloud/cluster-linking/topic-data-sharing.html#mirror-a-topic). ### Use the REST API to create a private to public link The API call to create a cluster is described in [Create a cluster link](https://docs.confluent.io/cloud/current/ccloud/create-kafka-link/) in the Confluent Cloud API reference. To use this call to create a private to public link with the [REST API](../../kafka-rest/kafka-rest-cc.md#krest-overview): 1. CloudClusterAdmin, EnvironmentAdmin, or OrganizationAdmin for the public cluster sends this request: `POST to {Public_Cluster_REST_API}/kafka/v3/clusters/{Public_Cluster_ID}/links?link_name={link_name}` For example: `https://pkc-12345.us-west-2.aws.confluent.cloud:443/kafka/v3/clusters/lkc-12345/links?link_name=private-to-public` ```bash { "source_cluster_id": "", "configs": [ { "name": "link.mode", "value": "DESTINATION" }, { "name": "connection.mode", "value": "INBOUND" } ] } ``` 2. An OrganizationAdmin, EnvironmentAdmin, or CloudClusterAdmin for the private cluster sends this request to the private cluster: `POST to {Private_Cluster_REST_API}/kafka/v3/clusters/{Private_Cluster_ID}/links?link_name={link_name}` For example: `https://lkc-67890-67890.us-west-2.aws.glb.confluent.cloud:443/kafka/v3/clusters/lkc-67890/links?link_name=private-to-public` ```bash { "destination_cluster_id": "", "configs": [ { "name": "link.mode", "value": "SOURCE" }, { "name": "connection.mode", "value": "OUTBOUND" }, { "name": "bootstrap.servers", "value": "" }, { "name": "security.protocol", "value": "SASL_SSL" }, { "name": "sasl.mechanism", "value": "PLAIN" }, { "name": "sasl.jaas.config", "value": "org.apache.kafka.common.security.plain.PlainLoginModule required username='' password='';" }, { "name": "local.security.protocol", "value": "SASL_SSL" }, { "name": "local.sasl.mechanism", "value": "PLAIN" }, { "name": "local.sasl.jaas.config", "value": "org.apache.kafka.common.security.plain.PlainLoginModule required username='' password='';" } ] } ``` Both REST API calls should return a status of 201: CREATED and a blank response if successful. ## Private-Public-Private Pattern with cluster link chaining and a jump cluster You can configure Cluster Linking between any two Dedicated or Enterprise Confluent Cloud clusters with any private networking configuration, as a fully supported pattern. These clusters must be in the same organization. ### Cluster link chaining and jump clusters However, it is still possible to use Cluster Linking between private networking combinations that cannot be directly linked (per the [supported clusters table](#cluster-linking-private-net-supported-combos)). Cluster Linking can replicate data and metadata between any two privately networked, dedicated Confluent Cloud clusters using two mechanisms: - A chain of multiple cluster links–or simply “chaining”, which keep data and metadata replicated from start to finish. Cluster Links and mirror topics are designed to be composable and to chain together intuitively. - A dedicated Confluent Cloud cluster with secure public endpoints, which can be securely reached by both private clusters. This is colloquially known as a “jump cluster”, as it is the middle point between the two disparate private networks. To learn more about the security implications of using a cluster with secure public endpoints, and why this is a secure choice, see [Security considerations for the Private-Public-Private pattern](#cluster-link-security-for-chain-and-jump). ![image](images/cluster-link-chain-and-jump.png) ### How it works The solution consists of an origin cluster, a “jump” cluster, and a target cluster, as described below. Origin cluster : a Dedicated Confluent Cloud cluster with any private networking type where the data is coming from. The original source of the data and metadata. Jump cluster : a Dedicated Confluent Cloud cluster with secure public endpoints
- A cluster link replicates topics and desired metadata from the origin cluster (its source cluster) to the jump cluster (its destination cluster) - This cluster link uses the “private to public” feature, where the private target cluster always initiates an outbound connection to the internet destination cluster. The internet cluster never has access to the private network. Target cluster : a Dedicated Confluent Cloud cluster with any private networking type where the data is going to. The final destination of the data and metadata.
- A cluster link replicates data and metadata from the jump cluster (the link’s source cluster) to the target cluster (the link’s destination cluster) - Data and metadata are kept consistent with the origin cluster thanks to cluster link chaining and the buyer for byte replication offered by mirror topics. - The private target cluster always initiates an outbound connection to the internet destination cluster. The internet cluster never has access to the private network. ### Security considerations for the Private-Public-Private pattern There are three security goals that are achieved by choosing private networking as opposed to public networking, and all three can be achieved with the private-public-private Cluster Linking pattern: #### Prevent data from being intercepted and sniffed in transit over the internet Private networking is appealing because it ensures that no third party can be involved in the transfer of data and potentially “sniff” or otherwise reveal the contents of that data. However, all Cloud Service Providers (CSPs) that Confluent Cloud operates on guarantee that data between two of their networks always stays on their own, private backbone, even if a public IP is used in the process (reference documentation for [AWS](https://aws.amazon.com/vpc/faqs/), [Azure](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview), and [Google Cloud](https://cloud.google.com/network-tiers/docs/overview)). Therefore, if all three Confluent Cloud clusters in the private-public-private pattern are on the same CSP, the data never leaves the cloud service provider’s backbone and cannot be intercepted by a third party, satisfying this goal. #### Prevent Distributed Denial of Service (DDoS) attacks from interrupting cluster operations Private IP addresses cannot be addressed or resolved from outside the private network, giving an extra layer of protection against a potential DDoS attack from a malicious actor who learned the cluster’s addresses. The private-public-private pattern does use internet-accessible addresses on the jump cluster; these addresses are only used for replication. The private cluster(s) which serve business-critical applications remain protected behind private IPs. A theoretical DDoS attack on the jump cluster could temporarily interrupt replication, but if replication is used for Disaster Recovery, migration, or another similar goal, this would not impact the business-critical workloads which are isolated to the private clusters, and the private clusters themselves cannot be DDoSed. #### Prevent a malicious party from accessing data Private networking gives an extra layer of protection against data exfiltration, by requiring access to the private network in order to access the data. Since the private-public-private pattern puts the data on an Internet cluster, the data on the jump cluster is not protected by network isolation, and therefore access to this cluster must be carefully guarded. Because accessing a Confluent Cloud cluster requires an API key specifically created for that cluster, the jump cluster can be protected by only creating one API key for it–the API key given to the cluster link–and then immediately destroying that API key. There is no need to store the cluster link’s API key, as it is securely and permanently stored on the cluster link. It is impossible to retrieve the API key from the cluster link; even for Confluent Cloud engineers, which ensures that this API key will never be used for anything other than the Cluster Linking operations. Since no other API keys exist for this cluster, nothing can access the cluster other than the cluster links. ## Confluent Cloud billing considerations There are cost differences associated with private vs. public networking. These are detailed under [Cluster Linking](../../billing/billing-dimensions.md#cloud-cluster-linking-billing-dimensions) in the Billing documentation. Examples are provided there for public networking. Here is further detail specifically related to the private-public-private pattern outlined for Cluster Linking. ### Private-Public-Private pattern cost considerations and security When adding the jump cluster architecture to an existing Origin and Target cluster, new Confluent Cloud cost will be introduced by: - The Jump cluster (an hourly cost) - The two cluster links: one from origin to Jump, and one from Jump to Target (an hourly cost) - The data throughput (ClusterLinkRead and ClusterLinkWrite charged twice), once on each cluster link (a per GB cost). ### How to keep costs as low as possible and maintain security Consider these suggestions and recommendations for keeping costs as low as possible while still achieving the desired level of security on the cluster links. #### Use a single zone for the jump cluster Using a “single zone” cluster for the Jump cluster will reduce the hourly cost of the jump cluster, if the replication use case can tolerate the “single zone” service level agreement (SLA). Here are points to consider for this strategy: - “Multi-zone” clusters are always recommended for clusters that run “production” traffic–which the Origin and Target clusters likely do–as they come with a higher SLA. However, the “single zone” Jump cluster’s SLA may be sufficient if the use case is data sharing, data aggregation, or even disaster recovery. - If there is a disruption in the availability zone used by a “single zone” jump cluster, it will only impact the replication flow from Origin to Target. Producers and consumers on both Origin and Target clusters will be unaffected. When the disruption ends, if the Jump cluster returns to healthy status, the cluster links will automatically resume and catch the Target cluster up with any data that it missed. - For a Data Sharing or Data Aggregation architecture, replication is used to send a copy of data from the Origin to the Target, so the Target’s consumers can read the data. An outage of the availability zone of a single zone Jump cluster would stop the cluster links from replicating new data to the Target cluster. During this time, the Target’s consumers can still read any data that was already replicated to the Target. When the outage is over, if the Jump cluster recovers in good health, the Target’s replicated topics will automatically catch up and the consumers will be able to read data. Topics on the Target cluster that do not use replication will be unaffected. Therefore, the only effect of an availability zone outage on a single zone Jump cluster is a delay in some replicated data. A multi-zone Jump cluster would avoid this case, but for an added cost. - For a Disaster Recovery (DR) architecture, replication is used to keep topics on the Target cluster up-to-date and ready for failover, should an outage hit the Origin cluster. If the availability zone of a single zone Jump cluster has an outage, this would temporarily halt replication, thereby increasing the RPO at the moment. Hypothetically, if some time after this outage began and before it resolved, the Origin cluster’s region (a different cloud region from the Jump cluster) also experienced an outage, then its applications would fail over to the Target cluster without access to recent data produced since the Jump cluster’s zone outage. The net effect is that, in this corner case, a multi-zone Jump cluster would yield a lower RPO than a single zone jump cluster, for an added cost. However, as of this writing, there are no documented cases of a cloud provider experiencing a regional outage and an availability zone outage in a different region at the same time. Because this hypothetical corner case is exceedingly rare, most enterprise companies require disaster recovery for only a single cloud region outage at a time, and therefore would be served by a single zone Jump cluster. #### Use bidirectional cluster links if data needs to flow in both directions If data needs to flow in both directions (Origin to Target, and Target to Origin), using a [bidirectional](cluster-links-cc.md#bidirectional-mode-cluster-linking) link is most cost-effective. Using the “bidirectional” cluster link mode will allow topics to mirror from Origin to Target, and will also allow topics to go back from Target to Origin without any additional cluster links. ([Bidirectional mode](cluster-links-cc.md#bidirectional-mode-cluster-linking) is always recommended when using Cluster Linking for Disaster Recovery.) A single Jump cluster can be used for both directions, as long as prefixing is used on at least one of the cluster links. ## Legacy workflows using network linking Although less efficient than the newer solutions described in [How to use cluster links with private networking](#cloud-cluster-link-how-to-use-for-private-networking), the following workflows using network linking are still supported. If you already have these workflows in place, you can continue to use them. - [(Legacy) Cluster Linking between AWS PrivateLink Confluent Cloud clusters](#cluster-linking-aws-privatelink) - [(Legacy) Cluster Linking between AWS Transit Gateway attached Confluent Cloud clusters](#cluster-linking-aws-tgw) ### (Legacy) Cluster Linking between AWS PrivateLink Confluent Cloud clusters #### WARNING This legacy workflow requires you to first create network link service and private endpoint over which to create the cluster link. Support for private linking with AWS and Azure now enables you to bypass this setup. The currently recommended workflow for both AWS and Azure is described in [Cluster Linking between Confluent Cloud clusters using Azure, AWS, or Google Cloud private networking](#cluster-linking-azure-privatelink). That said, if you are currently using network linking, you can continue to do so. Existing networking linking users who wish to upgrade can send a request to Confluent support. You can use Cluster Linking on Confluent Cloud to create a cluster link that perpetually mirrors data between two Confluent Cloud clusters in different AWS regions, each with the “AWS PrivateLink” networking type. Both clusters must be in the same Confluent Cloud organization. Confluent Cloud is available through [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-g5ujul6iovvcy?trk=14575e70-1766-4f20-8083-0c2757a1ec75&sc_channel=el) or [directly from Confluent](https://www.confluent.io/get-started/). ![image](images/cluster-link-aws-privatelink.png) #### Requirements To implement AWS PrivateLink on Confluent Cloud, you must have an active Confluent Cloud organization containing: - One or more users with these RBAC roles: - OrganizationAdmin, or - EnvironmentAdmin, or - CloudClusterAdmin - Two Dedicated Confluent Cloud clusters with AWS PrivateLink (any regions) - Ability to send REST API calls over the Internet to Confluent Cloud - Connectivity to your AWS PrivateLink clusters via Confluent Cloud Console, REST API, the Confluent CLI, and/or Terraform #### Limitations - An Organization supports a maximum of 20 Network Link Endpoints - A Confluent Cloud network supports a maximum of 5 Network Link Endpoints - Usage of the advanced “source-initiated link” feature is not allowed. - Cluster links must be between clusters in the same Confluent Cloud Organization. Cross-organization cluster linking between AWS PrivateLink clusters is not supported. #### Mental model When AWS PrivateLink is used to connect to a Confluent Cloud cluster, the cluster is isolated in its own Confluent Cloud network for network-level security. This prevents external resources, including Cluster Linking, from connecting to the Kafka cluster. Thus, in order to use Cluster Linking between two Confluent Cloud clusters in different Confluent Cloud networks, a secure networking path is required between the two Confluent Cloud networks. You can create this secure network path using resources called a Network Link Service and a Network Link Endpoint, as described in the networking document [Use Cluster Linking on Confluent Cloud with AWS PrivateLink](../../networking/network-linking.md#aws-network-linking). ![image](images/cluster-link-aws-privatelink-mental-model.png) - Network Link Services allow secure inbound connectivity from specific networks that you specify. - Network Link Endpoints allow secure outbound connectivity to specific networks that you specify. - To use Cluster Linking between two AWS PrivateLink clusters in different regions, you first must establish secure connectivity between the clusters as follows: - Create a Network Link Service in the source cluster Confluent Cloud network to allow incoming connectivity from the destination cluster Confluent Cloud network. - Then, create a Network Link Endpoint in the destination cluster Confluent Cloud network. This allows secure outbound connectivity to the source cluster. #### REST API for Network Resources The REST API for Network Link Endpoints and Services are shown in the Confluent Cloud APIs reference under [Network Link Services (networking/v1)](https://docs.confluent.io/cloud/current/ccloud/network-link-services-networking-v-1/) and are used in the tutorial that follows. #### Terraform for Networking Resources The Terraform documentation for Network Link Endpoints and Services is here: - [confluent_network_link_endpoint Resource](https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_network_link_endpoint) - [confluent_network_link_service Resource](https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_network_link_service) An end-to-end example is shown in this public GitHub repo here: [confluentinc/terraform-provider-confluent](https://github.com/confluentinc/terraform-provider-confluent/tree/master/examples/configurations/cluster-link-over-aws-private-link-networks) #### Tutorial: Create a Network Link and Cluster Link This tutorial uses the REST API, as described in [REST API for Network Resources](#rest-api-for-network-resources-aws-privatelink). To learn more about network links, see also [Use Cluster Linking on Confluent Cloud with AWS PrivateLink](../../networking/network-linking.md#aws-network-linking). Decide on the source cluster and destination cluster for the cluster link. You will need the following information about these clusters: - Environment ID and Network ID containing the source cluster - Environment ID and Network ID containing the destination cluster - Cloud API key(s) for user(s) with RBAC role authorization over the source cluster, either: - OrganizationAdmin, or - EnvironmentAdmin, or - CloudClusterAdmin - Cloud API key(s) for user(s) with RBAC role authorization over the destination cluster, either: - OrganizationAdmin, or - EnvironmentAdmin, or - CloudClusterAdmin ##### Step 1: Create Network Link Service ![image](images/cluster-link-aws-privatelink-create-network-link-service.png) Create the [Network Link Service](../../networking/network-linking.md#aws-networklinking-create-network-link-service) by sending a [POST REST API request](https://docs.confluent.io/cloud/current/ccloud/create-networking-v-1-network-link-service/) as a [properly authenticated user](https://docs.confluent.io/cloud/current/api.html/#authentication) who has OrganizationAdmin, EnvironmentAdmin, or NetworkAdmin over the source cluster: ```bash curl --location 'https://api.confluent.cloud/networking/v1/network-link-services' \ --header 'Content-Type: application/json' \ --header "Authorization: Basic $(echo -n "$CLOUD_API_KEY:$CLOUD_API_SECRET" | base64)" \ --data '{ "spec": { "display_name": "", "description": "", "environment": { "id": "" }, "network": { "id": "" }, "accept": { "networks": [ "" ] } } }' ``` Take note of the ID of the `network_link_service` in the REST API response. If lost, this ID can be retrieved with a [GET REST API call](https://docs.confluent.io/cloud/current/ccloud/list-networking-v-1-network-link-services/): ```none curl --location 'https://api.confluent.cloud/networking/v1/network-link-services?environment=' \ --header "Authorization: Basic $(echo -n "$CLOUD_API_KEY:$CLOUD_API_SECRET" | base64)" ``` #### NOTE For advanced setups: - Multiple network IDs can be listed at once - As an alternative to a network, to allow secure inbound connectivity from an entire Confluent Cloud Environment, pass an environment with the destination cluster environment ID(s) instead ##### Step 2: Create Network Link Endpoint ![image](images/cluster-link-aws-privatelink-create-network-link-endpoint.png) Create the [Network Link Endpoint](../../networking/network-linking.md#aws-networklinking-create-network-link-endpoint) by sending the [POST REST API request](https://docs.confluent.io/cloud/current/ccloud/create-networking-v-1-network-link-endpoint/) as a [properly authenticated with a user](https://docs.confluent.io/cloud/current/api.html/#pagination) who has OrganizationAdmin, EnvironmentAdmin, or NetworkAdmin over the destination cluster: ```bash curl --location 'https://api.confluent.cloud/networking/v1/network-link-endpoints' \ --header 'Content-Type: application/json' \ --header "Authorization: Basic $(echo -n "$CLOUD_API_KEY:$CLOUD_API_SECRET" | base64)" \ --data '{ "spec": { "display_name": "", "description": "", "environment": { "id": "" }, "network": { "id": "" }, "network_link_service": { "id": "" } } }' ``` ##### Step 3: Wait until the Network Link Endpoint is READY ![image](images/cluster-link-aws-privatelink-wait-for-network-ready.png) It takes several minutes to establish secure connectivity. When ready to be used by Cluster Linking, the network link endpoint’s status will change from PROVISIONING to READY, which you can check with a [GET REST API call](https://docs.confluent.io/cloud/current/ccloud/get-networking-v-1-network-link-endpoint/): ```bash curl --location 'https://api.confluent.cloud/networking/v1/network-link-endpoints?environment=' \ --header "Authorization: Basic $(echo -n "$CLOUD_API_KEY:$CLOUD_API_SECRET" | base64)" ``` To learn more about this step, see [Check Network Link Endpoint status](../../networking/network-linking.md#aws-networklinking-create-network-link-status) in the network link documentation. ##### Step 4: Create the Cluster Link ![image](images/cluster-link-aws-privatelink-create-link.png) After the Network Link Endpoint is in READY status, create a cluster link using your preferred method. The Confluent Cloud Console, the [Confluent CLI](https://docs.confluent.io/confluent-cli/current/command-reference-index.html), REST API, or Terraform are all valid methods to create a cluster link. Here is an example of how to create one using the Confluent CLI: 1. Create or retrieve an API key for the source cluster. The API key should correspond to a Service Account that has [appropriate read permissions](security-cloud.md#cloud-cluster-link-security) on the source cluster. [Copy-paste command examples](security-cloud.md#cluster-link-read-permissions-on-source-cluster-cc) are available in the [Cluster Linking security tutorial](security-cloud.md#cluster-link-lifecycle-and-permissions). 2. From a network that has network access to the Destination cluster (such as, an EC2 instance in a VPC with the PrivateLink endpoint), issue the command to create a cluster link: ```bash confluent kafka link create \ --source-cluster \ --source-bootstrap-server \ --source-api-key \ --source-api-secret ``` To learn more, browse these resources which walk through how to create a cluster link step-by-step for various use cases: - [Cluster Linking Quick Start on Confluent Cloud](quickstart.md#cloud-cluster-link-quickstart) is a fast-paced tutorial - The [Cluster Linking Data Sharing tutorial](topic-data-sharing.md#cloud-cluster-link-topic-data-sharing) is an in-depth tutorial - The [Disaster Recovery Whitepaper](https://www.confluent.io/resources/white-paper/best-practices-disaster-recovery/) covers how to architect an active-passive DR setup in Confluent Cloud - The [Cluster Linking Disaster Recovery page](dr-failover.md#cloud-cluster-linking-dr) gives a basic overview of Cluster Linking for Disaster Recovery Congratulations, you have successfully geo-replicated data between two AWS PrivateLink Confluent Cloud clusters! To learn more about what you can accomplish with Confluent Cloud and mirror topics, see the [Cluster Linking docs and examples](index.md#cloud-cluster-linking). #### Deleting the cluster links and networking resources If you want to remove cluster links and stop accruing charges, you can delete them in any order with the following command: ```bash confluent kafka link delete --cluster ``` Or on the Confluent Cloud Console, the REST API, or Terraform. If all cluster links are deleted and you no longer need the network links, use the DELETE REST API to [delete the Network Link Endpoint(s)](https://docs.confluent.io/cloud/current/ccloud/delete-networking-v-1-network-link-endpoint/) first, and then [delete the Network Link Service](https://docs.confluent.io/cloud/current/ccloud/delete-networking-v-1-network-link-service/). #### Stopping the data flow Deleting any one resource–cluster link, network link service, or network link endpoint will stop data from being mirrored from source to destination cluster. Removing the destination cluster network or environment ID from the allowed list of IDs in the Network Link Service will also stop the data flow. ### (Legacy) Cluster Linking between AWS Transit Gateway attached Confluent Cloud clusters #### WARNING This legacy workflow requires you to use AWS Transit Gateway to create a cluster link with private networking. Support for private linking with AWS and Azure now enables you to bypass this setup. The currently recommended workflow for both AWS and Azure is described in [Cluster Linking between Confluent Cloud clusters using Azure, AWS, or Google Cloud private networking](#cluster-linking-azure-privatelink). Confluent provides Cluster Linking between AWS Transit Gateway Confluent Cloud clusters as a fully managed solution for geo-replication, multi-region, high availability and disaster recovery, data sharing, or aggregation. This section describes how to use Cluster Linking to sync data between two private Confluent Cloud clusters in different AWS regions that are each attached to an AWS Transit Gateway. You can provision new Confluent Cloud clusters or use existing AWS Transit Gateway attached or AWS virtual private cloud (VPC) Peered Confluent Cloud clusters. ![image](images/cluster-link-private-net-aws-gate-arch.png) #### Limitations - This is limited to Confluent Cloud clusters that use AWS Transit Gateway as their networking type. - The clusters must be provisioned with different CIDRs. The address ranges cannot overlap. - The CIDRs for both clusters must be within RFC 1918: - 10.0.0.0/8 - 100.64.0.0/10 - 172.16.0.0/12 - 192.168.0.0/16 - The CIDRs for either cluster cannot be 198.18.0.0/15, even though it is a valid Confluent Cloud CIDR. - This configuration does not support combinations with other networking types, such as PrivateLink, or with other cloud providers, such as Google Cloud or Microsoft Azure. #### Setup ##### Step 1: Create the networks and clusters 1. Determine: - the two regions to use - the two non-overlapping /16 CIDRs for the two Confluent Cloud clusters to use - the AWS account(s) to use This decision will depend on your architecture and business requirements. Note that: - You can use only one region, but most use cases will involve two (or more) different regions. - It is possible for the Cluster Linking to be between different AWS accounts or Confluent Cloud accounts, but most use cases will involve one AWS account and one Confluent Cloud account. 2. Provision two AWS Transit Gateways, one in each region, and create two resource shares; one for each Transit Gateway, as described in [Use AWS Transit Gateway on Confluent Cloud](../../networking/aws-transit-gateway.md#aws-transit-gateway) under Networking. ![image](images/cluster-link-private-net-aws-gateways.png) 3. Provision a new Transit Gateway enabled Confluent Cloud network, as described in [Use AWS Transit Gateway on Confluent Cloud](../../networking/aws-transit-gateway.md#enable-transit-gateway-cloud). You will need to specify the network ID and the ARN of the resource share containing that region’s Transit Gateway. It is possible to seamlessly convert an existing AWS VPC Peered Confluent Cloud cluster in that region to a Transit Gateway attached cluster. ![image](images/cluster-link-priv-net-provision-aws-gate-dedicated-cluster.png) 4. Connect a “Command VPC” from which to issue commands, and create topics on the Confluent Cloud cluster in “Region 1”. ![image](images/cluster-link-private-net-aws-gate-command-VPC.png) 1. Create a new VPC in Region 1, from which to run commands against your Confluent Cloud cluster. For purposes of this example, call this the “Command VPC”. 2. Attach the Command VPC to your Transit Gateway. (Make sure you have a route in the Transit Gateway’s route table that points to the Command VPC for the Command VPC’s CIDR range.) ![image](images/cluster-link-private-net-aws-gate-command-VPC-attach-to-transit-gateway.png) 3. In the Command VPC’s route table, create the following routes if they do not already exist: | Component | Route to: | |------------------------------------------------|----------------------------------------------------------------| | Command VPC CIDR range | `local` | | Confluent Cloud CIDR range in this region | Transit Gateway in this region | | Confluent Cloud CIDR range in the other region | Transit Gateway in this region | | `$0.0.0.0/0` | An Internet Gateway (create one if needed) [8](#f8) | * **[8]** `$0.0.0.0/0` enables this VPC to reach out to the internet to install the Confluent CLI. 5. Create and launch an EC2 instance in that VPC. 6. SSH into the EC2 instance. (If needed for this step, create an Elastic IP and assign it to this EC2 instance.) 7. [Install the Confluent Cloud CLI](https://docs.confluent.io/confluent-cli/current/install.html). 8. Log on to the Confluent CLI with [confluent login](https://docs.confluent.io/confluent-cli/current/command-reference/confluent_login.html). 9. Select your Confluent environment with [confluent environment use ](https://docs.confluent.io/confluent-cli/current/command-reference/environment/confluent_environment_use.html). (You can list your environments with [confluent environment list ](https://docs.confluent.io/confluent-cli/current/command-reference/environment/confluent_environment_list.html).) 10. Select your Confluent cluster in this region with [confluent kafka cluster use ](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/cluster/confluent_kafka_cluster_use.html). (You can list your clusters with [confluent kafka cluster list](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/cluster/confluent_kafka_cluster_list.html).) 11. List the topics in your Confluent Cloud cluster with [confluent kafka topic list](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_list.html). If this command fails, your Command EC2 instance may not be able to reach your Confluent Cloud cluster. Your networking may not be correctly set up. Make sure you followed the steps above. See the Troubleshoot section if needed. 12. Create a new topic with [confluent kafka topic create my-topic –partitions 1](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_create.html). If you have more Kafka clients, you can spin them up in VPCs attached to the Transit Gateway, and produce to and consume from the cluster. ##### Step 2: Create a cluster link After you have two Transit Gateway-attached Confluent Cloud clusters, you can set up Cluster Linking between the two clusters to copy data and metadata from one to the other. 1. [Peer the Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html). This will create connectivity between the two. This can be done cross-account, if needed. ![image](images/cluster-link-private-net-aws-gate-command-VPC.png) 2. Set up routes and propagation so that the two clusters have connectivity to each other. In each Transit Gateway’s Route Table, these routes are required: | Component | Route to: | |---------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------| | To the local Confluent Cloud cluster | - CIDR: This region’s Confluent Cloud cluster CID
- Type: Propagated
- Destination: a Confluent VPC [9](#f9) | | To the other region’s Confluent Cloud cluster | - CIDR: The other region’s Confluent Cloud cluster CID
- Type: Static
- Destination: Peering — the other region’s Transit Gateway, that was peered | | To the other command VPC in this region [10](#f10) | - CIDR: CIDR range of your Command VPC
- Type: Propagated
- Destination: Command VPC | | To the other command VPC in the other regions (if applicable) | - CIDR: CIDR range of your Command VPC
- Type: Propagated
- Destination: Command VPC | * **[9]** You can find the VPC ID in the Confluent Cloud Console under this cluster’s Network). * **[10]** Region 1 needs a Command VPC for now, but in a DR scenario, you would need to be able to access your Confluent Cloud clusters from any region. 3. Check that the Command VPC from Region 1 can access the Confluent Cloud cluster in Region 2. This ensures that your networking is set up properly. - List the cluster’s topics with `confluent kafka topic list --cluster `. - If this command succeeds, then you’ve verified that Confluent Cloud has inter-region connectivity! ![image](images/cluster-link-private-net-aws-gate-inter-region-connect-success.png) 4. [Set up privileges](topic-data-sharing.md#set-link-permissions-to-source-cluster-topics) on the cluster in Region 1 for the cluster link, and [create a cluster link](topic-data-sharing.md#cloud-create-cluster-link) on Region 2’s cluster. - You will use the bootstrap server of the cluster in Region 1. Because you have peered the Transit Gateways and set up routing between the two clusters, the cluster in Region 2 will be able to resolve the private CIDR of the cluster in Region 1. - As long as your Command VPC can reach the Destination Cluster (Region 2 in this picture), it does not matter which region the Command VPC is in. (It is okay to run the command from Region 1.) ![image](images/cluster-link-private-network-aws-gate-privileges-region-1-to-2.png) 5. Create mirror topics using the cluster link, and produce and consume the data. This will bring data from Region 1 to Region 2. - Follow the [Quick Start instructions](quickstart.md#create-source-and-mirror-topics-qs) or the more in-depth [Data sharing tutorial instructions](topic-data-sharing.md#create-a-mirror-topic-cloud-tutorial). - It is okay to run these commands from Region 1, even if they are against Region 2’s cluster, as long as your Command VPC has connectivity to Region 2’s cluster. Successfully consuming messages from Region 2 proves the inter-region replication is working, no matter where your Command VPC itself lives. ![image](images/cluster-link-private-net-aws-gate-link-and-mirror-topics.png) 6. Now, you can spin up more Kafka producers and consumers in Region 1, and Kafka consumers in Region 2. You can also create a Command VPC in Region 2, so that you can issue `confluent` commands should Region 1 experience an outage. ![image](images/cluster-link-private-net-aws-gate-regions-produce-consume.png) 7. You can also set up a cluster link in the opposite direction, too. You only need to repeat steps 4 through 6 above. You do not need to set up additional networking to create additional cluster links. You only need to set up the networking once. #### Cluster Linking between two Confluent Cloud clusters in the same region If you want to create a cluster link between two AWS Transit Gateway Confluent Cloud clusters in the same AWS region, this is a special case in which the requirements may be different, depending on the networking setup: Here are some scenarios and factors to consider: - If both Confluent Cloud clusters are in the same Confluent Cloud network, the additional configuration described in previous sections is not necessary, Only one Transit Gateway is required; without any Transit Gateway peering or changes to its route table. - If the Confluent Cloud clusters are in different Confluent Cloud networks, but both are attached to the same Transit Gateway, then the only requirement is that they use the same Transit Gateway Route Table. The routes from each CIDR to each Confluent VPC must be in the same route table. No Transit Gateway Peering is required. - If the Confluent Cloud clusters are attached to different Transit Gateways, then the above configuration is required. The steps are no different for two Transit Gateways in the same region from two Transit Gateways in different regions. #### Management responsibilities Every cluster link runs as a continuous service managed by Confluent Cloud. Keeping a cluster link running is a shared responsibility between Confluent and its customers: - Confluent is responsible for the Cluster Linking service. - The customer is responsible for the network that facilitates the connection between the two clusters. To operate a cluster link between two AWS Transit Gateway Confluent Cloud clusters, Confluent requires that the AWS networking be configured as laid out in the sections on this page. #### Troubleshoot Transit Gateway Cluster Linking This section covers these issues: - [My CLI commands / API calls are failing](#trouble-failing-clis-apis) - [Troubleshoot Transit Gateway connectivity](#trouble-tgw-connectivity) For more troubleshooting help, see [Troubleshoot Cluster Linking on Confluent Cloud](trouble-cc.md#trouble-cc). ##### My CLI commands / API calls are failing Often, CLI commands may fail if you are not running them from a place that has connectivity to your Confluent Cloud cluster. Verify that your CLI (for example, which may be running in a Command EC2 instance) has connectivity to the Confluent Cloud cluster. - You can test connectivity to the cluster with: ```bash confluent kafka cluster describe ``` - Get the URL out of REST Endpoint. ```bash telnet 443 ``` - Example success showing connectivity: ```bash telnet pkc-z3000.us-west-2.aws.confluent.cloud 443 Trying 10.18.72.172… Connected to pkc-z3000.us-west-2.aws.confluent.cloud. Escape character is '^]' ``` - Example failure (the command will hang indefinitely): ```bash telnet pkc-z3000.us-west-2.aws.confluent.cloud 443 ... ``` If this process ends in failure, you are not running the CLI commands from a location that has connectivity to your Confluent Cloud cluster. Work with your networking team to ensure your instance is attached and routed to your Transit Gateway to the Confluent Cloud cluster. ##### Troubleshoot Transit Gateway connectivity Ensure the Transit Gateways, Peering, and Route Tables are properly configured. Assuming a transit gateway in Region A and one in Region B, with CIDRs CIDR-A and CIDR-B : Transit Gateway Region A route table | Component | Route to: | |-------------|-------------------------------------------------------------| | CIDR-A | Confluent VPC A (Confluent is responsible for setting this) | | CIDR-B | Transit Gateway B via Peering connection | Transit Gateway Region B route table | Component | Route to: | |-------------|-------------------------------------------------------------| | CIDR-A | Transit Gateway B via Peering connection | | CIDR-B | Confluent VPC B (Confluent is responsible for setting this) | Note that each transit gateway has routes set for both CIDRs. This may be the issue. If the transit gateways are not both set up with both CIDRs, then the clusters will not have connectivity to each other. The route between the two Confluent Cloud clusters and transit gateways must allow traffic over port `9092`. You can test if the cross-region connectivity works like this: 1. Attach a Test VPC in Region A to A’s transit gateway. 2. Launch an EC2 instance in the Test VPC (or you can use the “Command VPC” if you set one up per the previous steps). 3. Route the EC2 instance into transit gateway in Region A: 1. Test VPC Route Table: | Component | Route to: | |----------------|--------------------------| | CIDR-Test-VPC: | local | | CIDR-A | Transit gateway A | | CIDR-B | Transit gateway A (also) | 2. Transit gateway Region A Route Table: Add `CIDR-Test-VPC: Test VPC Attachment` 3. Transit gateway Region B Route Table: Add `CIDR-Test-VPC: TGW A via Peering connection` (needed for bidirectional connectivity) 4. SSH into the EC2 instance. For example, put an elastic IP on the EC2 instance. 5. Check connectivity to Cluster A: ```bash telnet CIDR-A 9092 ``` If successful, you should see similar output: ```bash Trying 10.18.72.172... Connected to pkc-z3000.us-west-2.aws.confluent.cloud. Escape character is '^]'. ``` 6. Check connectivity across the peering connection to Cluster B: ```bash telnet CIDR-A 9092 ``` If successful, you should see similar output: ```bash Trying 10.18.72.172... Connected to pkc-z3000.us-west-2.aws.confluent.cloud. Escape character is '^]'. ``` ## Confluent Cloud billing considerations There are cost differences associated with private vs. public networking. These are detailed under [Cluster Linking](../../billing/billing-dimensions.md#cloud-cluster-linking-billing-dimensions) in the Billing documentation. Examples are provided there for public networking. Here is further detail specifically related to the private-public-private pattern outlined for Cluster Linking. ### Private-Public-Private pattern cost considerations and security When adding the jump cluster architecture to an existing Origin and Target cluster, new Confluent Cloud cost will be introduced by: - The Jump cluster (an hourly cost) - The two cluster links: one from origin to Jump, and one from Jump to Target (an hourly cost) - The data throughput (ClusterLinkRead and ClusterLinkWrite charged twice), once on each cluster link (a per GB cost). ### How to keep costs as low as possible and maintain security Consider these suggestions and recommendations for keeping costs as low as possible while still achieving the desired level of security on the cluster links. #### Use a single zone for the jump cluster Using a “single zone” cluster for the Jump cluster will reduce the hourly cost of the jump cluster, if the replication use case can tolerate the “single zone” service level agreement (SLA). Here are points to consider for this strategy: - “Multi-zone” clusters are always recommended for clusters that run “production” traffic–which the Origin and Target clusters likely do–as they come with a higher SLA. However, the “single zone” Jump cluster’s SLA may be sufficient if the use case is data sharing, data aggregation, or even disaster recovery. - If there is a disruption in the availability zone used by a “single zone” jump cluster, it will only impact the replication flow from Origin to Target. Producers and consumers on both Origin and Target clusters will be unaffected. When the disruption ends, if the Jump cluster returns to healthy status, the cluster links will automatically resume and catch the Target cluster up with any data that it missed. - For a Data Sharing or Data Aggregation architecture, replication is used to send a copy of data from the Origin to the Target, so the Target’s consumers can read the data. An outage of the availability zone of a single zone Jump cluster would stop the cluster links from replicating new data to the Target cluster. During this time, the Target’s consumers can still read any data that was already replicated to the Target. When the outage is over, if the Jump cluster recovers in good health, the Target’s replicated topics will automatically catch up and the consumers will be able to read data. Topics on the Target cluster that do not use replication will be unaffected. Therefore, the only effect of an availability zone outage on a single zone Jump cluster is a delay in some replicated data. A multi-zone Jump cluster would avoid this case, but for an added cost. - For a Disaster Recovery (DR) architecture, replication is used to keep topics on the Target cluster up-to-date and ready for failover, should an outage hit the Origin cluster. If the availability zone of a single zone Jump cluster has an outage, this would temporarily halt replication, thereby increasing the RPO at the moment. Hypothetically, if some time after this outage began and before it resolved, the Origin cluster’s region (a different cloud region from the Jump cluster) also experienced an outage, then its applications would fail over to the Target cluster without access to recent data produced since the Jump cluster’s zone outage. The net effect is that, in this corner case, a multi-zone Jump cluster would yield a lower RPO than a single zone jump cluster, for an added cost. However, as of this writing, there are no documented cases of a cloud provider experiencing a regional outage and an availability zone outage in a different region at the same time. Because this hypothetical corner case is exceedingly rare, most enterprise companies require disaster recovery for only a single cloud region outage at a time, and therefore would be served by a single zone Jump cluster. #### Use bidirectional cluster links if data needs to flow in both directions If data needs to flow in both directions (Origin to Target, and Target to Origin), using a [bidirectional](cluster-links-cc.md#bidirectional-mode-cluster-linking) link is most cost-effective. Using the “bidirectional” cluster link mode will allow topics to mirror from Origin to Target, and will also allow topics to go back from Target to Origin without any additional cluster links. ([Bidirectional mode](cluster-links-cc.md#bidirectional-mode-cluster-linking) is always recommended when using Cluster Linking for Disaster Recovery.) A single Jump cluster can be used for both directions, as long as prefixing is used on at least one of the cluster links. ## Related content - [Supported cluster types](index.md#cloud-cluster-linking-supported-types) - [Use the Confluent Cloud Console with Private Networking](../../networking/ccloud-console-access.md#ccloud-console-access-networking) - [Cluster Linking Quick Start on Confluent Cloud](quickstart.md#cloud-cluster-link-quickstart) (tutorial) - [Cluster Linking billing dimensions](../../billing/billing-dimensions.md#cloud-cluster-linking-billing-dimensions) ## Next steps Try [Confluent Cloud on AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-g5ujul6iovvcy?trk=14575e70-1766-4f20-8083-0c2757a1ec75&sc_channel=el) with $1000 of free usage for 30 days, and pay as you go. No credit card is required.