Networking in Confluent Cloud

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

Using VPC peering, AWS PrivateLink, or AWS Transit Gateway is a trade-off. 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.

  • If you use VPC peering, your cluster will not have internet endpoints and you can only access it from a peered VPC.
  • If you use AWS PrivateLink, your cluster will not have internet endpoints and you can only access it from VPC Endpoints in accounts you have registered with Confluent Cloud.
  • If you use AWS Transit Gateway, your cluster will not have internet endpoints and you can only access it from the linked AWS Transit Gateway network.
  • After a cluster has been provisioned with VPC peering, AWS PrivateLink, or AWS Transit Gateway, you cannot change it to have internet endpoints.
  • After a cluster has been provisioned with secure internet endpoints, you cannot change it to use VPC/VNet peering, AWS PrivateLink, or AWS Transit Gateway.
  • IP addresses for secure internet endpoints are not static.

Important

Managed connectors created in a VPC peered cluster can access data sources and sinks hosted in all peered VPCs, if the firewall rules allow connector traffic to and from the peered VPCs.

Confluent Cloud clusters with internet endpoints are protected by a proxy layer that prevents some types of DoS, DDoS, syn flooding, and other network-level attacks. Confluent Cloud clusters using VPC peering, AWS PrivateLink, or AWS Transit Gateway 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. Refer to the Confluent Cloud Security Controls whitepaper for more details on securing Confluent Cloud.

Tip

To learn more about networking in Confluent Cloud, listen to this podcast which walks you 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.

Important

Connectors created in a VPC peered cluster can access protected resources hosted on the same VPC cluster. For example, a sink or source connector and a protected database resource, all running in the VPC cluster.

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. The CIDR block 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

Confluent Cloud clusters can be created for use with one 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

VPC Peering

You can configure VPC peering for Dedicated clusters in GCP using this procedure.

Important

Cross-region access to Confluent Cloud is not supported when VPC peering is enabled with GCP.

  • 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

VNet Peering

You can configure network peering for Dedicated clusters in 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.

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 configuration 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. The current limit for a private VPC is 50 CKUs, based on the limit for an environment. This limit and others are outlined in Resource limits for Confluent Cloud.
  • IP addresses in Confluent Cloud are not static.