Docs Cloud Networking Network Design, Ports, and Flows Network Design, Ports, and Flows Redpanda Cloud deploys two different types of networks: one for private Redpanda clusters and one for public Redpanda clusters. By default, networks are always laid out across multiple availability zones (AZs) to enable the creation of one or many single and multi-AZ Redpanda clusters within them. With both private and public Redpanda clusters, TCP listeners are protected by SASL/SCRAM (SCRAM-SHA-256, SCRAM-SHA-512) authentication and encrypted in transit using TLS 1.2. Public Redpanda clusters The following diagram shows the public subnet used by public Redpanda clusters. Private Redpanda clusters Private Redpanda clusters are designed based on the following behaviors: There is proper network segmentation. All Redpanda services are only accessible from within the same VPC or through VPC peering. The data plane agent is placed in public subnets and segmented away by firewall rules from Redpanda services. The following diagram shows the private subnet used by private Redpanda clusters. Network ports This section lists the external ports on which Redpanda Cloud components communicate. Redpanda manages security group and firewall configurations on your behalf, but if you need to add to your own rule sets, these are the available network ports. Redpanda also uses some ports for internal communication inside the cluster, including ports 80, 8081, 8082, and 9644. North-South The following table lists the network ports available to external clients within each data plane. For private-only Redpanda clusters, access to these ports is only possible through Redpanda Cloud network connections such as VPC peering, transit gateway attachments, or Private Links/Private Service Connect. Service Port Kafka API 30092/tcp Kafka bootstrap 9092/tcp Schema Registry 30081/tcp HTTP Proxy 30082/tcp Redpanda Console, Prometheus metrics 443/tcp East-West The following table lists the network ports available within each data plane for internal communication only. Service Port Kafka API 30092/tcp Kafka bootstrap 9092/tcp Schema Registry 30081/tcp HTTP Proxy 30082/tcp Redpanda Console 33145/tcp Redpanda Admin API 30644/tcp Kafka Connect API 8083/tcp South-North The following network port is used for outgoing network connections outside the VPC. DNS and NTP ports are not included because those network flows do not leave the cloud provider’s network, and they reach the internal cloud provider services within the VPC. Service Port Control plane, breakglass, artifact repository 443/tcp AWS network services Redpanda Cloud supports the following Amazon Web Services (AWS) network services: Time synchronization To ensure time synchronization, Redpanda Cloud in AWS uses the Amazon Time Sync Service, a fleet of redundant satellite-connected and atomic reference clocks in AWS regions. Domain Name System (DNS) Redpanda Cloud creates a new DNS zone for each cluster in the control plane and delegates its management exclusively to each cluster’s data plane. In turn, the data plane creates a hosted zone in Route 53, managing DNS records for Redpanda services as needed. All interactions with Route 53 are controlled by IAM policies targeted to the specific Route 53 resources managed by each data plane, following the least privilege principle. Distributed denial of service (DDoS) protection All Redpanda Cloud services publicly exposed in the control plane and data plane are protected against the most common layer 3 and 4 DDoS attacks by AWS Shield Standard, with no latency impact. VPC peering Redpanda Cloud supports configuring VPC peering against Redpanda Cloud networks, making them available to one or many private clusters and allowing users to connect to those clusters without traversing the public internet. You can establish VPC peering connections between two VPCs with non-overlapping network addresses. When creating a network intended for peering, ensure that the specified network address range does not overlap with the network address range of the destination VPC. It is strongly recommended to reject all network traffic initiated from a Redpanda Cloud network and only accept traffic from Kafka connectors that connect to your internal data stores to retrieve or push data. GCP network services Redpanda Cloud supports the following Google Cloud Platform (GCP) network services: Time synchronization To ensure time synchronization, Redpanda Cloud in GCP uses Google NTP Servers, a fleet of satellite-connected and atomic reference clocks. Domain Name System (DNS) Redpanda Cloud creates a new DNS zone for each cluster in the control plane and delegates its management exclusively to each cluster’s data plane. In turn, the data plane creates a managed zone in Cloud DNS, managing DNS records for Redpanda services, as needed. All the interactions with Cloud DNS are controlled by IAM policies targeted to the specific Cloud DNS resources managed by each data plane, following the least privilege principle. VPC peering Redpanda Cloud supports configuring VPC peering against Redpanda Cloud networks, making them available to one or many private Redpanda clusters and allowing users to connect to those clusters without traversing the public internet. You can establish VPC peering connections between two VPCs with non-overlapping network addresses. When creating a network intended for peering, ensure that the specified network address range does not overlap with the network address range of the destination VPC. It is strongly recommended to reject all network traffic initiated from a Redpanda Cloud network and only accept traffic from Kafka connectors that connect to your internal data stores to retrieve or push data. Azure network services Redpanda Cloud supports the following Azure network services: Time synchronization To ensure time synchronization, Redpanda Cloud in Azure uses Microsoft time sync. Domain Name System (DNS) Redpanda Cloud creates a new DNS zone for each cluster in the control plane and delegates its management exclusively to each cluster’s data plane. In turn, the data plane creates a managed zone in Azure DNS, managing DNS records for Redpanda services, as needed. All the interactions with Azure DNS are controlled by Azure RBAC policies targeted to the specific Azure DNS resources managed by each data plane, following the least privilege principle. Back to top × Simple online edits For simple changes, such as fixing a typo, you can edit the content directly on GitHub. Edit on GitHub Or, open an issue to let us know about something that you want us to change. Open an issue Contribution guide For extensive content updates, or if you prefer to work locally, read our contribution guide . Was this helpful? thumb_up thumb_down group Ask in the community mail Share your feedback group_add Make a contribution Networking Choose CIDR Ranges