Collapse navigation tree

Collapse

Configure Centralized Egress with AWS Transit Gateway

beta

This feature is in beta and is available only on AWS BYOC clusters with private networking. Availability is controlled per organization. Contact your account team to request access to centralized egress.

Centralized egress lets your BYOC cluster send all internet-bound traffic through your own AWS Transit Gateway and hub VPC instead of a Redpanda-managed NAT Gateway in the Redpanda VPC. When centralized egress is enabled, the Redpanda spoke VPC attaches to your Transit Gateway, all outbound traffic exits through the NAT Gateway or firewall in your hub, and no per-VPC NAT Gateway is created in the spoke.

After reading this page, you will be able to:

  • Enable centralized egress on a new BYOC cluster using the Redpanda Cloud UI

  • Identify the shared responsibility boundaries between Redpanda and your hub account

  • Troubleshoot egress failures caused by misconfigured hub routes or firewall rules

When to use centralized egress

Use centralized egress when:

  • Your security policy prohibits per-VPC NAT Gateways and requires all internet-bound traffic to traverse a centralized inspection point such as an AWS Network Firewall, NVA, or third-party firewall appliance.

  • You already operate a hub-and-spoke network in AWS and want Redpanda to fit into that topology.

  • You want to consolidate egress through a single, predictable public IP for outbound allowlisting on external services.

  • You want to reduce NAT Gateway data-processing fees on high-throughput Redpanda workloads.

If none of these apply, the default NAT Gateway egress used by standard BYOC clusters is simpler and requires no extra customer-managed infrastructure.

How it works

Without centralized egress, the Redpanda agent creates a NAT Gateway and Internet Gateway inside the Redpanda VPC. With centralized egress enabled, the agent attaches the Redpanda VPC to your existing Transit Gateway instead, routes all 0.0.0.0/0 traffic through it, and provisions Interface VPC Endpoints in the Redpanda VPC so critical AWS API calls (ECR, STS, CloudWatch Logs) do not need to traverse your hub.

The following diagram shows the connectivity model:

+----------------------------------+         +-----------+         +----------------------------------+
| Redpanda VPC                     |         | Transit   |         | Customer Hub VPC                 |
| (Redpanda account)               |         | Gateway   |         | (Customer account)               |
|                                  |         |           |         |                                  |
| Transit Gateway VPC Attachment   +-------->+ Shared    +-------->+ Transit Gateway VPC Attachment   |
| 0.0.0.0/0 -> Transit Gateway     |         | via AWS   |         | 0.0.0.0/0 -> NAT GW              |
| VPC Endpoints                    |         | RAM       |         | NAT Gateway -> IGW               |
| EKS Worker Nodes                 |         |           |         | Internet Gateway                 |
| No NAT / No IGW                  |         |           |         |                                  |
+----------------------------------+         +-----------+         +-----------+----------------------+
                                                                               |
                                                                               v
                                                                           Internet
                                                               (Cloudsmith, public.ecr.aws,
                                                                         NTP, Helm)

Outbound traffic flow

  1. An EKS node in a Redpanda private subnet sends a packet destined for the internet.

  2. The private route table forwards 0.0.0.0/0 to the Transit Gateway VPC attachment in the Redpanda VPC.

  3. The Transit Gateway’s default route table forwards 0.0.0.0/0 to your hub VPC attachment (static route).

  4. The hub private route table forwards 0.0.0.0/0 to your NAT Gateway.

  5. The NAT Gateway forwards traffic to your Internet Gateway and out to the internet.

Return traffic flow

  1. The internet response arrives at the Internet Gateway in your hub VPC.

  2. The hub public route table forwards the Redpanda spoke CIDR to the Transit Gateway.

  3. The Transit Gateway forwards traffic back to the Redpanda spoke attachment through a propagated route.

  4. The packet arrives at the originating EKS node.

The Redpanda spoke CIDR route on the hub public route table is your responsibility. It is added when you provision your hub. See Create an AWS Hub for Centralized Egress for the full procedure.

Prerequisites

Before you configure centralized egress, confirm all of the following:

  • Centralized egress is enabled on your Redpanda Cloud organization. Contact your account team to request access.

  • Your BYOC cluster uses private networking (connection type Private). Centralized egress is not available on clusters with a public connection type.

  • You have an existing AWS Transit Gateway in the same region as the Redpanda BYOC cluster, and you know whether it auto-accepts cross-account attachments. Check the setting on your Transit Gateway before you create the cluster:

    aws ec2 describe-transit-gateways \
  --transit-gateway-ids <tgw-id> \
  --query 'TransitGateways[0].Options.AutoAcceptSharedAttachments'

    • If the value is enable, the Redpanda spoke attachment is accepted automatically when the BYOC cluster provisions. No action is required from you during cluster creation.

    • If the value is disable, you must manually accept the spoke attachment during cluster provisioning. In the AWS account that owns the Transit Gateway, open VPC > Transit Gateway Attachments, select the pending attachment from the Redpanda BYOC account, and choose Actions > Accept transit gateway attachment. Cluster provisioning pauses until you accept the attachment.

      Enabling AutoAcceptSharedAttachments causes the Transit Gateway to accept attachments from any AWS account it is shared with through AWS Resource Access Manager. Share the Transit Gateway only with accounts you trust to attach VPCs.

  • Your hub VPC has a NAT Gateway, AWS Network Firewall, or other NVA providing internet egress. See Create an AWS Hub for Centralized Egress if you need to provision a hub.

  • If the hub Transit Gateway is in a different AWS account than the account where you deploy your BYOC cluster, you have created an AWS Resource Access Manager (RAM) share in the hub account and accepted the invitation in the BYOC account before creating the cluster. Within an AWS Organization, the share is auto-accepted and no manual acceptance step is needed.

  • Your hub VPC CIDR and the planned Redpanda spoke VPC CIDR do not overlap.

    Terraform and AWS do not enforce CIDR uniqueness across Transit Gateway attachments, but overlapping CIDRs cause silent return-route failures. The hub VPC’s local route always wins over a Redpanda-spoke-CIDR route on the public route table, blackholing reply traffic.

    Use a non-overlapping range for your hub. The 100.64.0.0/16 CGNAT range is a safe default because it rarely conflicts with typical RFC 1918 workload CIDRs.

  • The Transit Gateway ID, in the form tgw- followed by at least 8 hexadecimal characters (for example, tgw-0b629c5b4fb6e364b).

Shared responsibility model

Component Owner

Redpanda spoke VPC, subnets, and EKS cluster

Redpanda

Spoke route table entry: 0.0.0.0/0 → Transit Gateway

Redpanda

Interface VPC Endpoints (ECR, STS, CloudWatch Logs) in spoke

Redpanda

Accepting the AWS RAM share invitation (cross-account)

Customer

Transit Gateway

Customer

Hub VPC

Customer

Hub NAT Gateway, firewall, or NVA

Customer

Hub route table entry: Redpanda spoke CIDR → Transit Gateway

Customer

Transit Gateway route tables

Customer

AWS RAM resource share (cross-account)

Customer

Egress path availability and HA

Customer

Redpanda does not manage the availability of the egress path. Plan for multi-AZ NAT or redundant firewall instances in your hub if you need high availability.

Limitations

Centralized egress is currently limited to setting the Transit Gateway ID at network creation. The field is immutable after the network is created.

Configure egress at network creation

Centralized egress is set at network creation. You cannot change it on an existing network. Complete all hub-side setup, including your decision on Transit Gateway attachment acceptance (see Prerequisites), before you start the cluster creation flow.

To switch back to NAT Gateway egress, create a new network and a new cluster on it, then migrate your data.

To enable centralized egress, use the Redpanda Cloud UI:

  1. Log in to Redpanda Cloud.

  2. On the Clusters page, click Create cluster, then click Create for BYOC.

  3. Complete the cluster details. See Create a BYOC Cluster on AWS for the full create flow.

  4. On the Network page, in the Transit Gateway ID field, enter your Transit Gateway ID. This field is only visible if centralized egress is enabled for your organization.

  5. Click Next and complete the remaining steps.

The CIDR block you enter on the Network page is the Redpanda spoke CIDR. Your hub public route table must include a static route for this CIDR with the Transit Gateway as the target so reply traffic from the internet routes back to the cluster. Add this route when you provision the hub. See Create an AWS Hub for Centralized Egress. The Transit Gateway’s own route table picks up the spoke CIDR automatically through route propagation when the spoke attaches.

Internet endpoints required from your hub

The Redpanda VPC uses Interface VPC Endpoints for ECR (ecr.api and ecr.dkr), STS, and CloudWatch Logs, so traffic to those AWS services does not leave the Redpanda VPC. Your hub VPC must still provide internet egress for the following non-AWS endpoints:

Endpoint Protocol and port Purpose

docker.cloudsmith.io

TCP/443

Redpanda container images

public.ecr.aws

TCP/443

EKS public CNI and network policy agent images

NTP servers

UDP/123

Time sync

prometheus-community.github.io and similar Helm repositories

TCP/443

Monitoring stack Helm charts

If your hub firewall enforces an allowlist, allow outbound traffic to these endpoints from the Redpanda spoke CIDR.

DNS resolution

Centralized egress does not affect DNS resolution. The Redpanda VPC uses AmazonProvidedDNS at VPC_CIDR + 2, which resolves both internal and external hostnames as long as 0.0.0.0/0 is routable through your hub. You do not need a separate DNS path or DNS resolver endpoint in your hub.

Troubleshooting

Symptom Likely cause

A new Transit Gateway VPC attachment from the Redpanda BYOC account appears in your hub AWS account with state pendingAcceptance, and cluster provisioning is stuck

Your Transit Gateway has AutoAcceptSharedAttachments set to disable. In the AWS account that owns the Transit Gateway, open VPC > Transit Gateway Attachments, select the pending attachment, and choose Actions > Accept transit gateway attachment. To remove this manual step on future BYOC cluster provisions, set AutoAcceptSharedAttachments=enable on the Transit Gateway, but only if you trust every account the Transit Gateway is shared with through AWS RAM.

The Transit Gateway resource share does not appear in the BYOC AWS account, or cluster creation rejects the Transit Gateway ID

The BYOC AWS account has not accepted the AWS RAM share invitation, so Redpanda cannot see the Transit Gateway. In that account, open AWS RAM and accept the pending invitation under Resource share invitations. Within an AWS Organization, shares are auto-accepted.

Cluster creation does not complete

The cluster cannot reach the external services it needs during bootstrap. On the hub side, verify all of the following: the Transit Gateway default route table has 0.0.0.0/0 to the hub VPC attachment; the hub public route table has a static route for the Redpanda spoke CIDR to the Transit Gateway; the hub firewall allowlist includes the endpoints in Internet endpoints required from your hub; and the hub VPC CIDR and the Redpanda spoke CIDR do not overlap. If these all look correct, contact Redpanda Support.

Next steps