Skip to content

SYSTEM Cited by 1 source

terraform-aws-redpanda-byovpc (Terraform module)

The terraform-aws-redpanda-byovpc module (github.com/redpanda-data/terraform-aws-redpanda-byovpc) is Redpanda's official opinionated Terraform module for provisioning the AWS substrate required by a Redpanda BYOVPC cluster. Alongside the 2026-03-11 BYOVPC GA announcement, Redpanda "formally establishes Terraform as the recommended provisioning path for BYOVPC clusters on AWS" (Source: sources/2026-03-11-redpanda-redpanda-clouds-byovpc-for-aws-is-now-generally-available).

What it provisions

Verbatim list from the GA post:

  • VPC and subnet configuration, including CIDR block allocation across availability zones.
  • IAM instance profiles for all five workload types — each scoped to exactly what the component needs:
  • agent — Redpanda Cloud agent VM.
  • redpanda — broker nodes.
  • utility — utility node group.
  • connectors — Kafka Connect / Redpanda Connect connector node group.
  • redpanda_connect — optionally enabled for systems/redpanda-connect inside BYOVPC.
  • k8s_cluster_role — the EKS cluster IAM role.
  • Seven security groups — "with sensible defaults you can customize before applying". The Terraform code block in the GA post references: redpanda_agent_security_group, connectors_security_group, redpanda_node_group_security_group, utility_security_group, cluster_security_group, node_security_group (6 named); the module README lists 7.
  • S3 bucket for tiered storage, pre-configured with encryption and appropriate bucket policies.
  • Management bucket + DynamoDB table (referenced in the redpanda_network wiring but not enumerated in the "what it includes" list).
  • PrivateLink configuration (optional, enabled via variables).
  • Redpanda Connect enablement (optional, configurable).

Permissions boundary policy

The module also provisions a permissions_boundary_policy ARN that gets passed to the redpanda_cluster resource as aws_permissions_boundary_policy_arn — this is the permissions-boundary IAM policy that caps the maximum permissions the Redpanda-created IAM entities can have within the customer account, even if attached policies would grant more. A safety invariant for customer IAM posture.

Skip-what-you-have composition

Verbatim (Source: post):

"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 composition hook for enterprise platform teams. See patterns/terraform-module-as-byoc-provisioning-path.

Integration with the Redpanda Terraform provider

The module outputs are consumed by redpanda_network + redpanda_cluster resources from the redpanda-data/redpanda Terraform provider:

  • redpanda_network.customer_managed_resources.aws: management_bucket, dynamodb_table, vpc, private_subnets.
  • redpanda_cluster.customer_managed_resources.aws: aws_permissions_boundary_policy_arn, agent_instance_profile, connectors_node_group_instance_profile, utility_node_group_instance_profile, redpanda_node_group_instance_profile, k8s_cluster_role, six+ security-group ARNs, cloud_storage_bucket, permissions_boundary_policy.

This separation — module provisions substrate, provider binds to substrate — is the wire between infrastructure-as-code (AWS resources) and infrastructure-as-service (Redpanda cluster).

Why Terraform (four reasons)

Verbatim from the "Why Terraform?" section of the GA post:

  1. Repeatability — define infrastructure once, deploy consistently across environments.
  2. Auditability — all changes tracked in version control; compliance reviews straightforward.
  3. Flexibility — customize every aspect via input variables, from CIDR ranges to PrivateLink settings.
  4. Speed — a single terraform apply provisions the full suite + outputs the ARNs needed for cluster creation.

High-level provisioning flow

From the GA post's "four main phases":

  1. Configure tfvars JSON with VPC ID + AWS account ID + region + subnet CIDRs + optional flags.
  2. terraform apply the module → outputs all the resource ARNs.
  3. Use redpanda_network + redpanda_cluster from the Redpanda Terraform provider; wire the module outputs to the provider inputs.
  4. The Redpanda Cloud agent takes over once the cluster resource reports back the initial provisioned state (autoscaling group, agent VM, launch template).

Caveats

  • AWS-only as of 2026-03-11. GCP + Azure equivalents not announced.
  • Opinionated defaults. The seven security groups, five IAM instance profiles, and the permissions-boundary policy encode Redpanda's view of least-privilege; customers with stricter posture may need to override defaults.
  • Not a lifecycle manager for the Redpanda cluster itself. Post-bootstrap, cluster lifecycle (upgrades, config changes, scaling) is handled by the Redpanda Cloud agent via the control plane, not by re-running the module.
  • State-file consolidation required. Platform teams with pre-existing Terraform state for VPC/subnets/IAM/S3 need to import those resources into the same workspace or use data sources when calling the Redpanda module with skip variables. The post doesn't walk this through.
  • No first-class module for Dedicated or Self-Managed. The terraform-aws-redpanda-byovpc name scope is BYOVPC-specific.

Seen in

Last updated · 470 distilled / 1,213 read