DOC-1613: Document BYOC AWS centralized egress with Transit Gateway (#587)

* DOC-1613: Document BYOC AWS centralized egress with Transit Gateway

Add two new pages under networking/byoc/aws for the beta NAT
Gateway-free egress feature: a concept + how-to page for
configuring centralized egress on a BYOC cluster, and a hub-side
setup guide for the customer's Transit Gateway, NAT Gateway, and
AWS RAM share. Update nav and link from the existing BYOC create
and BYOVPC pages. The Cloud API path is gated behind
ifdef::show-preview-api[] while egress_spec is in PREVIEW.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* reorder sections

* add blurb to What's New

* Add preview-gated AWS Transit Gateway egress example to Control Plane API

Document `egress_spec.aws.transit_gateway_id` on AWS BYOC networks in the
Control Plane API partial behind `:show-preview-api:`, and cross-link the
full API workflow from the centralized-egress page.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Note private-networking requirement for centralized egress

Centralized egress is only available on AWS BYOC clusters with a private
connection type. Add the constraint to the Prerequisites list on the
centralized-egress page and to the Transit Gateway TIP callout on the
create-cluster page.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Clarify centralized egress switch-back guidance

Trim the IMPORTANT callout to keep only the actionable instruction
(create new network + cluster, then migrate data), since the
"immutable" point is already covered in the Limitations section.
Reassign the RAM share invitation acceptance to the Customer owner.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Clarify that the customer accepts the AWS RAM share invitation

Redpanda does not accept the Transit Gateway RAM share -- the customer
accepts the invitation in the BYOC AWS account before creating the
cluster (auto-accepted within an AWS Organization). Correct the
Prerequisites bullet, the Console procedure step, and both
troubleshooting rows that previously implied Redpanda accepts the share.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Note that the Network page CIDR must route on the hub side

Add a NOTE next to the Transit Gateway ID UI step clarifying that the
CIDR block customers enter on the Network page is the Redpanda spoke
CIDR, and that a matching static route must exist on the hub public
route table for reply traffic to reach the cluster. The Transit
Gateway's own route table picks up the spoke CIDR via propagation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Rewrite centralized egress troubleshooting from customer POV

The previous six-row table mixed customer-observable symptoms with
internal framings (agent logs, packets in the Redpanda VPC) that
customers cannot inspect. Replace it with two rows whose symptoms
are visible in the Cloud UI or the customer's own AWS account, and
fold the four hub misconfiguration causes into a single
"cluster creation does not complete" checklist.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Document TGW auto-accept setting as a customer prerequisite

The page assumed the customer knew their existing Transit Gateway
would auto-accept the Redpanda spoke attachment. Spell out both cases
in Prerequisites and split the conflated troubleshooting row that
mislabeled a pendingAcceptance attachment as a RAM share issue.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Update modules/networking/pages/byoc/aws/nat-free-egress.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* Update modules/networking/pages/byoc/aws/aws-hub-egress.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* Update modules/networking/pages/byoc/aws/aws-hub-egress.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* incorporate review feedback

* Update modules/manage/partials/controlplane-api.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* Update modules/get-started/pages/whats-new-cloud.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* Update modules/networking/pages/byoc/aws/aws-hub-egress.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* Update modules/networking/pages/byoc/aws/aws-hub-egress.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* Update modules/networking/pages/byoc/aws/aws-hub-egress.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* Address open review comments on the hub egress page

- Add an xref to "What are CIDRs?" from the hub-and-spoke CIDR overlap warning.
- Explain why the hub needs private subnets and an Internet Gateway in the
  two sections that previously jumped straight from heading to tabs.
- Drop the "in preview on AWS BYOC networks only" qualifier from the
  centralized-egress API note, since there is no central definition of
  "preview" to link to.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Spell out Transit Gateway instead of the TGW acronym

AWS official documentation does not use the TGW acronym in prose. It
appears only in URL paths and resource-ID prefixes. Match that
convention: replace bare-word TGW in prose, numbered traffic-flow
steps, ASCII diagrams, and echo strings in CLI examples. Shell
variables ($TGW_ID, $TGW_ARN) and resource-ID prefixes (tgw-...)
are left unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* style edit

* style edit

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

Author: 3 people

modules/ROOT/nav.adoc

@@ -453,6 +453,8 @@
 **** xref:networking:configure-privatelink-in-cloud-ui.adoc[Configure PrivateLink in the Cloud Console]
 **** xref:networking:aws-privatelink.adoc[Configure PrivateLink with the Cloud API]
 **** xref:networking:byoc/aws/transit-gateway.adoc[Add a Transit Gateway]
+**** xref:networking:byoc/aws/nat-free-egress.adoc[Configure Centralized Egress]
+**** xref:networking:byoc/aws/aws-hub-egress.adoc[Create an AWS Hub for Centralized Egress]
 *** xref:networking:byoc/azure/index.adoc[Azure]
 **** xref:networking:azure-private-link-in-ui.adoc[]
 **** xref:networking:azure-private-link.adoc[]

modules/get-started/pages/cluster-types/byoc/aws/create-byoc-cluster-aws.adoc

@@ -43,6 +43,11 @@ Optionally, click *Advanced settings* to specify up to five key-value custom tag
 ** Clusters with private networking include a setting for API Gateway network access. Public access exposes endpoints for Redpanda Console, the Data Plane API, and the MCP Server API, but they remain protected by your authentication and authorization controls. Private access restricts endpoint access to your VPC only.
 +
 NOTE: After the cluster is created, you can change the API Gateway access on the Dataplane settings page. If you change from public to private access, users without VPN access to the Redpanda VPC will lose access to these services.
++
+[TIP]
+====
+To route all cluster egress through your own AWS Transit Gateway and hub VPC instead of a per-VPC NAT Gateway, set the *Transit Gateway ID* field on this page. The field is only available on clusters with a private connection type, and is only visible if centralized egress is enabled for your organization. This option is in beta. See xref:networking:byoc/aws/nat-free-egress.adoc[].
+====
 . Click *Next*.
 . On the Deploy page, follow the steps to log in to Redpanda Cloud and deploy the agent.
 +

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

@@ -111,7 +111,7 @@ module "redpanda_byovpc" {
 
 [NOTE]
 ====
-* 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.
+* 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. Standard BYOC clusters can also route egress through a customer-owned hub VPC and Transit Gateway, eliminating the per-VPC NAT Gateway entirely. See xref:networking:byoc/aws/nat-free-egress.adoc[].
 * The example creates an Internet Gateway and an associated Route Table rule that routes traffic into the VPC, which allows the Redpanda control plane to access the cluster. To disable creation of the Internet Gateway, either remove the configuration and value for `create_internet_gateway` or set `"create_internet_gateway": false`.
 * When using a pre-existing VPC, at least one public subnet must already exist in that VPC. Setting `public_subnet_cidrs = []` only prevents the module from creating new ones.
 ====

modules/get-started/pages/whats-new-cloud.adoc

@@ -8,6 +8,10 @@ This page lists new features added to Redpanda Cloud.
 
 == May 2026
 
+=== Centralized egress for BYOC on AWS (beta)
+
+You can route all BYOC cluster egress through your own AWS Transit Gateway and hub VPC instead of a per-VPC NAT Gateway, so outbound traffic exits through your centralized inspection point. This is useful for regulated environments that prohibit per-VPC NAT Gateways and for consolidating egress behind a single, predictable public IP for outbound allowlisting. Centralized egress is in beta and is enabled per organization. Contact your account team for access. See xref:networking:byoc/aws/nat-free-egress.adoc[Configure Centralized Egress with AWS Transit Gateway].
+
 === Schema Registry Authorization enabled by default
 
 Schema Registry Authorization is now enabled automatically on all new BYOC and Dedicated clusters. The xref:reference:properties/cluster-properties.adoc#schema_registry_enable_authorization[`schema_registry_enable_authorization`] cluster property is set to `true` at provisioning, and the predefined Admin, Writer, and Reader roles include Schema Registry permissions for the `subject` and `registry` ACL resource types. You can use ACLs and RBAC roles to grant fine-grained access to schemas and subjects without any additional setup. See xref:manage:schema-reg/schema-reg-authorization.adoc[Schema Registry Authorization] and xref:security:authorization/rbac/rbac.adoc#predefined-roles[Predefined roles].

modules/manage/partials/controlplane-api.adoc

@@ -125,11 +125,40 @@ curl -d \
     "region": "us-west1"
   }
 }' -H "Content-Type: application/json" \
--H "Authorization: Bearer <token>" -X POST https://api.redpanda.com/v1/networks 
+-H "Authorization: Bearer <token>" -X POST https://api.redpanda.com/v1/networks
+----
+// The AWS BYOC network example adds `egress_spec.aws.transit_gateway_id`
+// to route all cluster egress through a customer-owned Transit Gateway.
+// It is gated behind `:show-preview-api:` while the field is in preview.
+// To enable, set the attribute in the playbook or in this page header.
+ifdef::show-preview-api[]
+
+To route all cluster egress through your own AWS Transit Gateway and hub VPC instead of a per-VPC NAT Gateway, set `egress_spec.aws.transit_gateway_id` on an AWS BYOC network. Centralized egress is in beta. The Transit Gateway ID is immutable after the network is created. Before calling this endpoint, provision the hub VPC and Transit Gateway and share the Transit Gateway with the Redpanda cluster account. See xref:networking:byoc/aws/aws-hub-egress.adoc[Create an AWS Hub for Centralized Egress] and xref:networking:byoc/aws/nat-free-egress.adoc[Configure Centralized Egress with AWS Transit Gateway].
+
+[,bash]
 ----
+curl -d \
+'{
+  "network": {
+    "cidr_block": "10.10.0.0/20",
+    "cloud_provider": "CLOUD_PROVIDER_AWS",
+    "cluster_type": "TYPE_BYOC",
+    "name": "<network-name>",
+    "resource_group_id": "<resource-group-id>",
+    "region": "us-east-2",
+    "egress_spec": {
+      "aws": {
+        "transit_gateway_id": "tgw-0b629c5b4fb6e364b"
+      }
+    }
+  }
+}' -H "Content-Type: application/json" \
+-H "Authorization: Bearer <token>" -X POST https://api.redpanda.com/v1/networks
+----
+endif::[]
 endif::[]
 
-This endpoint returns a <<lro,long-running operation>>. 
+This endpoint returns a <<lro,long-running operation>>.
 
 === Create a new cluster