# Manage Networking on Confluent Cloud Confluent Cloud supports the following networking solutions on the specified cloud service providers: * Amazon Web Services (AWS) * [Public connectivity](#cloud-networking-support-public) * [Private connectivity](#cloud-networking-support-private): Private Network Interface, VPC Peering, Transit Gateway, PrivateLink * Microsoft Azure * [Public connectivity](#cloud-networking-support-public) * [Private connectivity](#cloud-networking-support-private): Private Link, VNet Peering * Google Cloud * [Public connectivity](#cloud-networking-support-public) * [Private connectivity](#cloud-networking-support-private): Private Service Connect, VPC Peering Regardless of network configuration, all connections to Confluent Cloud are encrypted with TLS 1.2 or later and require authentication using API keys, OAuth, or mTLS. Refer to the [Confluent Cloud Security Controls](https://assets.confluent.io/m/67f93edfe1a9f524/original/20200805-WP-Confluent_Cloud_Security_Controls.pdf) whitepaper for more details on securing Confluent Cloud. After a cluster has been provisioned, you cannot change its networking solution type between public and private. Confluent Cloud uses the following ports and protocols for Confluent Cloud services: | Service | Port | Protocol | Transport | |-------------------------|--------|--------------------------------------------|-------------| | Kafka Brokers | 9092 | [Kafka](https://kafka.apache.org/protocol) | TCP + TLS | | Confluent Cloud Console | 443 | HTTPS | TCP + TLS | | Schema Registry | 443 | HTTPS | TCP + TLS | | Confluent REST API | 443 | HTTPS | TCP + TLS | | Confluent CLI | 443 | HTTPS | TCP + TLS | | Metrics API | 443 | HTTPS | TCP + TLS | ## Considerations for public vs. private networking type Using a private or public connectivity with Confluent Cloud is a trade-off: * With private networking, your cluster cannot be accessed from the public endpoints, eliminating potential security threats. * Private networking requires you to manage the peered or linked networks to ensure all your client applications and developers have the needed access to Confluent Cloud. * If you use private networking (VPC peering, VNet peering, Private Link, or Private Network Interface), you cannot directly connect from an on-premises data center to Confluent Cloud. To do this, you must first route to a shared services VPC or VNet that you own and connect that to Confluent Cloud using VPC/VNet peering (along with a proxy), Private Link, or Private Network Interface. If you are interested in this configuration for Confluent Cloud, contact your Confluent sales representative. * Public endpoint IP addresses are not guaranteed to be static. For details, see [IP addresses for public endpoints](#cloud-ip-addresses-not-static). * Native Kafka clients are not designed to work seamlessly in forward proxy environments. If you are producing HTTPS records, consider using the [Kafka REST API](../kafka-rest/kafka-rest-cc.md#krest-produce). * You are prohibited from transmitting cardholder or sensitive authentication data (PCI data as defined in the [Payment Card Industry Data Security Standard](https://www.pcisecuritystandards.org/standards/)) unless you encrypt the PCI data at the message level, and you use only private networking for Confluent Cloud clusters. To learn more about networking in Confluent Cloud, check out the following resources: - [Securing the Cloud with VPC Peering](https://confluent.buzzsprout.com/186154/2055213-securing-the-cloud-with-vpc-peering-ft-daniel-lamotte), a podcast that walks you through the details of cloud networking and VPC peering. - [Confluent Cloud Networking: Introduction](https://developer.confluent.io/learn-kafka/confluent-cloud-networking/intro/), a [Confluent Developer](https://developer.confluent.io) course. - [Apache Kafka Networking with Confluent Cloud](https://developer.confluent.io/podcast/apache-kafka-networking-with-confluent-cloud/), a [Confluent Developer](https://developer.confluent.io) podcast. ## Public networking solutions Confluent Cloud offers data in motion services that can be shared across organizations over secure public endpoints. Confluent Cloud services include the public connectivity for the Basic, Standard, and Dedicated [cluster types](../clusters/cluster-types.md#cloud-cluster-types). Confluent Cloud clusters with secure public endpoints are protected by a proxy layer that prevents types of DoS, DDoS, syn flooding, and other network-level attacks. For Confluent Cloud clusters with public connectivity, you can use public egress IP addresses to communicate with external resources (such as data sources and sinks for managed connectors) over secure public endpoints. For details, see [Use Public Egress IP Addresses on Confluent Cloud for Connectors and Cluster Linking](static-egress-ip-addresses.md#static-egress-ip-addresses). ### IP addresses for public endpoints Because the cloud infrastructure used by Confluent Cloud does not guarantee static IP addresses or hostnames across cluster changes, Confluent Cloud uses DNS to provide consistent addresses. The underlying IP addresses and hostnames might be stable for a period of time, but are subject to change at any time, so don’t rely on them for any purpose. These public endpoints include Kafka brokers, Confluent REST API (`api.confluent.cloud`), and the Telemetry API (`api.telemetry.confluent.cloud`); each can assume any public IP address that the cloud provider has assigned to the region where the workload runs. There’s no specific range to rely on. For details on Confluent’s public egress IP addresses, see [Use Public Egress IP Addresses on Confluent Cloud for Connectors and Cluster Linking](static-egress-ip-addresses.md#static-egress-ip-addresses) and [Public IP address for Confluent Cloud connectors](../connectors/static-egress-ip.md#cc-static-egress-ips). Confluent handles changes to the list of public egress IP addresses as follows: * Confluent considers planned changes to the list of public egress IP addresses a Major Upgrade and follows the policy outlined in [Major Upgrades for Confluent Cloud](../release-notes/upgrade-policy.md#major-ccloud-upgrade). * In the event of an unplanned change, Confluent sends out notifications as soon as possible. * You might need to take immediate action to update your firewall rules. ## Private networking solutions Confluent Cloud includes support for data in motion services that are shared privately with organizations on private networks that offer additional customization and controls for security and privacy. Confluent Cloud clusters using private networking solutions are not accessible from the public endpoints. Confluent Cloud services, the Confluent Cloud Console, and Confluent REST API requests require additional configuration to function as they use cluster endpoints. To use all features of the Confluent Cloud Console and Confluent REST API with private networking, see [Use the Confluent Cloud Console with Private Networking](ccloud-console-access.md#ccloud-console-access-networking). The following table summarizes the private networking solutions supported by Confluent Cloud. For details on each solution, click the link to go to the specific documentation. ### AWS | Feature | VPC Peering | Transit Gateway | PrivateLink (Inbound) | PrivateLink (Outbound) | Private Network Interface | |------------------------------------------------|---------------|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------|--------------------------------------------| | Enterprise cluster | No | No | [Yes](aws-platt.md#cloud-networking-privatelink-aws-esku) | No | [Yes](aws-pni.md#cloud-networking-pni-aws) | | Freight cluster | No | No | No | No | [Yes](aws-pni.md#cloud-networking-pni-aws) | | Dedicated cluster | Yes | Yes | [Yes](private-links/aws-privatelink.md#cloud-networking-privatelink-aws) | No | No | | Connect | Yes | Yes | No | Yes: [Dedicated](aws-egress-privatelink.md#cloud-networking-privatelink-aws-egress) | No | | Connect with Enterprise Kafka clusters | No | No | No | Yes: [Serverless](aws-egress-privatelink-esku.md#cloud-networking-privatelink-aws-egress-esku) | No | | Custom Connectors | No | No | No | Yes: [Serverless](aws-egress-privatelink-esku.md#cloud-networking-privatelink-aws-egress-esku) | No | | Flink | Yes | Yes | Yes: [Serverless](aws-platt.md#cloud-networking-privatelink-aws-esku), [Dedicated](private-links/aws-privatelink.md#cloud-networking-privatelink-aws) | No | No | | Flink external table lookups | No | No | No | Yes: [Serverless](aws-egress-privatelink-esku.md#cloud-networking-privatelink-aws-egress-esku) | No | | Inferences for external AI models | No | No | No | Yes: [Serverless](aws-egress-privatelink-esku.md#cloud-networking-privatelink-aws-egress-esku) | No | | Schema Registry | Yes | Yes | Yes: [Serverless](aws-platt.md#cloud-networking-privatelink-aws-esku), [Dedicated](private-links/aws-privatelink.md#cloud-networking-privatelink-aws) | No | [Yes](aws-pni.md#cloud-networking-pni-aws) | | Cluster Linking with Enterprise Kafka clusters | No | No | No | Yes: [Serverless](aws-egress-privatelink-esku.md#cloud-networking-privatelink-aws-egress-esku) | No | ### Azure | Feature | VNet Peering | PrivateLink (Inbound) | PrivateLink (Outbound) | |----------------------------------------|----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------| | Enterprise cluster | No | [Yes](azure-platt.md#cloud-networking-privatelink-azure-esku) | No | | Dedicated cluster | Yes | [Yes](private-links/azure-privatelink.md#cloud-networking-privatelink-azure) | No | | Connect | Yes | No | Yes: [Dedicated](azure-egress-privatelink.md#cloud-networking-privatelink-azure-egress) | | Connect with Enterprise Kafka clusters | No | No | Yes: [Serverless](azure-egress-privatelink-esku.md#cloud-networking-privatelink-azure-egress-esku) | | Flink | Yes | Yes: [Serverless](azure-platt.md#cloud-networking-privatelink-azure-esku), [Dedicated](private-links/azure-privatelink.md#cloud-networking-privatelink-azure) | No | | Schema Registry | Yes | Yes: [Serverless](azure-platt.md#cloud-networking-privatelink-azure-esku), [Dedicated](private-links/azure-privatelink.md#cloud-networking-privatelink-azure) | No | ### Google Cloud | Feature | VPC Peering | Private Service Connect (Inbound) | Private Service Connect (Outbound) | |------------------------|---------------|--------------------------------------------------------------------------------|---------------------------------------------------------------------| | Enterprise cluster | No | [Yes](gcp-platt.md#cloud-networking-privatelink-gc-esku) | No | | Dedicated cluster type | Yes | [Yes](private-links/gcp-private-service-connect.md#private-service-connect-gc) | No | | Connect | Yes | No | Yes: [Dedicated](gcp-egress-psc.md#cloud-networking-gcp-psc-egress) | | Flink | No | Yes: [Serverless](gcp-platt.md#cloud-networking-privatelink-gc-esku) | No | | Schema Registry | No | Yes: [Serverless](gcp-platt.md#cloud-networking-privatelink-gc-esku) | No | ### Compare Confluent Cloud private networking solutions Confluent Cloud’s private networking solutions are designed to meet different architectural and operational requirements. Understanding the nuances of Confluent Cloud’s private networking options is crucial for selecting the best fit for your organization’s security, compliance, and architectural requirements. While all options ensure your data remains within the cloud provider’s private network, they differ in their scalability, management overhead, and connectivity patterns. The following comparison helps you understand which solution best fits your use case in Confluent Cloud: | Feature / Aspect | VPC / VNet Peering | PrivateLink / Private Link / Private Service Connect | Transit Gateway (AWS) | Private Network Interface (AWS) | |---------------------------------------|---------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------| | **Primary Use Case** | Direct VPC/VNet connectivity | Secure service consumption | Centralized multi-VPC/hybrid connectivity | High-throughput private connectivity | | **Connectivity Direction** | Bidirectional | Unidirectional | Bidirectional | Bidirectional _[\*] | | **IP Address Overlap** | Not supported | Supported | Not supported | Supported | | **Transitive Routing** | No | N/A | Yes | Yes (hub-and-spoke architecture) | | **On-premises Connectivity** | No (requires proxy VMs) | Yes | Yes (via Direct Connect) | Yes (if the deployed VPC has on-premises connectivity) | | **Security Model** | Network-level isolation (customer-managed network connections;
distributed policy management) | Service-level isolation (customer-managed centralized, granular
policies; granular connections) | Network-level isolation (customer-managed network connections;
distributed policies or integrated with a central firewall) | Network-level isolation (customer-managed security groups; centralized,
granular policies) | | **Network Scalability** | Low (limited access from just peered VPCs/VNets) | High (private endpoint access from many VPCs/VNets) | Medium (hub-and-spoke access to many VPCs); | Medium (hub-and-spoke access to many VPCs) | | **Management Complexity** | High for many-to-many connections; DNS management | Simplified (no route tables); DNS setup | Simplified for multi-VPC; centralized routing; initial setup (AWS TGW
requires a ticket) | Simplified (granular interface-level management) | | **Performance** | Latency ranges from milliseconds to seconds, depending on cluster type | Latency ranges from milliseconds to seconds, depending on cluster type | Latency ranges from milliseconds to seconds, depending on cluster type | Latency ranges from milliseconds to seconds, depending on cluster type | | **Cost (data transfer)** | Low (inter-availability zone charges where applicable) | Medium (hourly endpoint fees + data processing) | High (hourly attachment fees + data processing) | Low ($0 when produce and consume are aligned in the same availability
zone; inter-availability zone charges where applicable) | | **Cost (data processing)** | None | Charge per gigabyte for consume and produce traffic | Charge per gigabyte for consume and produce traffic | None | | **Confluent Cloud Cluster Support** | Dedicated clusters | Dedicated clusters, Enterprise clusters | Dedicated clusters | Freight clusters, Enterprise clusters | | **Confluent Data Streaming Platform** | AWS: Flink, Schema Registry | AWS and Azure: Flink, Schema Registry | Flink, Schema Registry | AWS: Schema Registry | _[\*] On AWS, PNI connectivity for Freight and Enterprise clusters supports ingress to Kafka, egress from fully managed connectors, and ingress to Schema Registry. #### Select the right connectivity option based on use case Choosing the optimal private networking solution for Confluent Cloud and Kafka workloads requires a careful assessment of current needs and future architectural evolution. VPC/VNet Peering : This solution is best suited for simple, point-to-point connections between a limited number of VPCs/VNets and Confluent Cloud within the same region. It is ideal when IP address management is straightforward and transitive routing is not a requirement. This approach requires careful IP planning.
The primary benefit is its relative simplicity to configure for isolated connections and low latency.
However, a key difference is its lack of scalability compared to other solutions available in Confluent Cloud. As the number of customer VPCs grows, managing individual peering connections becomes cumbersome. Furthermore, peering connections are non-transitive, meaning your VPC cannot use the Confluent Cloud VPC as a transit point to reach other peered networks. Managed connectors will only be able to access resources residing in the peered VPC. Transit Gateway (AWS) : This is the preferred solution for complex, large-scale, multi-VPC environments, hybrid cloud scenarios, or when transitive routing is a core requirement. It significantly simplifies network architecture and management, and in AWS, it can handle overlapping CIDR blocks.
The main benefit is its ability to provide transitive routing, allowing your VPCs to communicate with each other through the Transit Gateway and offering a more manageable way to connect to Confluent Cloud. The key difference from peering is its enhanced scalability and simplified management for complex network topologies, though it introduces a slightly higher initial setup complexity.
Transit Gateway solutions are generally more expensive than direct VPC peering due to the per gigabyte charge for Transit Gateway data transfer.
Confluent Cloud supports migration from VPC peering to Transit Gateway as organizations outgrow simpler solutions.
Google Cloud users would typically leverage Cloud VPN in a hub-and-spoke model to achieve similar transitive capabilities. PrivateLink (AWS PrivateLink, Azure Private Link, Google Cloud Private Service Connect) : This solution is recommended for secure, service-level connectivity, particularly when IP address overlap is a concern or when strict data exfiltration protection is the highest priority. It is suitable for connecting many consumer VPCs to a single Confluent Cloud environment without introducing complex routing.
It provides the simplicity of connectivity and the ability to handle all network topologies at the added cloud provider costs. Private Network Interface (AWS) : Private Network Interface (PNI) can handle the highest throughput workloads at a fraction of the cost of Transit Gateway or PrivateLink. Additionally, for example, with an Enterprise cluster with PNI, you see benefits even for low to moderate throughput.
It also enables hub-and-spoke architectures like Transit Gateway and can be as secure as PrivateLink due to customer-managed security groups. The key benefit is the deep integration and simplified access, allowing you to manage Confluent Cloud traffic with the same network policies and tools you use for your internal resources. ## Confluent Cloud networks A Confluent Cloud network is an abstraction for a single tenant network environment that hosts the following Confluent Cloud services: * One or more [Dedicated clusters](../clusters/cluster-types.md#dedicated-cluster). After provisioning, a cluster cannot be moved to a different network. * Single tenant services * Managed connectors * ksqlDB clusters A Confluent Cloud network in some circumstances can also provide connectivity to the following serverless Confluent services. Refer to the table above for a specific support matrix. * Apache Flink® * Schema Registry A Confluent Cloud network is associated with one Confluent Cloud environment and can host clusters and applications within that environment. You cannot move a network to a different environment. A Confluent Cloud network includes the following features: * Support for private network connectivity with AWS PrivateLink, Azure Private Link, VPC peering, VNet peering, or AWS Transit Gateway. * Cloud-specific, regional, and spread across three zones. Zone selection for a Confluent Cloud network is supported in AWS and Google Cloud. The following RBAC roles can provision Confluent Cloud networks: * [NetworkAdmin](../security/access-control/rbac/predefined-rbac-roles.md#networkadmin-role) Can grant access to provision Confluent Cloud networks in all environments belonging to the organization. * [OrganizationAdmin](../security/access-control/rbac/predefined-rbac-roles.md#organizationadmin-role) Can grant access to provision Confluent Cloud networks in all environments belonging to the organization. * [EnvironmentAdmin](../security/access-control/rbac/predefined-rbac-roles.md#environmentadmin-role) Can only provision the Confluent Cloud networks for the assigned environments. You can create or delete a Confluent Cloud network on demand using: * Confluent Cloud Console * [Confluent Cloud Network REST API](https://docs.confluent.io/cloud/current/ccloud/networks-networking-v-1/) ### Deletion of idle Confluent Cloud networks An idle network is defined as a Confluent Cloud network that does not contain any physical resources, such as physical Kafka clusters. Idle networks are deleted after **60 days**. You will receive email communication and reminders prior to any deletion. #### Check for an idle Confluent Cloud network You can proactively check if or which of your Confluent Cloud networks are idle using the Confluent Cloud Console, Confluent REST API, or Confluent CLI. ### Confluent Cloud Console 1. In the **Network management** tab of your Confluent Cloud environment, click **For dedicated clusters** to get a table of Confluent Cloud networks. Check the following columns: * **State**: Indicates `Idle` when the network is not being provisioned and in the idle state. * **Connections**: Number of connections and clusters When no connection and no cluster exists in the network, you see the warning symbol. When you hover over the warning symbol for the network, you see how many days remain until this network is deleted. 2. Click a network name to open the network detail page. If the network is idle, the network detail page shows how many days are remaining before the network gets deleted. ### Confluent REST API **REST request** ```rest GET https://api.confluent.cloud/networking/v1/networks/ ``` **REST authentication** See [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). The `status` section of the response includes `idle_since` which is the timestamp of when the network became idle. ### Confluent CLI Use the [confluent network describe](https://docs.confluent.io/confluent-cli/current/command-reference/overview.html) Confluent CLI command to check the status of a Confluent Cloud network: ```bash confluent network describe ``` The output contains the `idle_since` field which is the timestamp of when the network became idle. #### Delete a Confluent Cloud network You can delete a Confluent Cloud network using the Confluent Cloud Console, Confluent REST API, or Confluent CLI. ### Confluent Cloud Console 1. In the **Network management** tab of your Confluent Cloud environment, click **For dedicated clusters** to get a table of Confluent Cloud networks. 2. Click a network name you want to delete. 3. Click **…** at the upper right side of the page, and select **Delete network**. 4. Specify the network ID, and click **Continue**. ### Confluent REST API **REST request** ```rest DELETE https://api.confluent.cloud/networking/v1/networks/ ``` **REST authentication** See [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). ### Confluent CLI Use the [confluent network delete](https://docs.confluent.io/confluent-cli/current/command-reference/overview.html) Confluent CLI command to delete a Confluent Cloud network: ```bash confluent network delete ```