Custom Domains and Network Isolation in Confluent Private Cloud Gateway

Confluent Private Cloud Gateway (Confluent Gateway) maps Apache Kafka® listener endpoints to custom domains and isolates network traffic using private networking. Together, these features let you expose branded endpoints to clients, restrict access by policy, and separate internal broker networks from external access. Both capabilities help you grant external partners access to Kafka clusters in compliance with your policies.

Custom domain: A custom domain is an isolated pathway with its own entry point (endpoint), routing logic, and security enforcement. Custom domains provide the framework for network isolation. By configuring multiple custom domains, you can create isolated network segments for different clients, departments, or applications—all controlled by Confluent Gateway, removing the need for physical separation or complex client configuration.
Network isolation: Kafka brokers stay on a private network, unreachable directly by external clients. Confluent Gateway acts as the proxy access point and enforces controlled entry.

Custom domain routing flow

Custom-domain routing follows the following path from client to broker:

The client resolves the custom domain name to a Confluent Gateway IP address using DNS (for example, AWS Route 53 or Azure Private DNS Zones).
The client connects to Confluent Gateway using the resolved IP, presenting the custom domain in the connection’s SNI header (for host-based routing) or using the broker-specific port (for port-based routing).
Confluent Gateway matches the connection against a configured Route, applies the Route’s security policy, and identifies the target broker.
Confluent Gateway forwards the request to the appropriate Kafka broker on its private network.

The Kafka brokers stay on the private network and are never directly reachable by clients. Confluent Gateway is the only public entry point.

For configuration details, see Configure and Deploy Confluent Private Cloud Gateway using Docker.

Set up custom domains and network isolation

Set up a custom domain and network isolation in three steps: configure host resolution, update Confluent Gateway’s endpoint, and restart it.

For a complete example, see the custom-domains-and-network-isolation example in the gateway-images repository.

Set up host resolution for the custom domain

Configure network and DNS so that clients can resolve the custom domain to Confluent Gateway’s IP address. In production, use a DNS service such as AWS Route 53 or Azure Private DNS Zones. For local development only, map the custom domain in the /etc/hosts file.

Kafka clients and Confluent Gateway in the same VPC

Create a private hosted zone (or DNS zone) in the VPC and create DNS records pointing to the private IP of the Confluent Gateway instance.

Kafka clients and Confluent Gateway in different VPCs

Enable connectivity between the VPCs using Peering, Transit Gateway, or Private Link.
Use the same private hosted zone (or DNS zone) and associate it with both VPCs.
Create DNS records pointing to the private IP of the Confluent Gateway instance.

Kafka clients on an external network

Create a public hosted zone (or DNS zone).
Create DNS records pointing to the public IP of the Confluent Gateway instance.

For details on creating a DNS zone and DNS records, see:

Configure Confluent Gateway to use the custom domain

Update your Confluent Gateway configuration so that the routes use the custom domain name as their endpoint.

routes:
  - name:
    endpoint:        --- [1]

[1] Specify the same custom domain name you set up for host resolution, followed by the port.

Restart Confluent Gateway

Restart the Confluent Gateway instance to apply the changes.

For Docker deployments:

docker compose -f docker-compose.yaml up -d

For CFK deployments:

kubectl apply -f <gateway_cr.yaml>

The restart results in client disconnections and reconnections.

AWS Route 53 example setup

AWS Route 53 setup configures custom-domain routing and network isolation when Confluent Gateway and Kafka clients share an AWS VPC and no public access is required. The following procedure uses a private Route 53 hosted zone.

Browse to AWS Console → Route 53 → Create Hosted Zone.
Select Private Hosted Zone, and enter your custom domain name (for example, mycluster-proxy-route53.kafka).
Associate the VPC where both Confluent Gateway and Kafka clients run (for example, <vpc-id>).
Ensure the VPC has DNS Resolution and DNS Hostnames enabled.
Inside the hosted zone, create A records pointing to the private IP of the Confluent Gateway EC2 instance (for example, 10.0.3.140):
- mycluster-proxy-route53.kafka → 10.0.3.140
- *.mycluster-proxy-route53.kafka → 10.0.3.140
  The wildcard A record is needed when brokerIdentificationStrategy.type is host in gateway.yaml. For more information, see Routes configuration.

Modify the Confluent Gateway configuration file to use the custom domain.

The following is an example configuration using the sample values from the preceding steps. For production, prefer IAM roles over the static accessKey and secretKey shown below. See Secret store configuration.

secretStores:
  - name: AWS
    provider:
      type: AWS
      config:
        region: us-east-1
        accessKey: <AWS_ACCESS_KEY>
        secretKey: <AWS_SECRET_KEY>
        separator: /
streamingDomains:
  - name: sample-domain
    type: kafka
    kafkaCluster:
      name: kafka-cluster-1
      bootstrapServers:
        - id: SASL_SSL-1
          endpoint: <KAFKA_BROKER_HOST:PORT>
routes:
  - name: sasl-plain-to-sasl-plain
    endpoint: mycluster-proxy-route53.kafka:10000
    brokerIdentificationStrategy:
      type: host
      pattern: "broker$(nodeId).mycluster-proxy-route53.kafka"
    streamingDomain:
      name: sample-domain
      bootstrapServerId: SASL_SSL-1

Start the Confluent Gateway instance and test producing and consuming.