REDPANDA 2026-03-11

Redpanda — Redpanda Cloud's BYOVPC for AWS is now Generally Available¶

Summary¶

Redpanda's 2026-03-11 unsigned launch-announcement post moves Bring Your Own VPC (BYOVPC) for AWS from beta to GA on Redpanda Cloud. BYOVPC is positioned as the "one step further" deployment mode beyond BYOC (Bring Your Own Cloud): instead of Redpanda creating VPC / subnets / security groups / IAM roles / S3 buckets inside the customer's AWS account, the customer pre-provisions every one of those resources and Redpanda's cloud agent deploys the data plane into that pre-existing substrate without creating any new networking or IAM resources. The post canonicalises a resource-ownership comparison table across six resources (VPC, subnets, security groups, IAM roles, S3 buckets, Redpanda IAM footprint), formally establishes terraform-aws-redpanda-byovpc as the recommended provisioning path, and enumerates GA-grade capabilities (PrivateLink + Transit Gateway support, secrets management by default, up-to-16 custom tags, automated pre-flight validation checks, Redpanda Connect inside BYOVPC).

Key takeaways¶

BYOVPC = BYOC + customer-owned networking/IAM/storage. Verbatim: "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." This is a strict refinement of BYOC's "customer-owned data-plane-compute" topology: BYOC has Redpanda provisioning all the supporting resources (VPC, subnets, SGs, IAM, S3) while BYOVPC requires the customer to pre-provision all of them. See systems/redpanda-byovpc + systems/redpanda-byoc.
Resource-ownership comparison across six axes (Source: verbatim table in post). BYOC vs BYOVPC ownership:
VPC: created by Redpanda / pre-provisioned by customer
Subnets: created by Redpanda / pre-provisioned by customer
Security groups: created+managed by Redpanda / pre-provisioned+managed by customer
IAM roles & instance profiles: created by Redpanda / pre-provisioned by customer
S3 buckets (tiered storage): created by Redpanda / pre-provisioned by customer
Redpanda IAM footprint: broader (needs to create resources) / minimal (read/write only). The last axis is the load-bearing commercial value proposition, canonicalised as concepts/customer-managed-iam-footprint-minimization.
Security group profiles accommodate layered enterprise security posture. Verbatim: "Rather than a flat set of rules, many organizations manage security posture through layered security group profiles that reflect environment tiers (e.g., prod vs. staging) or application roles (e.g., broker, agent, client). 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's Redpanda-managed security groups can't integrate with such profile schemes because Redpanda owns the rules.
Tiered-storage S3 buckets stay under customer's bucket policies + lifecycle rules + encryption + BPA settings. Verbatim: "Redpanda uses S3 for tiered storage, offloading older log segments to object storage to dramatically reduce broker disk requirements. 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." The same property that the 2025-05-13 BYOC Iceberg Topics beta canonicalised for Iceberg data files on object storage (concepts/byoc-data-ownership-for-iceberg) applies here to tiered-storage log segments.
Condition tags for fine-grained IAM enablement. Verbatim: "Support for condition tags for fine-grained IAM controls based on AWS resource tags." Canonicalised as concepts/condition-tag-iam — the AWS IAM primitive of using resource tags inside IAM Condition elements to attenuate what Redpanda's role can act on even within the permissions it holds.
Terraform formally established as the recommended BYOVPC provisioning path. Verbatim: "Alongside the GA announcement, we're formally establishing Terraform as the recommended provisioning path for BYOVPC clusters on AWS." Canonicalised as systems/redpanda-terraform-aws-byovpc-module + patterns/terraform-module-as-byoc-provisioning-path. The terraform-aws-redpanda-byovpc module is "a complete, opinionated module" provisioning: VPC + subnet CIDRs across AZs, IAM instance profiles for five workload types (agent, redpanda, utility, connectors, optionally redpanda_connect) each scoped to exactly what the component needs, the EKS cluster IAM role (k8s_cluster_role), seven security groups with sensible defaults, S3 bucket for tiered storage pre-configured with encryption + bucket policies, optional PrivateLink, optional Redpanda Connect enablement.
Module variables skip resources already provisioned. Verbatim: "Variables are provided throughout, so you can skip the creation of any resource that already exists in your environment. If your platform team has already provisioned a VPC with approved subnets, simply pass those IDs as inputs, and the module skips that step entirely. The same applies to the S3 bucket, security groups, and IAM roles — bring what you have, let Terraform create what you don't." This is the customer- preprovisioning-substrate composition hook — enterprise platform teams with centrally-managed networking/IAM/storage can use the Terraform module as a partial substrate provider.
Four-phase provisioning flow. (a) Re-use or configure via the terraform module: define a tfvars JSON file with VPC ID + AWS account ID + region + subnet CIDRs + optional PrivateLink / Redpanda Connect flags. (b) Create the network + cluster via the Redpanda Terraform provider: redpanda_network + redpanda_cluster resources consume the outputs from the module (management bucket ARN, DynamoDB table ARN, VPC ARN, private subnet ARNs, permissions-boundary policy ARN, all instance-profile ARNs, k8s cluster role ARN, all seven security-group ARNs, cloud storage bucket ARN). The full code block in the post demonstrates every required output-to-input wiring. example for provisioning a BYOVPC cluster.
Four-reason Terraform recommendation. (a) Repeatability — define infrastructure once, deploy consistently across environments; (b) Auditability — changes tracked in version control, compliance reviews straightforward; (c) Flexibility — customize every aspect via input variables (CIDR ranges, PrivateLink settings); (d) Speed — a single terraform apply provisions the full suite + outputs the ARNs needed for cluster creation.
GA feature surface: (a) full private + public connectivity including PrivateLink + Transit Gateway; (b) secrets management enabled by default via Terraform (supports REST catalogs + Iceberg-enabled topics integration — bridges to systems/redpanda-iceberg-topics); (c) custom tagging up to 16 tags via Cloud API for cost allocation / audit / governance; (d) automated pre-flight validation checks at deploy time surface missing permissions or misconfigured resources; (e) Redpanda Connect support inside BYOVPC clusters (enabled by default, configurable).

Systems + concepts + patterns canonicalised¶

Systems (new)¶

systems/redpanda-byovpc — the BYOVPC deployment mode itself, distinguished from BYOC along the resource-ownership axis.
systems/redpanda-terraform-aws-byovpc-module — the terraform-aws-redpanda-byovpc module canonicalised as the recommended provisioning path.

Concepts (new)¶

concepts/customer-managed-iam-footprint-minimization — the architectural value prop of reducing the vendor's IAM blast radius by transferring resource-creation privileges back to the customer.
concepts/security-group-profile — layered, pre-approved SG sets reflecting environment tiers or application roles, as a security posture abstraction BYOVPC accommodates by accepting customer-attached profiles rather than managing its own SGs.
concepts/condition-tag-iam — AWS IAM Condition elements keyed on resource tags for tag-aware fine-grained access control.

Patterns (new)¶

patterns/customer-preprovisioned-network-substrate — the composed pattern where the vendor's data plane ships into a customer-owned substrate (VPC + subnets + SGs + IAM + S3) rather than provisioning it.
patterns/terraform-module-as-byoc-provisioning-path — the vendor publishes an opinionated Terraform module that provisions the full BYOC/BYOVPC substrate, with variables that allow skipping any resource the customer already has.

Pages extended¶

systems/redpanda-byoc — canonical BYOVPC reference added as a stricter refinement of the BYOC topology.
systems/redpanda-cloud — BYOVPC added as a BYOC sub-model.
concepts/byoc-data-ownership-for-iceberg — generalised from Iceberg-data-only to tiered-storage + Iceberg-data + customer- managed-bucket-policies via the new BYOVPC S3-provisioning surface.
companies/redpanda — Recent articles entry + frontmatter.

Operational numbers¶

5 workload types each with its own IAM instance profile: agent, redpanda, utility, connectors, optionally redpanda_connect.
7 security groups (SGs) provisioned by the Terraform module: redpanda_agent_security_group, connectors_security_group, redpanda_node_group_security_group, utility_security_group, cluster_security_group, node_security_group — plus one implied in the module name that the post doesn't explicitly list ("Security groups (7), with sensible defaults you can customize before applying").
Up to 16 custom tags via the Cloud API for cost allocation, audit compliance, governance policies.

Caveats¶

Launch-announcement voice, no production customer references or fleet numbers. Zero latency / throughput / cost-reduction figures.
AWS-only. The post is scoped to AWS BYOVPC GA; GCP and Azure BYOVPC status not discussed.
Mechanism depth shallow on pre-flight validation. "Automated validation checks at deploy time" named but mechanism (what permissions are checked, how misconfigured resources are detected) not disclosed.
IAM footprint reduction unquantified. "Minimal (read/write only)" vs "broader (needs to create resources)" framed qualitatively; no enumeration of which AWS actions are dropped in BYOVPC vs retained in BYOC.
Platform-team-collaboration flow not walked through. The four-phase provisioning assumes the customer's platform team has either pre-approved the Terraform module's defaults or has already provisioned some resources elsewhere. The hand-off protocol between platform team (pre-provisioner) and operator team (cluster creator) is not discussed.
Premium support prerequisite. Closing line verbatim: "BYOVPC for AWS is available now to all Redpanda Cloud customers with premium support. To unlock this feature for your account, contact your Redpanda account team or reach out to Redpanda Sales." — commercial gating, not a self-service product surface.
Transit Gateway + PrivateLink named as supported, not walked through. "Full support for private and public connectivity, including PrivateLink and Transit Gateway" is a capability assertion; the integration pattern (Redpanda inside one VPC, application VPCs peered via TGW, PrivateLink endpoints for cross-account producer/consumer access) is not detailed.
Security group profile mechanism shallow. The "pre-approved profiles" attachment mechanism is framed at the AWS-feature altitude (AWS security-group profiles) without detailing how the Terraform module or Redpanda API accepts profile ARNs vs SG ARNs.
Unsigned (Redpanda default attribution) and launch-voice marketing post; passes Tier-3 scope filter on vocabulary-canonicalisation grounds (resource-ownership table + five-workload IAM enumeration + security-group-profile concept + Terraform-as-provisioning-path formalization) rather than production-retrospective density.

Cross-source continuity¶

Deployment-topology refinement of the 2025-04-03 canonical BYOC retrospective (sources/2025-04-03-redpanda-autonomy-is-the-future-of-infrastructure). BYOC's central property (customer data-plane-in-customer-VPC) was that post's emphasis; BYOVPC extends that property deeper (customer VPC + subnets + SGs + IAM + S3 are all also customer-provisioned).
Storage-ownership companion to the 2025-05-13 BYOC Iceberg Topics beta (sources/2025-05-13-redpanda-getting-started-with-iceberg-topics-on-redpanda-byoc). That post canonicalised customer-owned buckets for Iceberg Parquet + metadata files; this post extends the same customer-bucket-ownership property to tiered-storage log segments and enumerates the customer-managed bucket policies (encryption, lifecycle, S3 Block Public Access) that stay in customer hands.
Substrate companion to the 2025-05-06 Kubernetes guide (sources/2025-05-06-redpanda-a-guide-to-redpanda-on-kubernetes). The Kubernetes guide canonicalised Redpanda's K8s operator path for Self-Managed; BYOVPC canonicalises the Redpanda Cloud + Terraform path for customer-provisioned substrate on AWS.