Skip to content

SYSTEM Cited by 1 source

Redpanda BYOVPC

Redpanda BYOVPC (Bring Your Own VPC) is the deployment mode on Redpanda Cloud where the customer pre-provisions the entire AWS substrate (VPC + subnets + security groups + IAM roles + instance profiles + tiered-storage S3 bucket) and the Redpanda Cloud agent deploys the data plane into that substrate without creating any new networking or IAM resources in the customer's account. GA for AWS as of 2026-03-11 (Source: sources/2026-03-11-redpanda-redpanda-clouds-byovpc-for-aws-is-now-generally-available).

Verbatim (Source: post intro):

"With BYOVPC, you supply and manage your own VPC (virtual private cloud). Redpanda then deploys its data plane into your VPC, using your subnets, your IAM roles, and your security policies. The Redpanda Cloud agent doesn't create any new networking or IAM resources in your account; it simply runs within the environment you've defined."

BYOC vs BYOVPC (resource-ownership axis)

BYOVPC is a strict refinement of BYOC: BYOC already runs the data plane inside the customer's AWS account, but Redpanda provisions and manages the supporting networking + IAM + storage resources. BYOVPC transfers that provisioning authority back to the customer. The 2026-03-11 post's verbatim comparison table (reproduced):

Resource BYOC BYOVPC
VPC Created by Redpanda Pre-provisioned by you
Subnets Created by Redpanda Pre-provisioned by you
Security groups Created and managed by Redpanda Pre-provisioned and managed by you
IAM roles & instance profiles Created by Redpanda Pre-provisioned by you
S3 buckets (Tiered Storage) Created by Redpanda Pre-provisioned by you
Redpanda IAM footprint Broader (needs to create resources) Minimal (read/write only)

The last row — Redpanda IAM footprint reducing from "broader (needs to create resources)" to "minimal (read/write only)" — is the load-bearing commercial value proposition, canonicalised as concepts/customer-managed-iam-footprint-minimization.

Why teams choose BYOVPC

Four reasons enumerated in the GA post (Source: "Why teams choose BYOVPC" section):

  1. Full ownership of VPC, subnets, IAM roles, firewall rules, storage buckets.
  2. Reduced IAM footprint for Redpanda — "fewer permissions means a smaller blast radius" (verbatim).
  3. Seamless integration with existing VPCs, transit gateways, and PrivateLink configurations — BYOVPC composes with customer's pre-existing hub-and-spoke network topology, cross-VPC peering, on-prem Direct Connect, etc.
  4. Support for condition tags for fine-grained IAM controls based on AWS resource tags — see concepts/condition-tag-iam. Secrets management is enabled by default, allowing secure integration with REST catalogs and Iceberg-enabled topics.

Security group profiles

BYOVPC accommodates layered enterprise security posture where organisations manage security via pre-approved security group profiles reflecting environment tiers (prod vs staging) or application roles (broker, agent, client). Verbatim (Source: post):

"BYOVPC lets you attach these pre-approved profiles to Redpanda's resources, ensuring Redpanda fits into your existing security model rather than operating alongside it."

Canonicalised as concepts/security-group-profile. BYOC can't accommodate this pattern because Redpanda owns the SG rules.

Subnet placement flexibility

Customer chooses subnets + AZ placement for both the Redpanda broker data plane and the Redpanda Cloud agent. Supports:

  • Private subnets behind NAT gateway
  • Subnets routed through Transit Gateway (hub-and-spoke topologies)
  • Subnets peered with on-premises networks (via PrivateLink or Direct Connect)
  • Strict AZ-placement policies (e.g. per-AZ isolation for blast-radius).

This is the "seamless integration" axis of the BYOVPC value prop.

Tiered-storage S3 buckets under customer control

Verbatim (Source: post):

"With BYOVPC, you provision your own S3 buckets and apply your own bucket policies, lifecycle rules, server-side encryption settings, and S3 Block Public Access configurations. Redpanda simply writes to and reads from the bucket you've defined — no bucket policies are ever modified by Redpanda."

Extends concepts/byoc-data-ownership-for-iceberg (which the 2025-05-13 BYOC Iceberg Topics beta canonicalised for Iceberg Parquet + metadata) to all tiered-storage log segments — the customer's S3 bucket is the substrate for both Iceberg Topic output and the base tiered-storage feature.

The GA post "formally establishes" the terraform-aws-redpanda-byovpc module as the recommended provisioning path — see systems/redpanda-terraform-aws-byovpc-module. The module provisions the five workload-specific IAM instance profiles, seven security groups, EKS cluster IAM role, VPC + subnets, S3 bucket (pre-configured with encryption + bucket policies), optional PrivateLink, and optional Redpanda Connect enablement.

The module exposes variables for every resource, so any resource the customer has already provisioned in their environment can be passed in by ID/ARN and skipped in the module. This is the composition hook that lets enterprise platform teams with centrally-managed networking/IAM/storage use the module as a partial substrate provider.

Provisioning flow (four phases)

From the "high-level provisioning flow" section:

  1. Re-use existing AWS resources or configure/deploy via the Terraform module: define a tfvars JSON with VPC ID + AWS account ID + region + subnet CIDRs + optional flags (PrivateLink, Redpanda Connect enablement).
  2. Create the network + cluster via Redpanda's Terraform provider: redpanda_network + redpanda_cluster resources consume outputs from the module, then hand off control to the Redpanda Cloud agent. An example is linked in the post.

The post's Terraform code block wires the following outputs from module.redpanda_byovpc into the redpanda_cluster customer_managed_resources.aws block: permissions_boundary_policy_arn, agent_instance_profile_arn, connectors_node_group_instance_profile_arn, utility_node_group_instance_profile_arn, redpanda_node_group_instance_profile_arn, k8s_cluster_role_arn, redpanda_agent_security_group_arn, connectors_security_group_arn, redpanda_node_group_security_group_arn, utility_security_group_arn, cluster_security_group_arn, node_security_group_arn, cloud_storage_bucket_arn, + for network: management_bucket_arn, dynamodb_table_arn, vpc_arn, private_subnet_arns.

GA capabilities

From the "What's included in BYOVPC GA" section:

  • Full public + private connectivity, including PrivateLink + Transit Gateway.
  • Secrets management enabled by default through Terraform provisioning.
  • Custom tagging up to 16 tags via Cloud API (cost allocation + audit compliance + governance).
  • Automated pre-flight validation checks at deploy time that surface missing permissions or misconfigured resources.
  • Redpanda Connect support inside BYOVPC clusters (enabled by default, configurable).

Relationship to other Redpanda deployment modes

  • BYOC — broader resource ownership by Redpanda, less customer substrate responsibility. BYOC is the superset; BYOVPC is the stricter refinement.
  • Redpanda Cloud Dedicated — data plane
  • control plane in Redpanda's AWS/GCP/Azure account. BYOVPC and BYOC both keep data plane in customer account; Dedicated does not.
  • Redpanda Self-Managed — customer runs everything including the control plane; no Redpanda Cloud agent. BYOVPC keeps the Cloud-managed control plane while transferring substrate provisioning back to the customer.

Single managed-service-axis taxonomy:

Model Data plane Control plane Substrate provisioning
Redpanda Cloud Dedicated Redpanda account Redpanda account Redpanda
BYOC Customer account Redpanda account Redpanda
BYOVPC Customer account Redpanda account Customer
Self-Managed Customer Customer Customer

Caveats

  • AWS-only GA as of 2026-03-11. GCP and Azure BYOVPC status not disclosed.
  • Premium-support gated. "Available now to all Redpanda Cloud customers with premium support" — commercial gating, contact account team / Sales.
  • Mechanism shallow on pre-flight validation. The "automated validation checks" detect missing permissions + misconfigured resources, but the specific permissions-check matrix + failure classification is not disclosed.
  • IAM footprint reduction is qualitative. "Minimal (read/write only)" vs "broader" framed at the capability altitude; no enumeration of AWS actions retained vs dropped in BYOVPC.
  • Security-group-profile attachment mechanism shallow. How profile ARNs are passed to the Terraform module or the Redpanda provider API (vs individual SG ARNs) is not detailed.
  • Platform-team collaboration flow not walked through. The hand-off between platform team (pre-provisioner) and operator team (cluster creator) is left to implementation.
  • Launch-announcement voice — no customer references, no production fleet numbers, no cost-reduction figures.

Seen in

  • sources/2026-03-11-redpanda-redpanda-clouds-byovpc-for-aws-is-now-generally-available — canonical GA-announcement introduction. BYOVPC for AWS moves beta → GA on Redpanda Cloud. Canonicalises the six-axis resource-ownership comparison table with BYOC, the security- group-profile accommodation, the tiered-storage S3 bucket ownership extension, the condition-tag IAM support, the Terraform module + four-phase provisioning flow, and the five- workload-type IAM instance profile + seven-SG enumeration.
Last updated · 470 distilled / 1,213 read