Skip to main content
Horizontal Transit Scaling with FireNet for Azure is Early Access in Controller 10.1. The migration action for existing deployments is API-only in this release and is not available in CoPilot. To request Early Access, contact your Aviatrix account team.
Azure Transit FireNet previously supported a maximum of two Transit gateways (primary and HA). Each firewall was associated with a specific gateway, and post-inspection return traffic routed directly from the firewall to its associated gateway. Horizontal scaling removes this limit by introducing an Azure Internal Load Balancer (ILB) for post-inspection return traffic. Firewalls send inspected traffic to the ILB, which distributes it across all healthy Transit gateways in the group. Firewalls are no longer associated with individual gateways.

​
How It Works

When horizontal scaling is active, the existing FireNet ILB gains a second frontend:
  • The forward-traffic frontend is the existing frontend that receives traffic heading to firewalls for inspection.
  • The post-inspection frontend is a new frontend on the same ILB that receives return traffic from firewalls after inspection, then distributes it across Transit gateway interfaces in a shared backend pool.
A TCP health probe on port 443 monitors each Transit gateway. If a gateway becomes unhealthy, the ILB stops routing post-inspection traffic to it. Because firewalls are no longer tied to specific gateways, they share a single subnet and can serve any gateway in the group. This decoupling is what enables scaling beyond two gateways.

​
Deployment Modes

Horizontal scaling supports two deployment modes with different scale limits: The firewall limits are derived from Azure subnet capacity (a /27 subnet provides 27 usable IP addresses; a /28 subnet provides 11 usable addresses after Azure reserves five).
Existing (pre-10.1) Transit FireNet deployments that have not been migrated cannot add a third Transit gateway and cannot delete the primary gateway. You must complete the migration to scale beyond two gateways.

​
Prerequisites

  • Aviatrix Controller 10.1 or later.
  • Gateway software 10.1 or later.
  • An Azure account onboarded to the Aviatrix Controller.
  • IPv6 must not be enabled on the Transit gateway group (horizontal scaling does not support IPv6).
  • No Azure Virtual Network Gateway (VNG) attached to the transit VNet (migration rejects VNG-attached transits).
  • For migrating an existing deployment: an existing Azure Transit FireNet deployment with primary and HA gateways.

​
New Deployment

Use this procedure to deploy a new Azure Transit FireNet with horizontal scaling enabled from the start.
1

Create the Transit gateway group

Create an Azure Transit gateway group with at least one availability zone. Select the Transit + FireNet VPC function when creating the VNet, or ensure the VNet already has the required subnets.
2

Enable Transit FireNet on the group

Enable Transit FireNet on the group following the standard FireNet creation workflow. See Configuring Transit FireNet for Azure for the detailed procedure.The Controller creates /27 subnets for the gateway interface and firewall LAN, creates both ILB frontends, and enables horizontal scaling automatically. No additional configuration is required.There is no separate control to turn on horizontal scaling. On Controller and CoPilot 10.1 or later, creating an Azure Transit FireNet from the + FireNet split button under Security > FireNet > FireNet always provisions it in horizontal scaling mode. Click the main + FireNet button (not the Add Egress Transit FireNet or Add AWS TGW FireNet dropdown options) to open the Add FireNet to Transit Gateway dialog. To confirm scaling is active after creation, open Security > FireNet > FireNet, select the Transit FireNet, and check the Horizontal Scaling field on the General Information panel. It reads Enabled and carries an Early Access tag.
3

Launch firewalls

Launch firewall instances as you normally would through the FireNet workflow. Each firewall lands in the shared firewall LAN subnet and is not associated with any specific Transit gateway.
4

Add Transit gateway instances

Add Transit gateway instances to the group (up to 15 total). Each new gateway is automatically added to the ILB backend pool.Navigate to the Transit gateway group settings and increase the instance count. The Controller adds the new gateway interfaces to the post-inspection backend pool and programs firewall LAN route tables to use the ILB frontend.
5

Attach spokes

Attach spoke gateways to the transit group as you normally would. Traffic from spokes is forwarded through the ILB to firewalls for inspection, then returned through the post-inspection frontend and distributed across healthy Transit gateways.

​
Migrating an Existing Deployment

Use this procedure to migrate an existing Azure Transit FireNet deployment (primary + HA, created before Controller 10.1) to horizontal scaling.
The migration is one-way and cannot be reversed. There is no rollback API. Once you migrate, the deployment permanently uses the horizontal scaling architecture. Ensure you have validated your configuration and have a maintenance window before proceeding.
During migration, the Controller reprograms firewall LAN route tables. Traffic that is in transit through the firewalls may be disrupted while route tables are updated. Plan for a maintenance window.

​
Migration Prerequisites

  • The existing Transit FireNet must have both a primary and an HA gateway.
  • IPv6 must not be enabled on the Transit gateway group.
  • No Azure Virtual Network Gateway (VNG) can be attached to the transit VNet.

​
Migration Procedure

1

Verify your deployment meets the prerequisites

Confirm that IPv6 is not enabled, no VNG is attached, and you have both primary and HA gateways running. Verify that all firewalls are healthy and passing traffic before you begin.
2

Call the migration API

Call the migration endpoint on the Controller:
Replace {gwgroup_name} with the name of your Transit gateway group.The Controller:
  • Creates the post-inspection ILB resources (backend pool, health probe, frontend, and load balancing rule) on the existing FireNet ILB.
  • Moves firewall and subnet configuration from per-gateway to a shared VPC-level scope.
  • Removes the gateway association from all firewall entries.
  • Reprograms firewall LAN route tables to point to the ILB post-inspection frontend.
The API is idempotent. If you call it again on an already-migrated deployment, it returns success without making changes.
3

Verify the migration

After the API call completes, verify that:
  • Traffic is flowing through the firewalls and returning to the transit gateways via the ILB.
  • The FireNet detail API response shows horizontal scaling as enabled.
  • Firewall entries no longer show a specific gateway association.
4

Add Transit gateway instances (optional)

You can now add Transit gateway instances up to 8 total. Each new gateway is automatically added to the ILB backend pool.The HA gateway retains its dedicated subnet from the original deployment. All other gateways share the primary gateway subnet.

​
Post-Migration Behavior

After migration:
  • Firewalls are resolved by VNet scope, not by gateway name.
  • New firewalls you launch land in the shared firewall LAN subnet.
  • The original HA gateway retains its dedicated subnet.
  • You cannot remove the primary gateway from the group.
  • The maximum number of Transit gateways is 8 (constrained by the /28 subnet from the original deployment).

​
Limitations

  • Azure only. Horizontal scaling is not available for AWS or GCP Transit FireNet in this release.
  • No FireNet removal. An Azure Transit FireNet cannot be removed after creation. Remove FireNet is available only for AWS; on Azure and GCP the action is disabled with the message Remove FireNet is not supported in <cloud>.
  • No migration rollback. The migration cannot be reversed.
  • No CoPilot migration UI. The migration action is available only through the Controller API.
  • IPv6 not supported. Transit gateway groups with IPv6 enabled cannot use horizontal scaling.
  • VNG not compatible. Transit VNets with an attached Virtual Network Gateway cannot be migrated.
  • BGP over LAN on instances 3+. External BGP connections are not available on Transit gateway instances beyond the primary and HA pair in this release.
  • Terraform not supported. No Terraform provider resources or attributes exist for horizontal scaling or the migration API.
  • Firewall health probe. If a Transit gateway fails the TCP 443 health probe, traffic through that gateway is disrupted. Existing flows do not migrate to other gateways.

​
Troubleshooting

If traffic is not flowing after enabling horizontal scaling or completing migration, work through the following checks in order.
1

Verify the ILB exists

Verify the ILB exists in the Azure portal. Look for the FireNet load balancer with two frontend IP configurations.
2

Check backend pool health

Check the backend pool health in Azure. All Transit gateway interfaces should show as healthy.
3

Confirm route table configuration

Confirm that firewall LAN route tables point to the post-inspection ILB frontend IP, not a specific gateway IP.
4

Confirm migration API success

For migrations of existing deployments, confirm the migration API returned success. Re-call the endpoint if needed. The API is idempotent.