Cloud
beta

Configure Centralized Egress with Azure Firewall

This feature is in beta and is available only on Azure 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 Azure Firewall and hub VNet instead of a Redpanda-managed NAT Gateway in the Redpanda VNet. When centralized egress is enabled, the Redpanda spoke VNet peers with your hub VNet, all outbound traffic exits through the Azure Firewall in your hub, and no 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 subscription

  • Troubleshoot egress failures caused by misconfigured hub routes or VNet peering

When to use centralized egress

Use centralized egress when:

  • Your security policy prohibits per-cluster NAT Gateways and requires all internet-bound traffic to traverse a centralized inspection point such as Azure Firewall or a third-party network virtual appliance (NVA).

  • You already operate a hub-and-spoke network in Azure 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 costs 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 one Azure NAT Gateway per availability zone in the Redpanda VNet. With centralized egress enabled, the agent skips NAT Gateway creation, peers the Redpanda VNet with your hub VNet, and creates a Route Table (UDR) on the Redpanda private subnets with a default route to your firewall’s private IP.

The following diagram shows the connectivity model:

+----------------------------------+         +----------------------------------+
| Redpanda VNet                    |         | Customer Hub VNet                |
| (Redpanda subscription)          |         | (Customer subscription)          |
|                                  |         |                                  |
| VNet Peering                     +<------->+ VNet Peering                     |
| allow_forwarded_traffic=true     |         | allow_forwarded_traffic=true     |
| Route Table (UDR)                |         | Azure Firewall (Standard)        |
| 0.0.0.0/0 -> Firewall private IP |         | SNAT to public IP                |
| No NAT Gateway                   |         |                                  |
| AKS Worker Nodes                 |         |                                  |
+----------------------------------+         +-----------+----------------------+
                                                          |
                                                          v
                                                      Internet
                                          (Cloudsmith, mcr.microsoft.com,
                                                    NTP, Helm)

Outbound traffic flow

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

  2. The subnet’s Route Table forwards 0.0.0.0/0 to the Azure Firewall’s private IP in the hub VNet.

  3. Because both sides of the VNet peering allow forwarded traffic, the packet crosses the peering even though its destination is outside either VNet’s own address space.

  4. The packet arrives at the Azure Firewall, which evaluates it against your firewall policy and performs SNAT to the firewall’s public IP.

  5. The packet exits to the internet.

Return traffic flow

  1. The internet response arrives at the firewall’s public IP.

  2. The Azure Firewall reverses the SNAT and forwards the packet back across the peering to the originating subnet.

  3. The packet arrives at the originating AKS node.

The hub VNet, Azure Firewall, and hub-side peering are your responsibility. Redpanda creates and manages the spoke-side peering and the Route Table (UDR). See Create an Azure 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.

  • Your BYOC cluster uses a Redpanda-managed VNet. Centralized egress is not available on BYOVNet clusters.

  • You have an existing hub VNet in the same region as the Redpanda BYOC cluster, with an Azure Firewall (or other NVA) providing internet egress. See Create an Azure Hub for Centralized Egress if you need to provision a hub.

  • Your hub VNet address space and the planned Redpanda spoke VNet address space do not overlap.

    Azure rejects VNet peering when address spaces overlap. Use a non-overlapping range for your hub. The 10.255.0.0/16 range used in examples on this page is only an example: it is a normal RFC 1918 range, so verify it does not conflict with your existing networks before using it. For background, see What are CIDRs?

  • The hub VNet’s Azure resource ID, in the form /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>.

  • The Azure Firewall’s private IP address in the hub VNet.

You create the VNet peering from the hub to the Redpanda spoke VNet after the network is provisioned, once the spoke VNet’s resource ID is available in the Redpanda Cloud console. See Configure egress at network creation. When you create that peering, enable allow_forwarded_traffic on both sides; this is what allows traffic forwarded by the Azure Firewall (a network virtual appliance) to cross the peering. allow_gateway_transit on the hub side is unrelated to firewall forwarding; enable it only if you also want the spoke to use a VPN/ExpressRoute gateway attached to the hub VNet.

Shared responsibility model

Component Owner

Redpanda spoke VNet, subnets, and AKS cluster

Redpanda

Spoke-side VNet peering with allow_forwarded_traffic = true

Redpanda

Route Table (UDR): 0.0.0.0/0 → firewall private IP

Redpanda

No NAT Gateway created in the spoke

Redpanda

Hub VNet

Customer

Hub-side VNet peering with allow_forwarded_traffic = true (allow_gateway_transit = true too, only if the hub also shares a VPN/ExpressRoute gateway)

Customer

Azure Firewall (or other NVA) and its policy rules

Customer

Firewall public IP

Customer

Egress path availability and HA

Customer

Redpanda does not manage the availability of the egress path. Plan for zone redundancy or the Premium tier in your hub if you need high availability or deep packet inspection. See Create an Azure Hub for Centralized Egress for sizing guidance.

Limitations

  • Centralized egress requires a Redpanda-managed VNet. It is not available on BYOVNet clusters.

  • You can enable centralized egress at network creation, or add, change, or remove hub_vnet_id and firewall_private_ip on an existing network through the Cloud UI. See Update egress on an existing network. Either way, the cluster’s infrastructure only picks up the change after you re-run rpk cloud byoc azure apply; the agent does not reapply network configuration on its own.

  • Turning centralized egress on or off on an existing cluster requires two consecutive runs of rpk cloud byoc azure apply. Azure won’t let the first apply delete the NAT Gateway (when enabling) or the hub-egress Route Table (when disabling) while a subnet is still attached to it, so the first apply moves subnets onto the new path and the second apply removes the now-unused resource. Run rpk cloud byoc azure apply again after the first one completes; the agent logs a warning naming the resource it’s still waiting to remove.

Configure egress at network creation

Centralized egress can be enabled at network creation, or added to an existing network later. Either way, provision the hub VNet and Azure Firewall first, since the request requires the hub VNet ID and firewall private IP. Create the VNet peering to the Redpanda spoke VNet after the network is provisioned, once the spoke VNet’s resource ID is available in the Redpanda Cloud console. See Create an Azure Hub for Centralized Egress.

Use the Cloud Console

  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 Azure for the full create flow.

  4. Set the connection type to Private. Centralized egress fields only appear for private clusters.

  5. On the Network page, enter the Hub egress VNet ID and Firewall private IP using the values you collected in Collect the values to provide to Redpanda. These fields are only visible if centralized egress is enabled for your organization.

  6. Click Next and complete the remaining steps.

After you click Create and run rpk cloud byoc azure apply, the Redpanda provisioner peers the Redpanda VNet with your hub VNet and creates a Route Table (UDR) that routes internet-bound traffic to your firewall’s private IP, without creating a NAT Gateway. The hub-side peering you created earlier becomes Connected once the reciprocal peering completes.

Update egress on an existing network

You can also add centralized egress to a network that was created without it, change the hub VNet ID or firewall private IP on a network that already has it set, or remove it and revert to the default NAT Gateway egress.

  1. Log in to Redpanda Cloud.

  2. On the Networks page, select the network.

  3. On the network’s Details page, find the Hub VNet row and click Edit (or Add if centralized egress isn’t set yet). This row only appears if centralized egress is enabled for your organization.

  4. Enter the Hub VNet ID and Firewall private IP and click Save, or click Remove hub VNet to revert to NAT Gateway egress.

  5. Follow the on-screen instructions to run rpk cloud byoc azure apply, then confirm you’ve applied the change.

Saving or removing the hub VNet through the Cloud UI only updates the stored network configuration. Re-run rpk cloud byoc azure apply so the agent applies the change to the VNet peering and Route Table (UDR). If you change the hub VNet, also create the new hub-side peering (and remove the old one) as described in Create an Azure Hub for Centralized Egress.

If this update adds centralized egress to a network that previously used the default NAT Gateway, or removes it back to the default, run rpk cloud byoc azure apply twice. Azure rejects deleting the NAT Gateway or the hub-egress Route Table while a subnet still references it, so the first apply moves subnets onto the new path and leaves the old resource in place; the second apply removes it. Changing the hub VNet ID or firewall private IP while centralized egress stays enabled the whole time only needs one apply.

Internet endpoints required from your hub

Your hub Azure Firewall must provide internet egress for the following endpoints. If your firewall policy enforces an allowlist, allow outbound traffic to these endpoints from the Redpanda spoke address space:

Endpoint Protocol and port Purpose

docker.cloudsmith.io

TCP/443

Redpanda container images

mcr.microsoft.com

TCP/443

AKS system images (CNI, kube-proxy, and other cluster add-ons)

NTP servers

UDP/123

Time sync

prometheus-community.github.io and similar Helm repositories

TCP/443

Monitoring stack Helm charts

docker.cloudsmith.io, mcr.microsoft.com, and the Helm repository hostnames are FQDNs on TCP/443. Allow them with Azure Firewall application rules, which filter HTTPS traffic by hostname using the TLS SNI and don’t require DNS proxy. NTP is UDP-based, which application rules don’t support, so allow it with a network rule using your NTP servers' actual destination IP addresses (or an FQDN in a network rule if you enable DNS proxy on the firewall).

DNS resolution

Centralized egress does not affect DNS resolution. The Redpanda VNet uses Azure-provided DNS at 168.63.129.16. Azure resolves this address using a platform route that bypasses your subnet’s UDRs entirely, so DNS resolution works regardless of whether 0.0.0.0/0 is routed through your hub. You do not need a separate DNS path or DNS resolver endpoint in your hub.

Troubleshooting

Symptom Likely cause

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: both the hub-side and spoke-side VNet peerings show Connected; allow_forwarded_traffic is enabled on both peerings; the firewall policy allowlist includes the endpoints in Internet endpoints required from your hub; and the hub VNet address space and the Redpanda spoke address space do not overlap. If these all look correct, contact Redpanda Support.

VNet peering stays in a non-connected state

The reciprocal peering from the Redpanda spoke VNet has not been created yet. This is expected until cluster provisioning completes. If the cluster is already running, confirm that allow_forwarded_traffic is enabled on both peerings.

VNet peering creation fails with an address space conflict error

The spoke VNet address space overlaps the hub VNet address space. Choose non-overlapping address spaces for the hub and every spoke.

Outbound traffic is intermittently dropped

Your firewall policy is not allowlisting the endpoints required by Redpanda. See Internet endpoints required from your hub.

All traffic appears to come from one public IP

This is the expected behavior of centralized egress. Use that IP for outbound allowlisting.

Updated hub_vnet_id or firewall_private_ip has no effect

Updating the network resource through the Cloud UI or Cloud API only changes the stored configuration. Re-run rpk cloud byoc azure apply to apply the change to the VNet peering and Route Table.

NAT Gateway or hub-egress Route Table still exists after toggling centralized egress

Azure won’t delete a NAT Gateway or Route Table while a subnet still references it. The agent logs a warning and leaves the old resource in place until the next apply reconciles the subnets onto the new path. Run rpk cloud byoc azure apply again to remove it.

Next steps