DOC-1348: Document cross-region AWS PrivateLink feature #480
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughThis PR adds documentation for a new feature: Cross-region AWS PrivateLink support. Changes include a new January 2026 section in the product release notes, updated Terraform provider documentation with the Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
✅ Deploy Preview for rp-cloud ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
- Add supported_regions field to aws_private_link configuration examples - Add new Cross-region PrivateLink section with requirements and usage - Update requirements to note cross-region option - Add cross-region note to Cloud UI page with link to API docs - Add supported_regions to Terraform provider example - Add What's New entry for January 2026 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
- Add cross-region PrivateLink section to Cloud UI docs - Include UI steps for configuring supported regions - Update What's New to reference both UI and API docs 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
…lusters 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
micheleRP
force-pushed
the
DOC-1348-cross-region-aws-privatelink
branch
from
976e755 to
5080380
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @modules/networking/pages/aws-privatelink.adoc:
- Line 362: Clarify that the aws_private_link configuration's supported_regions
field is only present for clusters deployed with multiple availability zones
(multi-AZ); update the sentence around `aws_private_link`/`supported_regions` to
add a concise note such as: "Note: the `supported_regions` field appears in the
cluster configuration only when the cluster is deployed with multiple
availability zones (multi‑AZ) and is not available for single‑AZ clusters." This
keeps the multi‑AZ prerequisite explicit and prevents API users from attempting
cross‑region PrivateLink on single‑AZ clusters.
- Around line 359-363: Update the Requirements subsection to list the two new
AWS IAM permissions and the feature flag: add bullets stating that IAM must
allow vpce:AllowMultiRegion and elasticloadbalancing:DescribeListenerAttributes,
and note that the cross-region PrivateLink capability is guarded by the feature
flag named in the PR objectives (mention the exact flag name from the PR and how
to enable it in cluster configuration), and keep the existing note about
configuring cross-region via the aws_private_link supported_regions field so
users see all prerequisites in one place.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (4)
modules/get-started/pages/whats-new-cloud.adocmodules/manage/pages/terraform-provider.adocmodules/networking/pages/aws-privatelink.adocmodules/networking/pages/configure-privatelink-in-cloud-ui.adoc
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-08-07T16:36:45.111Z
Learnt from: micheleRP
Repo: redpanda-data/cloud-docs PR: 377
File: modules/networking/pages/dedicated/gcp/configure-psc-in-ui.adoc:35-71
Timestamp: 2025-08-07T16:36:45.111Z
Learning: In Redpanda Cloud documentation, NAT subnet and firewall rule creation commands for GCP Private Service Connect are producer-side infrastructure steps that only BYOC (Bring Your Own Cloud) customers need to perform, since they manage their own VPC. Dedicated cluster customers don't need these steps because Redpanda manages the infrastructure for them. The ifdef::env-byoc[] guard correctly hides these commands from Dedicated users.
Applied to files:
modules/networking/pages/configure-privatelink-in-cloud-ui.adocmodules/get-started/pages/whats-new-cloud.adocmodules/manage/pages/terraform-provider.adocmodules/networking/pages/aws-privatelink.adoc
📚 Learning: 2025-04-25T01:41:57.162Z
Learnt from: micheleRP
Repo: redpanda-data/cloud-docs PR: 267
File: modules/manage/pages/maintenance.adoc:91-92
Timestamp: 2025-04-25T01:41:57.162Z
Learning: The notification timeline for Redpanda Cloud deprecations has been deliberately removed from the documentation, even though the PR summary mentioned a 180-day advance notice period.
Applied to files:
modules/get-started/pages/whats-new-cloud.adoc
📚 Learning: 2025-08-11T22:06:05.137Z
Learnt from: david-yu
Repo: redpanda-data/cloud-docs PR: 387
File: modules/manage/pages/terraform-provider.adoc:99-102
Timestamp: 2025-08-11T22:06:05.137Z
Learning: In the Redpanda Terraform provider, modifying the `throughput_tier` attribute of a cluster resource will force cluster replacement (destroy and recreate) only when `allow_deletion` is set to `true`. If `allow_deletion` is `false`, Terraform will prevent the modification to protect against accidental cluster destruction.
Applied to files:
modules/manage/pages/terraform-provider.adoc
🔇 Additional comments (9)
modules/manage/pages/terraform-provider.adoc (1)
353-358: Well-documented cross-region PrivateLink example.The addition of
supported_regionsto the Terraform provider example is clear and helpful. The optional comment and realistic region examples make the feature accessible to users.modules/networking/pages/configure-privatelink-in-cloud-ui.adoc (3)
21-21: Accurate requirements update.The updated requirement correctly conditionalizes the region constraint, allowing cross-region PrivateLink when configured. This is non-breaking and provides clear guidance to users.
34-36: Clear optional step for cross-region configuration.The optional step on line 36 appropriately directs users to the new cross-region section without making it mandatory. The internal section reference is correctly formatted.
53-76: Comprehensive cross-region PrivateLink section with multi-AZ requirement clearly stated.The new section provides clear structure:
- Concise explanation of cross-region capability (lines 55-57)
- Multi-AZ prerequisite clearly stated (line 61)
- Helpful note about UI conditional rendering for multi-AZ clusters (line 65)
- Step-by-step configuration instructions (lines 67-72)
- Clear outcome statement (line 76)
The inline section anchor will resolve xref links from the release notes entry, and the AWS documentation link adds credibility.
modules/get-started/pages/whats-new-cloud.adoc (1)
9-13: Clear and well-positioned release notes entry.The January 2026 cross-region PrivateLink entry concisely explains the feature, states the multi-AZ requirement, and provides direct links to configuration guidance for both Cloud UI and API. The xref anchors resolve correctly to documented sections in the supporting pages.
modules/networking/pages/aws-privatelink.adoc (4)
353-401: Verify DNS resolution behavior and guidance for cross-region PrivateLink.The cross-region PrivateLink section (lines 353-401) references the same VPC endpoint creation process and includes reference to the <> section, but it doesn't clarify whether the DNS resolution guidance from the <> section (line 199) applies unchanged to cross-region endpoints. Cross-region PrivateLink may have different DNS propagation characteristics or require different DNS configuration.
Confirm whether the DNS resolution and conditional forwarding guidance documented for standard PrivateLink (included via line 199) applies identically to cross-region endpoints, or if additional DNS configuration considerations should be documented in the cross-region section.
99-129: API examples are well-structured and consistent.The POST and PATCH examples properly include the
supported_regionsfield alongsideallowed_principals, and the standalone JSON example in the configuration section clearly demonstrates cross-region usage. The field is correctly documented as optional and tied to cross-region configuration.Also applies to: 167-183, 370-378
382-401: Cross-region VPC endpoint example is clear and actionable.The example properly distinguishes the key difference in cross-region setup: specifying
--region $CLIENT_REGIONinstead of the cluster's region. The use of parameterized variables (CLIENT_REGION,$PL_SERVICE_NAME) and the reference back to the standard <> process provides good guidance.
25-25: Requirement updates are well-integrated with cross-references.The updates to lines 25 and 241 appropriately reference the new <> section, allowing users to discover the exception to region constraints. The cross-reference syntax is correct.
Also applies to: 241-241
| === Requirements | ||
|
|
||
| * The Redpanda cluster must be deployed across multiple availability zones (multi-AZ). This is an AWS limitation for cross-region PrivateLink. | ||
| * Cross-region PrivateLink is configured through the `supported_regions` field in the `aws_private_link` configuration. | ||
|
|
There was a problem hiding this comment.
Missing AWS permissions and feature flag documentation per PR objectives.
The PR objectives specify documenting "new required AWS permissions: vpce:AllowMultiRegion and elasticloadbalancing:DescribeListenerAttributes" and "the feature flag guarding the capability." Neither is present in the Requirements section or elsewhere in the new cross-region documentation.
Add the missing AWS permissions and feature flag guidance. These should be included in the Requirements subsection (lines 359-363) so users understand all prerequisites before attempting to configure cross-region PrivateLink.
🤖 Prompt for AI Agents
In @modules/networking/pages/aws-privatelink.adoc around lines 359 - 363, Update
the Requirements subsection to list the two new AWS IAM permissions and the
feature flag: add bullets stating that IAM must allow vpce:AllowMultiRegion and
elasticloadbalancing:DescribeListenerAttributes, and note that the cross-region
PrivateLink capability is guarded by the feature flag named in the PR objectives
(mention the exact flag name from the PR and how to enable it in cluster
configuration), and keep the existing note about configuring cross-region via
the aws_private_link supported_regions field so users see all prerequisites in
one place.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find the cloud IAM policies documentation file
fd -t f "cloud-iam-policies" --extension adoc
# Also search for files that might contain IAM policy documentation
fd -t f "iam" --extension adoc | head -20
Length of output: 429
🏁 Script executed:
#!/bin/bash
# Read the current AWS IAM policies documentation
cat modules/security/pages/authorization/cloud-iam-policies.adoc
# Also check the partial file
echo "====== PARTIAL FILE ======"
cat modules/security/partials/iam-policies.adoc
Length of output: 34391
🏁 Script executed:
#!/bin/bash
# Fetch the Terraform file content from GitHub to see the PrivateLink permissions
curl -s "https://raw.githubusercontent.com/redpanda-data/cloudv2/42e19f241f98bda8c6a02623bcb849c9325be2d6/apps/redpanda-agent/infra/aws/redpanda/agent/instance_profile.tf" | sed -n '425,457p'
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Try fetching the entire file and then extracting the relevant section
curl -s "https://raw.githubusercontent.com/redpanda-data/cloudv2/42e19f241f98bda8c6a02623bcb849c9325be2d6/apps/redpanda-agent/infra/aws/redpanda/agent/instance_profile.tf" > /tmp/instance_profile.tf
# Check if the file was downloaded
if [ -s /tmp/instance_profile.tf ]; then
echo "File downloaded successfully. Total lines:"
wc -l /tmp/instance_profile.tf
echo ""
echo "Lines 425-457:"
sed -n '425,457p' /tmp/instance_profile.tf
echo ""
echo "=== Searching for PrivateLink-related permissions ==="
grep -i -A 5 -B 5 "privatelink\|vpce\|endpoint.*service" /tmp/instance_profile.tf | head -80
else
echo "Failed to download the file. Trying alternative approach..."
# Try with different user agent
curl -A "Mozilla/5.0" -s "https://raw.githubusercontent.com/redpanda-data/cloudv2/42e19f241f98bda8c6a02623bcb849c9325be2d6/apps/redpanda-agent/infra/aws/redpanda/agent/instance_profile.tf" | grep -i -A 10 -B 5 "privatelink\|vpce\|elasticloadbalancing" | head -100
fi
Length of output: 140
🌐 Web query:
AWS vpce:AllowMultiRegion permission PrivateLink cross-region
💡 Result:
Short answer
- vpce:AllowMultiRegion is a permission-only action you must allow (in identity policies and not denied by SCPs) to create or access PrivateLink (VPC endpoint service or interface endpoint) across AWS Regions. [1][2][3]
Key points
- Who needs it: service providers (to make a VPCE service available in multiple Regions) and service consumers (to create an interface endpoint to a service in another Region). [1][2]
- Policy controls: use ec2:VpceSupportedRegion (providers) and ec2:VpceServiceRegion (consumers) condition keys to restrict which Regions can be added/used. [1][2]
- SCPs: ensure your organization SCPs do not deny vpce:AllowMultiRegion. [2][3]
- Opt-in Regions: accounts must be opted-in to opt-in Regions before selecting them. [1]
Minimal example IAM statement (allow only two service Regions)
{
"Effect":"Allow",
"Action":"vpce:AllowMultiRegion",
"Resource":"arn:aws:ec2:::vpc-endpoint/*",
"Condition":{
"StringLike":{"ec2:VpceServiceRegion":["ap-northeast-1","eu-west-1"]}
}
}
(Adapt Principal/Resource to your use case.) [3]
Sources
- AWS PrivateLink: Share your services (cross-Region permissions & condition keys). [1]
- AWS PrivateLink cross-region docs (permissions/considerations). [2]
- AWS blog / announcement describing vpce:AllowMultiRegion and examples. [3]
🌐 Web query:
AWS elasticloadbalancing:DescribeListenerAttributes PrivateLink cross-region
💡 Result:
Short answer: DescribeListenerAttributes is an ELBv2 (regional) API that returns attributes for a listener on a load balancer in the region you call. For a PrivateLink (VPCE service) that is hosted in another AWS Region, call DescribeListenerAttributes (or aws elbv2 describe-listener-attributes) against the load balancer's region (or set --region to the service region / use that region's endpoint). PrivateLink cross‑region itself does not change which ELB API region you must call. [1][2]
Practical notes:
- PrivateLink provider endpoints are typically backed by a Network Load Balancer; the ELBv2 listener attributes supported for NLB/GWLB (e.g. tcp.idle_timeout.seconds) are documented in the ELB API/CLI docs. Querying those attributes must target the region where the NLB exists. [2][3]
- If the load balancer is in another account, ensure the caller has IAM permissions and the correct ARN (and cross-account trust) to call DescribeListenerAttributes in that region.
- With the AWS CLI you can specify --region or use the ARN's region to direct the request. [3]
Sources:
[1] AWS PrivateLink cross‑region announcement and docs.
[2] ELBv2 DescribeListenerAttributes / API reference.
[3] AWS CLI elbv2 describe-listener-attributes reference.
@paulzhang97 Yes, adding the IAM permissions documentation to this PR makes sense since users will need these permissions to use cross-region PrivateLink.
I can help plan the code changes to update modules/security/pages/authorization/cloud-iam-policies.adoc. From the PR objectives and my research, I've confirmed the two new permissions for cross-region PrivateLink:
vpce:AllowMultiRegion- Required for both service providers and consumers to enable cross-region PrivateLink connectionselasticloadbalancing:DescribeListenerAttributes- Required to retrieve listener attributes for the Network Load Balancer backing the PrivateLink service
However, I cannot access the private cloudv2 repository you linked to see the existing PrivateLink permissions at lines 425-457. Could you either:
- Provide the list of existing PrivateLink-related permissions from that Terraform file that should be documented, or
- Confirm which permissions are currently missing from the docs that should be added
Once I have this information, I can plan the code changes to add a dedicated PrivateLink permissions section (or update the VPC Management section) in the IAM policies documentation with both the new cross-region permissions and any missing existing permissions.
Would you like me to proceed with planning these changes?
🧠 Learnings used
Learnt from: micheleRP
Repo: redpanda-data/cloud-docs PR: 390
File: modules/manage/pages/schema-reg/schema-reg-authorization.adoc:4-4
Timestamp: 2025-08-15T02:29:34.901Z
Learning: In Redpanda Cloud documentation PRs, when CodeRabbit flags missing Asciidoctor tag markers for include directives, the fix may be implemented in the corresponding ROOT module file that contains the actual content being included, rather than in the file where the include directive appears.
Learnt from: micheleRP
Repo: redpanda-data/cloud-docs PR: 377
File: modules/networking/pages/dedicated/gcp/configure-psc-in-ui.adoc:35-71
Timestamp: 2025-08-07T16:36:45.111Z
Learning: In Redpanda Cloud documentation, NAT subnet and firewall rule creation commands for GCP Private Service Connect are producer-side infrastructure steps that only BYOC (Bring Your Own Cloud) customers need to perform, since they manage their own VPC. Dedicated cluster customers don't need these steps because Redpanda manages the infrastructure for them. The ifdef::env-byoc[] guard correctly hides these commands from Dedicated users.
| === Requirements | ||
|
|
||
| * The Redpanda cluster must be deployed across multiple availability zones (multi-AZ). This is an AWS limitation for cross-region PrivateLink. | ||
| * Cross-region PrivateLink is configured through the `supported_regions` field in the `aws_private_link` configuration. |
There was a problem hiding this comment.
Clarify that supported_regions field only appears for multi-AZ clusters.
The Requirements section lists the multi-AZ prerequisite, but it doesn't explicitly state that the supported_regions field in the aws_private_link configuration is only available (or visible) for multi-AZ clusters. API users attempting to configure cross-region PrivateLink on single-AZ clusters will encounter errors without understanding the underlying constraint.
Consider adding a note like: "The supported_regions field appears in the cluster configuration only when the cluster is deployed with multiple availability zones."
🤖 Prompt for AI Agents
In @modules/networking/pages/aws-privatelink.adoc at line 362, Clarify that the
aws_private_link configuration's supported_regions field is only present for
clusters deployed with multiple availability zones (multi-AZ); update the
sentence around `aws_private_link`/`supported_regions` to add a concise note
such as: "Note: the `supported_regions` field appears in the cluster
configuration only when the cluster is deployed with multiple availability zones
(multi‑AZ) and is not available for single‑AZ clusters." This keeps the multi‑AZ
prerequisite explicit and prevents API users from attempting cross‑region
PrivateLink on single‑AZ clusters.
| === Requirements | ||
|
|
||
| * The Redpanda cluster must be deployed across multiple availability zones (multi-AZ). This is an AWS limitation for cross-region PrivateLink. | ||
| * Cross-region PrivateLink is configured through the `supported_regions` field in the `aws_private_link` configuration. | ||
|
|
| CLIENT_REGION=<client_region> | ||
| aws ec2 create-vpc-endpoint \ | ||
| --region $CLIENT_REGION --profile $PROFILE \ |
There was a problem hiding this comment.
Need to add --service-region $SERVICE_REGION. SERVICE_REGION is the region where RP cluster is deployed.
We should also mention for updating aws cli with the latest since an older aws might not have the option --service-region.
Description
This pull request introduces support for cross-region AWS PrivateLink connections in Redpanda Cloud, allowing clients in different AWS regions to connect to clusters via PrivateLink. The documentation has been updated to describe requirements, configuration steps, and examples for both API and Cloud UI workflows. Changes also clarify the multi-AZ requirement and add details on the new
supported_regionsconfiguration field.Cross-region PrivateLink feature and documentation:
supported_regionsfield in theaws_private_linkconfiguration, with examples for both cluster creation and updates via API and Terraform. [1] [2] [3] [4] [5]Resolves https://redpandadata.atlassian.net/browse/DOC-1348
Review deadline:
Page previews
What's New
Configure AWS PrivateLink with the Cloud API
Configure AWS PrivateLink in the Cloud UI
Terraform Provider
Checks