Manage Networking for Confluent Cloud Connectors

Consider the following when determining the public Internet access configuration for resources that fully-managed connectors must access. For Confluent Cloud networking details, see the Cloud Networking docs.

Networking

The following tabs provide network connectivity IP address details. Note that a Connect node runs in the same VPC/VNet as the cluster the Connect node was provisioned with. This is true for all cluster types (Basic, Standard, Enterprise and Dedicated). For Confluent Cloud networking details, see the Cloud Networking docs.

Note

The following information applies to a fully-managed Sink or Source connector connecting to an external system using a public IP address.

Cluster network type Public IP address connectivity IP range used by the connector
Public Endpoint Yes A set of public egress IP addresses (see Public Egress IP Addresses for Confluent Cloud Connectors)
VPC Peering and Transit Gateway Yes Dynamic public IP/CIDR range from the cloud provider region where the Confluent Cloud cluster is located
Private Link Yes Dynamic public IP/CIDR range from the cloud provider region where the Confluent Cloud cluster is located

Note

See the following cloud provider documentation for additional information:

DNS considerations

Fully qualified domain names: Some services require fully qualified domain names (FQDNs) to access the service. In order for a fully-managed connector to access such a service, the service must use public DNS records pointing to the IP address (public or private). Private DNS zones are not supported in Confluent Cloud.

Private service endpoints: Cloud service providers offer the ability to set up private endpoints with custom or vanity DNS names for native cloud provider services. Private endpoints are only supported if the provider supports resolving the endpoints using public DNS.

Service and gateway endpoints

Azure service endpoints and AWS gateway endpoints provide secure and direct private connectivity to Azure and AWS services over the cloud provider network backbone using an optimized route. These endpoints are located in the Confluent Cloud VPC/Vnet.

Managed connector network traffic is routed over cloud service provider (CSP) secure public endpoints for the following services:

AWS
Azure
  • Azure Blob Storage
  • Azure Cosmos DB
  • Azure Event Hubs
  • Azure Service Bus
  • Microsoft SQL Server

Private hosted services and peered VPCs

Under certain scenarios you must use a proxy configuration to allow a connector to attach to a database, storage, or other service running on a private host. A specific scenario for using a proxy is when Kafka clusters are in a peered VPC configuration and a connector needs to attach to a non-peered VPC. This is because peering network connectivity is non-transitive so the connector cannot attach to endpoints in the non-peered VPC.

The following shows an example of this scenario on GCP where a proxy configuration is required.

There are the following three VPCs running on GCP:

  • VPC A: The Confluent Cloud VPC.
  • VPC B: The customer VPC.
  • VPC C: The Cloud SQL VPC.

In this configuration, there is no transitive peering from VPC A to the private Cloud SQL database running on VPC C. For the connector to be able to attach to the database, a proxy client is added to VPC B so the connector can attach to a proxy server added to VPC C. For more information about setting up this GCP proxy configuration, see How the Cloud SQL Auth proxy works).

Note

AWS Transit Gateway (TGW) clusters do not have this transitive issue unless there is a third VPC to connect to. For example, Confluent Cloud VPC A > TGW > Customer VPC B > Customer VPC C (or a cloud service VPC C as shown in the GCP example scenario).

For Confluent Cloud networking details, see the Cloud Networking docs.