Cloud

Choose Between BYOC and BYOVPC

Every Bring Your Own Cloud (BYOC) cluster runs the Redpanda data plane in your own cloud account, so your streaming data stays in your environment. The two variants (standard BYOC and BYOVPC/BYOVNet) differ in who creates and owns the infrastructure around the cluster.

With standard BYOC, Redpanda provisions the network, IAM, and storage resources for you in your account. With Bring Your Own Virtual Private Cloud (BYOVPC), called Bring Your Own Virtual Network (BYOVNet) on Azure, you create those resources in advance and the agent operates with only the permissions you grant. This page compares the two variants so you can decide before you create a cluster, because you cannot change the variant after creation.

After reading this page, you will be able to:

  • Compare who provisions and owns the VPC or VNet, IAM identities, and storage in standard BYOC versus BYOVPC

  • Identify the operational responsibilities that BYOVPC transfers to your team

  • Choose the BYOC variant that matches your compliance and network ownership requirements

Who provisions what

With standard BYOC, Redpanda creates and manages the required resources in your VPC or VNet, including subnets, IAM roles, security policies, and object storage resources such as S3 buckets or Azure storage accounts. When you create the cluster, you choose a CIDR range for the new Redpanda network; you do not supply an existing VPC or VNet. You grant the provisioning permissions to the Redpanda agent when you deploy it, and the agent creates dedicated IAM roles per workload, each with only the permissions that workload requires. For the full list of permissions and why each one is required, see the agent IAM policies for AWS, Azure, or GCP.

With BYOVPC, you create the networking and security resources in advance, including the VPC or VNet, subnets, IAM roles, and storage resources, so the agent does not create or change them. You also supply the identity that the agent uses: an IAM role (instance profile) on AWS, managed identities on Azure, or a service account on GCP. You manage that identity’s permissions yourself, so the standard agent IAM policies do not apply, and the agent’s access is limited to the permissions you grant.

In both variants, the agent deploys and operates the Redpanda cluster infrastructure in your account, and Redpanda manages provisioning, monitoring, and upgrades. For what the agent can and cannot access in either variant, see Redpanda Access to Your Environment.

Responsibility split

The following table summarizes the ownership differences that drive the decision. For the complete split, see the shared responsibility model.

Responsibility Standard BYOC BYOVPC/BYOVNet

VPC or VNet, subnets, routing, and firewall rules

Redpanda provisions and manages them in your account

You create and manage them (Redpanda’s subnet and CIDR requirements apply)

Agent identity and IAM roles

Redpanda creates per-workload IAM roles, scoped by the standard agent IAM policies

You supply the agent identity and manage its permissions

Tiered Storage bucket or container

Redpanda

You

Internet egress

Redpanda provisions a NAT gateway (Cloud NAT on GCP)

You provide the egress path

Redpanda deployment, upgrades, and hotfixes

Redpanda

Redpanda
You can own the egress path on a standard BYOC cluster too. On clusters with private networking, you can route all cluster egress through your own hub network instead of a Redpanda-provisioned NAT gateway. See the instructions for AWS, Azure, or GCP.

When to choose standard BYOC

Standard BYOC is the default choice. Choose it when:

  • Your policies do not require your team to own the network or IAM lifecycle. Standard BYOC already runs the data plane in your own cloud account, so you do not need BYOVPC for a secure deployment.

  • You want Redpanda to manage the network lifecycle end to end, so your team does not maintain subnets, routing, or security resources for the cluster.

  • You want the simpler setup. The Redpanda Cloud UI walks you through cluster creation, and the agent bootstraps the infrastructure for you.

  • Your main requirement is controlling egress rather than owning the whole network. Centralized egress can meet that requirement on a standard BYOC cluster.

When to choose BYOVPC

BYOVPC/BYOVNet is an add-on feature that requires Premium support. To unlock this feature for your account, contact your Redpanda account team or Redpanda Sales.

Choose BYOVPC (BYOVNet on Azure) when:

  • Your security policies require Redpanda to hold fewer permissions. You supply the identity that the agent uses and manage its permissions yourself, so the standard BYOC agent IAM policies do not apply.

  • Your policies require clusters to run inside a VPC or VNet that your organization creates and controls, such as an existing landing zone, or you need to control the CIDR ranges and subnet layout.

  • Your team manages network infrastructure as code and must keep that ownership, including subnets, route tables, firewall rules or security groups, and storage.

  • You need the tightest control over your environment and accept a more complex configuration and the Premium support requirement in exchange.

What BYOVPC adds operationally

BYOVPC shifts ongoing work to your team. Before you choose it, confirm that you can take on the following responsibilities:

  • Network lifecycle ownership: You create the VPC or VNet, subnets, routing, egress, and security resources before cluster creation, using the Redpanda-provided Terraform module for AWS, the Terraform code for Azure, or the gcloud setup steps for GCP, and you maintain them for the life of the cluster.

  • Identity and storage management: You create and manage the agent identity, the per-workload IAM roles and their assignments, and the Tiered Storage bucket or container. On Azure, you also manage the resource group, user-assigned identities, and key vaults.

  • Feature enablement: Redpanda Connect and secrets management differ by provider on BYOVPC clusters:

    • On AWS, the Terraform module enables secrets management and grants the permissions that Redpanda Connect requires by default for new clusters. For existing BYOVPC clusters, contact Redpanda Support to enable secrets management.

    • On Azure, Redpanda Connect is enabled when you create the cluster.

    • On GCP, the creation steps include both for new clusters: you create the required service accounts during setup. For existing BYOVPC clusters, enable Redpanda Connect and secrets management yourself.

Switching later

You cannot change the variant after you create the cluster:

  • You cannot convert an existing cluster to a BYOVPC or BYOVNet cluster.

  • After creating a BYOVPC or BYOVNet cluster, you cannot change to a different VPC or VNet.

If you might need BYOVPC later, decide before you create the cluster.

Next steps