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 PrivateLink
You can configure AWS PrivateLink for Dedicated clusters in AWS using
this procedure.
AWS PrivateLink offers one-way connectivity from your VPC to a Confluent Cloud cluster,
without any coordination of CIDR ranges. PrivateLink connections to Confluent Cloud can
only be made from VPCs in registered customer AWS accounts.
For more information about AWS PrivateLink, see the AWS documentation.
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:
- 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.
- 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:
- 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.
- 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.
Azure Private Link (Preview)
Note
Azure Private Link service is currently in preview. Please contact your Confluent
representative to get access to the preview.
You can configure Azure Private Link for Dedicated clusters in Azure using
this procedure.
Azure Private Link offers one-way connectivity from your VNET to a Confluent Cloud cluster,
without any coordination of CIDR ranges. Private Link connections to Confluent Cloud can
only be made from VNETs in registered customer Azure subscriptions.
For more information about Azure Private Link, see the Azure documentation.
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.