BYOC Architecture

With Bring Your Own Cloud (BYOC) clusters, you deploy Redpanda in your own cloud (AWS, Azure, or GCP), and all data is contained in your own environment. This provides an additional layer of security and isolation. Redpanda handles provisioning, operations, and maintenance.

Control plane - data plane

For high availability, Redpanda Cloud uses the following control plane - data plane architecture:

Control plane and data plane

  • Control plane: This is where most cluster management, operations, and maintenance takes place. The control plane enforces rules in the data plane. You can use role-based access control (RBAC) in the control plane to manage access to organization-level resources like clusters, resource groups, and networks.

  • Data plane: This is where your cluster lives. The term data plane is sometimes used interchangeably with cluster. The data plane is where you manage topics, consumer groups, connectors, and schemas. You can use RBAC in the data plane to configure cluster-level permissions for provisioned users at scale.

IAM permissions allow the Redpanda Cloud agent to access the cloud provider API to create and manage cluster resources. The permissions follow the principle of least privilege, limiting access to only what is necessary.

Clusters are configured and maintained in the control plane, but they remain available even if the network connection to the control plane is lost.

In the Redpanda Cloud UI, you can identify which plane you’re in by the side navigation:

  • Control Plane: Visible after login at the organization level. Here you can select, create, and delete clusters, networks, and resource groups.

  • Data Plane: Visible after selecting a specific cluster. Here you can work with topics, consumer groups, connectors, and schemas.

BYOC setup

In a BYOC architecture, you deploy the data plane in your own VPC. All network connections into the data plane take place through either a public endpoint, or for private clusters, through Redpanda Cloud network connections such as VPC peering, AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. Customer data never leaves the data plane.

A BYOC cluster is initially set up from the control plane. This is a two-step process performed by rpk cloud byoc apply:

  1. You bootstrap a virtual machine (VM) in your VPC.

    This VM launches the agent and bootstraps the necessary infrastructure. Redpanda then assigns fine-grained IAM policies following least privilege, creating dedicated IAM roles per workload with only the permissions each requires.

  2. The agent communicates with the control plane to pull the cluster specifications.

    After the agent is up and running, it connects to the control plane and starts dequeuing and applying cluster specifications that provision, configure, and maintain clusters. The agent is in constant communication with the control plane, receiving and applying cluster specifications and exchanging cluster metadata. Agents are authenticated and authorized through opaque and ephemeral tokens, and they have dedicated job queues in the control plane. Agents also manage VPC peering networks.

    cloud_byoc_apply
To create a Redpanda cluster in your virtual private cloud (VPC), follow the instructions in the Redpanda Cloud UI. The UI contains the parameters necessary to successfully run rpk cloud byoc apply with your cloud provider.
Redpanda Cloud does not support customer access to the Kubernetes control plane with kubectl. This restriction allows Redpanda Data to manage all configuration changes internally to ensure a 99.99% service level agreement (SLA) for BYOC clusters.