Redpanda Cloud’s BYOVPC for AWS is now Generally Available

Take full control of your networking with Redpanda Cloud’s BYOVPC model—now GA on AWS.

March 11, 2026
Last modified on
TL;DR Takeaways:
No items found.
Learn more at Redpanda University

We’re excited to announce that Bring Your Own VPC (BYOVPC) for AWS is now Generally Available (GA)! After a period in beta, BYOVPC is ready for production workloads, giving your team the advanced networking control it needs without sacrificing the managed experience you love about Redpanda Cloud.

Here’s everything you need to know about BYOVPC and how to get started. 

What is BYOVPC?

Redpanda Cloud offers a deployment model called BYOC (Bring Your Own Cloud), which Redpanda deploys into your AWS account while managing networking on your behalf. This is a great option for teams that want cloud isolation without the overhead of managing network infrastructure themselves.

BYOVPC goes one step further. 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

On the surface, both models deploy Redpanda into your AWS account and keep your data out of Redpanda's infrastructure. But the difference in who owns what is substantial.

With BYOC, Redpanda creates and fully manages the networking layer inside your account. That means Redpanda provisions and controls:

  • VPCs and subnets
  • Security groups and firewall rules
  • IAM roles and instance profiles
  • S3 buckets for tiered storage and cluster metadata

This is a great fit for teams that want strong cloud isolation without an internal platform engineering investment. You get a private deployment without the operational burden.

With BYOVPC, your team pre-provisions every one of those resources before Redpanda ever touches your account. The distinction matters in practice:

  • Security groups: You define the ingress and egress rules. You control which CIDR ranges, VPCs, or specific security group IDs are allowed to communicate with Redpanda brokers. If your organization requires that all firewall rules go through an approval process or are managed via a security-as-code pipeline, BYOVPC accommodates that natively—Redpanda never modifies a security group you own.
  • Security group profiles: 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.
  • Subnets: You choose which subnets—across which availability zones—Redpanda brokers and agents are deployed into. Whether you're working with private subnets behind a NAT gateway, subnets routed through a Transit Gateway, or subnets peered with on-premises networks, BYOVPC integrates with your existing topology. This is especially valuable if your organization has a hub-and-spoke network model or strict AZ placement policies.
  • S3 buckets: 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.

Here's a side-by-side summary:

ResourceBYOCBYOVPC
VPCCreated by RedpandaPre-provisioned by you
SubnetsCreated by RedpandaPre-provisioned by you
Security groupsCreated and managed by RedpandaPre-provisioned and managed by you
IAM roles & instance profilesCreated by RedpandaPre-provisioned by you
S3 buckets (Tiered Storage)Created by RedpandaPre-provisioned by you
Redpanda IAM footprintBroader (needs to create resources)Minimal (read/write only)

Why teams choose BYOVPC

BYOVPC gives cloud teams a sophisticated level of control, including:

  • Full ownership of your VPC, subnets, IAM roles, firewall rules, and storage buckets.
  • Reduced IAM footprint for Redpanda (fewer permissions means a smaller blast radius).
  • Seamless integration with existing VPCs, transit gateways, and PrivateLink configurations.
  • Support for condition tags for fine-grained IAM controls based on AWS resource tags.
  • Secrets management is enabled by default, allowing you to securely integrate REST catalogs and Iceberg-enabled topics.

Terraform: the best way to provision BYOVPC clusters

Alongside the GA announcement, we're formally establishing Terraform as the recommended provisioning path for BYOVPC clusters on AWS.

The terraform-aws-redpanda-byovpc module on GitHub is a production-ready automation suite that provisions all the foundational AWS resources your BYOVPC cluster requires. It's a complete, opinionated module that handles:

  • VPC and subnet configuration, including CIDR block allocation across availability zones.
  • IAM instance profiles for all five workload types (agent, redpanda, utility, connectors, and optionally redpanda_connect), each scoped to exactly what that component needs.
  • k8s_cluster_role — the EKS cluster IAM role.
  • Security groups (7), with sensible defaults you can customize before applying.
  • S3 bucket for tiered storage, pre-configured with encryption and appropriate bucket policies.
  • PrivateLink configuration (optional, enabled via variables).
  • Redpanda Connect enablement (configurable).

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.

Why Terraform?

  • Repeatability: Define your infrastructure once and deploy it consistently across environments.
  • Auditability: All changes are tracked in version control, making compliance reviews straightforward.
  • Flexibility: Customize every aspect of your infrastructure using input variables, from CIDR ranges to PrivateLink settings.
  • Speed: A single Terraform apply provisions the full suite of required resources and outputs the ARNs needed for cluster creation.

The high-level provisioning flow

Getting a BYOVPC cluster up and running with Terraform involves four main phases:

  • Re-use existing AWS resources or configure and deploy resources using Terraform module: Define a tfvars JSON file with your VPC ID, AWS account ID, region, subnet CIDRs, and optional flags like PrivateLink and Redpanda Connect enablement.

  • Create the network and cluster Redpanda Terraform provider: Use the Redpanda Terraform provider to provision your network and cluster with the initial cluster resources (autoscaling group, agent VM, launch template), then hand off control to the Redpanda Cloud agent. Check an example for provisioning a BYOVPC cluster using the Terraform Provider.

Below is an example of a Redpanda network and Redpanda cluster definition with the Terraform provider.

resource "redpanda_network" "test" {
  name              = var.network_name
  resource_group_id = redpanda_resource_group.test.id
  cloud_provider    = var.cloud_provider
  region            = var.region
  cluster_type      = "byoc"
  customer_managed_resources = {
    aws = {
      management_bucket = {
        arn = module.redpanda_byovpc.management_bucket_arn
      }
      dynamodb_table = {
        arn = module.redpanda_byovpc.dynamodb_table_arn
      }
      vpc = {
        arn = module.redpanda_byovpc.vpc_arn
      }
      private_subnets = {
        arns = module.redpanda_byovpc.private_subnet_arns
      }
    }
  }
  depends_on = [
    module.redpanda_byovpc
  ]
}
resource "redpanda_cluster" "test" {
  name              = var.cluster_name
  resource_group_id = redpanda_resource_group.test.id
  network_id        = redpanda_network.test.id
  cloud_provider    = redpanda_network.test.cloud_provider
  region            = redpanda_network.test.region
  cluster_type      = redpanda_network.test.cluster_type
  connection_type   = "private"
  throughput_tier   = var.throughput_tier
  zones             = var.zones
  allow_deletion    = true
  tags = {
    "key" = "value"
  }
  customer_managed_resources = {
    aws = {
      aws_permissions_boundary_policy_arn = {
        arn = module.redpanda_byovpc.permissions_boundary_policy_arn
      }
      agent_instance_profile = {
        arn = module.redpanda_byovpc.agent_instance_profile_arn
      }
      connectors_node_group_instance_profile = {
        arn = module.redpanda_byovpc.connectors_node_group_instance_profile_arn
      }
      utility_node_group_instance_profile = {
        arn = module.redpanda_byovpc.utility_node_group_instance_profile_arn
      }
      redpanda_node_group_instance_profile = {
        arn = module.redpanda_byovpc.redpanda_node_group_instance_profile_arn
      }
      k8s_cluster_role = {
        arn = module.redpanda_byovpc.k8s_cluster_role_arn
      }
      redpanda_agent_security_group = {
        arn = module.redpanda_byovpc.redpanda_agent_security_group_arn
      }
      connectors_security_group = {
        arn = module.redpanda_byovpc.connectors_security_group_arn
      }
      redpanda_node_group_security_group = {
        arn = module.redpanda_byovpc.redpanda_node_group_security_group_arn
      }
      utility_security_group = {
        arn = module.redpanda_byovpc.utility_security_group_arn
      }
      cluster_security_group = {
        arn = module.redpanda_byovpc.cluster_security_group_arn
      }
      node_security_group = {
        arn = module.redpanda_byovpc.node_security_group_arn
      }
      cloud_storage_bucket = {
        arn = module.redpanda_byovpc.cloud_storage_bucket_arn
      }
      permissions_boundary_policy = {
        arn = module.redpanda_byovpc.permissions_boundary_policy_arn
      }
    }
  }
  depends_on = [
    redpanda_network.test
  ]
}

What’s included in BYOVPC GA

Now that you understand why we’re so excited about this going GA, here’s what you get:

  • Full support for private and public connectivity, including PrivateLink and Transit Gateway.
  • Secrets management is enabled by default through Terraform provisioning.
  • Custom tagging support for cost allocation, audit compliance, and governance policies (up to 16 custom tags via the Cloud API).
  • Automated validation checks at deploy time to surface missing permissions or misconfigured resources before they cause issues.
  • Redpanda Connect support within BYOVPC clusters (enabled by default, configurable).

Get started today

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.

Ready to dive in? Check out the full documentation:

No items found.

Related articles

View all posts
Tyler Akidau
,
Peter Corless
,
&
Feb 18, 2026

Redpanda Agentic Data Plane (ADP) now in limited availability

Securely integrate AI agents and MCP servers, all in real time

Read more
Text Link
David Yu
,
,
&
Feb 5, 2026

Redpanda Terraform provider: manage Connect pipelines, PrivateLink, and more

We're going "beyond the cluster" to standardize streaming for modern enterprises

Read more
Text Link
Towfiqa Yasmeen
,
Mike Broberg
,
&
Feb 3, 2026

Redpanda Serverless now Generally Available

Zero-ops simplicity meets enterprise-grade security to unlock production-ready data streaming for builders

Read more
Text Link
PANDA MAIL

Stay in the loop

Subscribe to our VIP (very important panda) mailing list to pounce on the latest blogs, surprise announcements, and community events!
Opt out anytime.