Confluent Cloud Networking FAQ

This topic provides answers to frequently asked questions about networking on Confluent Cloud.

General networking questions

What networking options are available on Confluent Cloud?

Confluent Cloud supports both public and private networking solutions:

  • Public connectivity: Internet-based connections with TLS encryption

  • Private connectivity: Includes the following options for each cloud provider:

    • AWS: PrivateLink, VPC Peering, Transit Gateway, Private Network Interface (PNI)

    • Azure: Private Link, VNet Peering

    • Google Cloud: Private Service Connect, VPC Peering

All connections to Confluent Cloud are encrypted with TLS 1.2 or later and require authentication using API keys, OAuth, or mTLS.

For more information, see Manage Networking on Confluent Cloud.

Can I change a cluster’s networking type after provisioning?

Enterprise clusters on AWS can switch between PNI and PrivateLink Attachment.

For the other cluster types and networking types, you cannot change its networking solution type, after a cluster has been provisioned. You must plan your networking configuration before creating a cluster.

What ports and protocols does Confluent Cloud use?

Confluent Cloud uses the following ports and protocols:

  • Kafka Brokers: Port 9092, Kafka protocol over TCP + TLS

  • Confluent Cloud Console: Port 443, HTTPS over TCP + TLS

  • Schema Registry: Port 443, HTTPS over TCP + TLS

  • Kafka REST API: Port 443, HTTPS over TCP + TLS

  • Confluent CLI: Port 443, HTTPS over TCP + TLS

  • Metrics API: Port 443, HTTPS over TCP + TLS

Can I connect from on-premises to Confluent Cloud with private networking?

Yes, but not directly. If you use private networking (VPC peering, VNet peering, Private Link, or PNI), you cannot directly connect from an on-premises data center to Confluent Cloud.

To enable on-premises connectivity:

  1. Route traffic to a shared services VPC or VNet that you own.

  2. Connect that VPC/VNet to Confluent Cloud using:

    • VPC/VNet peering (with a proxy)

    • Private Link

    • Private network interface (AWS only)

    • Transit Gateway (AWS only)

Contact your Confluent Cloud sales representative for assistance with this configuration.

Confluent Cloud network questions

What is a Confluent Cloud network?

A Confluent Cloud network is a logical network construct in Confluent Cloud that defines the networking configuration for your Dedicated clusters. When you create a Dedicated cluster, you must specify a network type:

  • Public networking: Accessible over the internet

  • Private link access: For private link connections

  • VPC/VNet peering: For peering connections

  • Transit Gateway: For AWS Transit Gateway connections (AWS only)

For more information, see Confluent Cloud networks.

Can I use the same network for multiple clusters?

Yes. You can colocate multiple Confluent Cloud Dedicated clusters in the same Confluent Cloud network, subject to the following:

  • Network capacity and CIDR block size limitations

  • Expected number and size of clusters

  • Resource limits specified in Networks

VPC/VNet peering questions

What is VPC/VNet peering?

VPC (Virtual Private Cloud) peering or VNet (Virtual Network) peering enables you to route traffic using private IP addresses between your cloud network and Confluent Cloud. Your network can communicate with Confluent Cloud as if they are within the same network.

Peering is available on:

  • AWS VPC Peering

  • Azure VNet Peering

  • Google Cloud VPC Peering

For more information, see the cloud-specific peering documentation.

Can I have multiple peering connections?

Yes. You can have multiple VPC/VNet peering connections. For information about limits, see Network quotas in Confluent Cloud.

What CIDR block should I use for my Confluent Cloud network?

When creating a Confluent Cloud network, carefully plan your CIDR block:

  • Ensure the CIDR block does not overlap with your existing VPC/VNet ranges

  • Use appropriate CIDR block sizes for your expected workload

  • Consider future expansion needs

For specific requirements, see Confluent Cloud network CIDR blocks and block size for peering and Transit Gateway.

Egress IP addresses questions

Are public egress IP addresses static?

No. Public egress IP addresses are not guaranteed to be static, although Confluent will make a reasonable effort to minimize changes.

When IP addresses do change:

  • Confluent will provide advance notice through email and in-product notifications

  • You should monitor for updates and update your allowlists accordingly

  • Changes are typically announced at least 30 days in advance

For more information, see Use Public Egress IP Addresses on Confluent Cloud for Connectors and Cluster Linking.

What are public egress IP addresses used for?

Public egress IP addresses are used by Confluent Cloud to establish outbound connections for:

  • Managed connectors: Connecting to external data sources and sinks over the internet

  • Cluster Linking (AWS only): Connecting to external Kafka clusters

Benefits include:

  • IP allowlisting: Add egress IPs to allowlists of external resources

  • Regulatory compliance: Meet requirements for outbound traffic identification

  • Logging and monitoring: Track traffic sources in logs and metrics

Public egress IP addresses are only supported by publicly networked Kafka clusters.

Are egress IP addresses exclusive to my account?

No. Public egress IP addresses are not exclusive to specific Confluent Cloud accounts. All Confluent Cloud managed connectors that use the same cloud service provider and region share the same available public egress IP addresses.

DNS and connectivity questions

Why do I need DNS configuration for private networking?

DNS configuration is essential for private networking to:

  • Resolve Confluent Cloud cluster endpoints to private IP addresses

  • Enable clients to discover and connect to the correct private endpoints

  • Support zonal DNS for high availability configurations

Each cloud provider has different DNS configuration requirements. See the cloud-specific documentation for detailed setup instructions.

PNI questions

What is the AWS feature that PNI is built on?

AWS Multi-VPC Attachment is a feature that allows an instance to have its primary network interface (ENI) in one VPC and attach a secondary ENI from a different VPC. For more information, see Multi-VPC ENI Attachments.

Do any AWS services use this feature?

Several AWS and partner services have been using the Multi-VPC Attachment ENI capability for some time. For instance, AWS Managed Streaming for Apache Kafka (MSK) makes Kafka brokers in MSK clusters accessible to customer VPCs using this feature. Other services using this model include EKS, VMware Cloud on AWS, and SageMaker Studio. In all these cases, the Multi-VPC Attachment ENI appears as a network interface directly within the customer’s VPC.

How is Confluent’s use of Multi-VPC Attachment similar to, and different from, AWS MSK’s use?

While both MSK and Confluent use Multi-VPC Attachment ENIs for private communication, they differ significantly in how these ENIs are managed. As a native AWS service, MSK creates Requester Managed ENIs on the customer’s behalf (when the customer performs MSK cluster operations) using Service Linked Role for MSK. You cannot manage these ENIs directly with EC2 APIs. In contrast, Confluent PNI requires you to create the ENIs themselves using EC2 APIs. You then grant Confluent permission to attach the ENI, converting it into a Multi-VPC Attachment ENI, but you always retain full, direct control over the ENI’s lifecycle.

If I own the ENI for PNI, how does it get attached to a Confluent VM?

To enable Multi-VPC Attachment functionality, the ENI’s owner (the customer) must configure it with INSTANCE-ATTACH permissions. These permissions are granted to the specific AWS account that needs to attach the ENI, which in this case is Confluent’s account. After receiving such permissions, Confluent can invoke EC2 API to attach the ENI to Confluent-owned VMs. Further technical details are available in both the AWS EC2 API documentation and this documentation.

How can I configure Security Group (SG) on the ENI for PNI?

Managing SGs attached to ENIs for PNI is identical to managing them for regular EC2 ENIs. You can use standard EC2 mechanisms (API, SDK, CLI, or Console) to create, update, attach, and delete SGs. If you do not explicitly configure a specific SG on your ENI for PNI, the VPC default SG will be automatically attached to the ENI. The SG attached to the ENI can be centrally administered and audit logged. You can find more details in this documentation and in Example security group configuration.

Can Confluent change the Security Group that I have configured on the ENI for PNI?

Since those SGs are part of your AWS account, Confluent has no ability to view, change or detach them.

Do the ENIs for PNI need to be on a subnet of their own?

You can create ENIs for PNI on any subnet within your VPC.

Can I use Network ACLs (NACLs) to create additional security perimeter around ENIs for PNI? If so, can I use NACLs along with SGs?

As illustrated in the diagram below, you can use NACLs if you choose to create ENIs for PNI on a dedicated subnet that is not directly attached to any other resources. Such a configuration can provide traffic control through NACLs and SGs, that can be implemented individually or in combination. By attaching NACLs to subnets, you can control traffic flow between the PNI subnets and other subnets, especially those that do not need traffic to/from Confluent. For more granular, stateful traffic control, you can configure Security Groups directly on the ENIs for PNI. We strongly recommend such Security Group configuration. Confluent has neither the ability nor the requirement to access or view the NACLs or Security Groups attached to your ENIs for PNI. Therefore, it is your responsibility to ensure that these security controls permit legitimate traffic between your resources in AWS and your cluster in Confluent Cloud. Example security group configuration, Example NACL configuration for non-PNI subnets, and Example NACL configuration for PNI subnets provide examples of NACL and Security Group configurations with the minimum set of rules required for communication with Confluent Cloud.

../_images/aws-pni-security.png

Can I deploy ENIs for PNI in a Transit VPC and connect to that VPC via VPC peering or TGW?

As illustrated in the diagram below, you can create ENIs for PNI in a dedicated Transit VPC that is connected to your App VPCs via peering or Transit Gateway. ENIs for PNI will thus have the same reachability as a virtual machine running in the Transit VPC. We recommended this deployment model, based on the well known hub-and-spoke Transit VPC deployment pattern, as this can be used for scalable deployment with well defined network boundaries.

../_images/aws-pni-dedicated-transit.png

How can I perform packet inspection, intrusion detection, or traffic logging at network level, on traffic flowing through ENIs for PNI?

As the owner of the ENI for PNI, that resides inside your VPC, you can use AWS Traffic Mirroring to capture packets flowing through it, for offline packet analysis like intrusion detection. You can also perform inline traffic analysis on traffic flowing to/from such ENIs using AWS Firewall or third-party security services powered by AWS Gateway Loadbalancer. You can enable VPC flow logs for your VPC to gather information about traffic through such ENIs.

Example security group configuration

../_images/aws-pni-example-sg.png

Example NACL configuration for non-PNI subnets

../_images/aws-pni-nacl-other-subnet.png

Example NACL configuration for PNI subnets

../_images/aws-pni-nacl-pni-subnet.png