Modify AWS BYOVPC documentation to use terraform module examples

[frenchfrywpepper]

Description

Instead of cloud-examples with API calls. @david-yu and @micheleRP and I discussed and agreed to go in this direction.

Review deadline: Feb 27

Page previews

• BYOVPC on AWS
• BYOVNet on Azure
• What's New

Checks

• New feature
• Content gap
• Support Follow-up
• Small fix (typos, links, copyedits, etc)

[netlify]

✅ Deploy Preview for rp-cloud ready!

Name	Link
🔨 Latest commit	8406757
🔍 Latest deploy log	https://app.netlify.com/projects/rp-cloud/deploys/69a5d0809d3f450008fcf5f2
😎 Deploy Preview	https://deploy-preview-506--rp-cloud.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

📝 Walkthrough

Walkthrough

This pull request rewrites the AWS BYOVPC deployment documentation to replace manual Terraform setup references with a registry-based Redpanda module approach. The guide shifts from cloud-examples repository patterns and Cloud API-based authentication flows to a consolidated Terraform module-centric deployment. Key additions include the redpanda_byovpc module, redpanda_network and redpanda_cluster resources, and redpanda_resource_group data source, along with updated configuration examples and deployment workflows. The guide now supports both new VPC creation and pre-existing VPC/subnet scenarios through module configuration.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• BYOVPC support for secrets and Iceberg REST catalogs  #313: Modifies the same AWS BYOVPC documentation around deployment and secrets management approaches, with overlapping scope on Terraform configuration patterns.
• DOC-1348: Document cross-region AWS PrivateLink feature #480: Extends the redpanda_cluster resource with aws_private_link and supported_regions attributes, directly related to the cluster configuration resources introduced in this documentation update.

Suggested reviewers

• david-yu
• micheleRP
• paulzhang97

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The PR description lacks a reference to a specific GitHub issue number and is missing detailed information about changes made, though it does include page previews and marked checkboxes.	Add the linked GitHub issue number (CIAINFRA-2473) to the 'Resolves' field and provide more detailed summary of what was changed and why.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and specifically describes the main change: modifying AWS BYOVPC documentation to use Terraform module examples instead of prior approaches.
Linked Issues check	✅ Passed	The code changes fully meet the linked issue objective to replace API/cloud-examples references with Terraform module and provider-based documentation examples.
Out of Scope Changes check	✅ Passed	All changes in the BYOVPC AWS guide are directly aligned with the objective to implement Terraform module-based documentation. No out-of-scope modifications were detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch sarah/CIAINFRA-2473

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (2)

modules/get-started/pages/cluster-types/byoc/aws/vpc-byo-aws.adoc (2)

206-210: Note the dependency between enable_redpanda_connect and the redpanda_connect_* cluster fields.

The redpanda_connect_node_group_instance_profile and redpanda_connect_security_group blocks in redpanda_cluster consume outputs that the module only produces when enable_redpanda_connect = true (set at line 98). If a user adjusts the module flag to false, they must also remove those two blocks from the cluster resource, or Terraform will reference non-existent outputs. A short inline note or comment would preempt this silent misconfiguration.

📝 Suggested inline comment

+      # The following two blocks are only required when
+      # enable_redpanda_connect = true in the module above.
       redpanda_connect_node_group_instance_profile = {
         arn = module.redpanda_byovpc.redpanda_connect_node_group_instance_profile_arn
       }
       redpanda_connect_security_group = {
         arn = module.redpanda_byovpc.redpanda_connect_security_group_arn
       }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@modules/get-started/pages/cluster-types/byoc/aws/vpc-byo-aws.adoc` around
lines 206 - 210, Add an inline comment next to the
redpanda_connect_node_group_instance_profile and redpanda_connect_security_group
blocks explaining they depend on enable_redpanda_connect being true because they
consume outputs from module.redpanda_byovpc
(redpanda_connect_node_group_instance_profile_arn and
redpanda_connect_security_group_arn); instruct users to remove these blocks or
conditionally include them when enable_redpanda_connect is false to avoid
Terraform referencing non-existent outputs.

---

90-105: Pin a module version in all three module "redpanda_byovpc" blocks.

All three module invocations (lines 90–105, 262–266, and 287–303) omit a version constraint. Without one, terraform init will silently pull the latest release, which can introduce breaking changes between documentation readers' runs. The Terraform Registry shows 2.1.7 as the current latest release and includes it in the canonical example snippet.

📌 Proposed fix (apply to all three module blocks)

 module "redpanda_byovpc" {
   source  = "redpanda-data/redpanda-byovpc/aws"
+  version = "~> 2.1"
   common_prefix = local.common_prefix
   ...
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@modules/get-started/pages/cluster-types/byoc/aws/vpc-byo-aws.adoc` around
lines 90 - 105, The three module invocations named module "redpanda_byovpc" are
missing a pinned Terraform Registry version; update each module block (the
module "redpanda_byovpc" that sets source = "redpanda-data/redpanda-byovpc/aws")
to include a version constraint (e.g. version = "2.1.7") so terraform init will
use a fixed release; apply the same version line to all three module
"redpanda_byovpc" blocks in the file.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@modules/get-started/pages/cluster-types/byoc/aws/vpc-byo-aws.adoc`:
- Around line 274-278: The allowed_principals ARN uses a shell-style $ACCOUNT_ID
which Terraform won't interpolate; update the
aws_private_link.allowed_principals entry to reference a Terraform variable
(e.g., var.aws_account_id) instead of $ACCOUNT_ID and add a corresponding
variable declaration named aws_account_id (string) with a description, or
alternatively add a clear inline comment next to the allowed_principals line
warning readers not to copy a shell-style placeholder and to replace it with
var.aws_account_id.
- Line 108: Update the NOTE that says "At least one public subnet is required to
create a cluster" to explicitly state that this requirement applies overall but
that when using a pre-existing VPC the module will rely on any already-existing
public subnets in that VPC; clarify that setting public_subnet_cidrs = [] only
prevents the module from creating public subnets (it does not negate the
requirement) and mention that if the pre-existing VPC lacks public subnets the
user must provide or create at least one before creating the cluster; reference
the configuration symbols create_internet_gateway and public_subnet_cidrs so the
reader knows which settings control module-managed gateway and subnet creation.

---

Nitpick comments:
In `@modules/get-started/pages/cluster-types/byoc/aws/vpc-byo-aws.adoc`:
- Around line 206-210: Add an inline comment next to the
redpanda_connect_node_group_instance_profile and redpanda_connect_security_group
blocks explaining they depend on enable_redpanda_connect being true because they
consume outputs from module.redpanda_byovpc
(redpanda_connect_node_group_instance_profile_arn and
redpanda_connect_security_group_arn); instruct users to remove these blocks or
conditionally include them when enable_redpanda_connect is false to avoid
Terraform referencing non-existent outputs.
- Around line 90-105: The three module invocations named module
"redpanda_byovpc" are missing a pinned Terraform Registry version; update each
module block (the module "redpanda_byovpc" that sets source =
"redpanda-data/redpanda-byovpc/aws") to include a version constraint (e.g.
version = "2.1.7") so terraform init will use a fixed release; apply the same
version line to all three module "redpanda_byovpc" blocks in the file.

[david-yu]

Suggested change

	* At least one public subnet is required to create a cluster. The example configuration includes multiple public subnets to allow for future scaling.
	* At least one public subnet is required to create a cluster to send telemetry back to the Redpanda Control Plane. If a public subnet is not provided, network connectivity through peering of transit gateway to another VPC that routes traffic through a public subnet is needed. The example configuration includes multiple public subnets to allow for future scaling.

[micheleRP]

@david-yu is this edit OK:

To send telemetry back to the Redpanda control plane, the cluster needs outbound internet access. You can provide this through at least one public subnet, or through network peering or a transit gateway to another VPC that routes traffic through a public subnet. The example configuration includes multiple public subnets to allow for future scaling.

[david-yu]

Approved aside from the comment about the subnet.