Networking in Confluent Cloud

Confluent Cloud Dedicated clusters can be accessed via secure internet endpoints, VPC/VNet peering, or AWS Transit Gateway. All Standard clusters are accessible via secure internet endpoints. All connections to Confluent Cloud are encrypted with TLS and require authentication via API keys, regardless of network configuration.

Important

  • If you use VPC peering, your cluster will not have public endpoints and you can only access it from a peered VPC.
  • If you use AWS Transit Gateway, your cluster will not have public endpoints and you can only access it from the linked AWS Transit Gateway network.
  • After a cluster has been provisioned with VPC peering or AWS Transit Gateway, you cannot change it to have public endpoints.
  • After a cluster has been provisioned with secure internet endpoints, you cannot change it to use VPC/VNet peering or AWS Transit Gateway.

Using VPC peering or AWS Transit Gateway is a tradeoff. Your cluster cannot be accessed from the public internet, which eliminates some potential security threats, but it also requires you to manage the peered or linked networks to ensure all your client applications and developers have the access they need to Confluent Cloud.

Confluent Cloud clusters with internet endpoints are protected by a proxy layer that prevents DDoS, syn flooding, and other network-level attacks. Confluent Cloud clusters with VPC peering are not accessible from the public internet at all.

Confluent Cloud ensures all connections to all cluster configurations use TLS 1.2+ so traffic is encrypted in transit. Access to any Confluent Cloud Kafka cluster or other services is limited to clients with valid API keys and secrets. Non-TLS or unauthenticated connections are not allowed.

Supported Features

Confluent Cloud Dedicated Clusters support the following networking features:

  • Peer up to five VPCs to a single Confluent Cloud VPC.
  • AWS only: connect one AWS Transit Gateway

Limitations

  • Transitive VPC and VNet peering are not supported. If you peer Network A to Network B, and peer Network B to Confluent Cloud Enterprise, applications running in Network A will not be able to access Confluent Cloud Enterprise. You can use shared GCP and Amazon Web Services VPCs to enable transitive VPC connectivity. For more information, see AWS Working with Shared VPCs and GCP Shared VPC overview. To achieve transitivity, you can also link an AWS Transit Gateway to a Confluent Cloud AWS cluster.
  • You cannot directly connect from an on-premises datacenter to Confluent Cloud. To do this, you must first route to a shared services VPC or VNet that you own, peer that to Confluent Cloud, and proxy traffic. If you are interested in this environment for Confluent Cloud, contact your Confluent sales representative.
  • You can co-locate multiple Confluent Cloud dedicated clusters in the same VPC. However, this is limited by the expected number and size of these clusters given the finite number of IPs available. If you require multiple clusters in the same VPC, contact your Confluent account team to further understand these limitations.

Getting Started

To implement VPC peering in your environment, order Confluent Cloud Enterprise or a Confluent Cloud Dedicated cluster with VPC peering enabled. You will be asked to provide the following information to your Confluent representative.

Tip

To learn more about VPC peering, listen to this podcast where Daniel LaMotte (Site Reliability Engineer, Confluent) walks through the details of cloud networking and VPC peering.

Confluent Cloud on Amazon Web Services

VPC Peering

You can configure network peering for Dedicated clusters in AWS using this procedure.

The following information is required.

  • The AWS account ID associated with the VPC that you are peering to Confluent Cloud.
  • The VPC ID that you are peering with Confluent Cloud.
  • The AWS region of the VPC that you are peering with Confluent Cloud.
  • The CIDR block of the VPC that you are peering with Confluent Cloud. This is used by Confluent Cloud to route traffic back to your network. Must be a private range.
  • The VPC CIDR block for Confluent Cloud to use.
    • Cannot be modified after the cluster is provisioned.
    • Cannot overlap with an existing Confluent Cloud CIDR.
    • Must be a /16.
    • Must not overlap with any ranges your organization is using.
    • Must be in one of the following private networks:
      • 10.0.0.0 - 10.255.255.255 (10/8 prefix)
      • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
      • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
    • The CIDR block cannot be any of the following:
      • 10.255.0.0/16
      • 10.100.0.0/16
      • 172.17.0.0/16
      • 172.20.0.0/16
    • You might need to increase your route quota when you use VPC peering, because the Confluent Cloud and AWS routes are shared.

For more information about VPC peering with AWS, see What Is Amazon VPC?.

AWS Transit Gateway

You can enable Confluent Cloud for use with AWS Transit Gateway. To enable, you must provide the following information to your Confluent representative:

  1. The full AWS Resource Name (ARN) for the AWS Resource Access Manager (RAM) Share-ID of the Transit Gateways that you want Confluent Cloud attached to.
  2. The VPC CIDR block for Confluent Cloud to use.
    • Cannot be modified after the cluster is provisioned.
    • Cannot overlap with an existing Confluent Cloud CIDR.
    • Must be a /16.
    • Must not overlap with any ranges your organization is using.
    • Must be in one of the following private networks:
      • 10.0.0.0 - 10.255.255.255 (10/8 prefix)
      • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
      • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
    • The CIDR block cannot be any of the following:
      • 10.255.0.0/16
      • 10.100.0.0/16
      • 172.17.0.0/16
      • 172.20.0.0/16
    • You might need to increase your route quota when you use VPC peering, because the Confluent Cloud and AWS routes are shared.

After the Confluent Cloud clusters have been provisioned:

  1. Confluent accepts RAM share and attaches the Confluent Cloud VPC to the AWS Transit Gateway. Confluent installs RFC 1918 routes in our VPC to return to the TGW.
  2. You can set up the desired routing in the AWS Transit Gateway to route traffic to Confluent Cloud. Any routes you install on the TGW outside of the RFC 1918 range are not supported and will not work with Confluent Cloud.

Confluent Cloud on Google Cloud Platform

Provide the following information to your Confluent representative.

  • The project ID associated with the VPC that you are peering to Confluent Cloud.
  • The network name of the VPC that you are peering with Confluent Cloud. Your VPC and the Confluent Cloud VPC must be in the same region.
  • The VPC CIDR block for Confluent Cloud to use.
    • Cannot be modified after the cluster is provisioned.
    • Cannot overlap with an existing Confluent Cloud CIDR.
    • Must be a /16.
    • Must not overlap with any ranges your organization is using.
    • Must be in one of the following private networks:
      • 10.0.0.0 - 10.255.255.255 (10/8 prefix)
      • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
      • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
    • You might need to increase your route quota when you use VPC peering, because the Confluent Cloud and GCP routes are shared.

For more information about VPC peering with GCP, see VPC Network Peering.

Confluent Cloud on Microsoft Azure

Provide the following information to your Confluent representative.

  • The Tenant ID associated with the VNet that you are peering to Confluent Cloud. Retrieve your Tenant/Directory ID in portal.azure.com under Azure Active Directory -> Properties.
  • The VNet ID of the VNet that you are peering with Confluent Cloud. Retrieve your VNet Resource ID in portal.azure.com under Virtual Networks -> Target VNet -> Properties.
  • The VNet CIDR block for Confluent Cloud to use.
    • Cannot be modified after the cluster is provisioned.
    • Cannot overlap with an existing Confluent Cloud CIDR.
    • Must be a /16.
    • Must not overlap with any ranges your organization is using.
    • Must be in one of the following private networks:
      • 10.0.0.0 - 10.255.255.255 (10/8 prefix)
      • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
      • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
    • The CIDR block cannot be any of the following:
      • 10.255.0.0/16
      • 10.100.0.0/16
      • 172.17.0.0/16
      • 172.20.0.0/16

Your Confluent representative will provide a setup script you must run before Confluent can peer to your VNet.

For more information about VNet peering with Azure, see Virtual Network Peering.