> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Horizontal Transit Scaling with FireNet for Azure (Early Access)
> Scale Azure Transit FireNet beyond the two-gateway limit by deploying additional Transit gateway instances behind an internal load balancer. Covers new deployments and migration of existing deployments.
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:
| Mode | How activated | Max Transit gateways | Max firewalls | Notes |
| ------------------------------ | -------------------------------------------------------- | -------------------- | ------------- | ----------------------------------- |
| New deployment | Create a new Transit FireNet on Controller 10.1 or later | 15 | 27 | Uses /27 subnets |
| Existing deployment (migrated) | Call the migration API on an existing Transit FireNet | 8 | 11 | Constrained by existing /28 subnets |
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.
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.
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.
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.
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.
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
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.
Call the migration endpoint on the Controller:
```http theme={null}
POST /v2.5/firenet/{gwgroup_name}/migrate-to-post-inspection-lb
```
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.
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.
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
``**.
* **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.
Verify the ILB exists in the Azure portal. Look for the FireNet load balancer
with two frontend IP configurations.
Check the backend pool health in Azure. All Transit gateway interfaces should
show as healthy.
Confirm that firewall LAN route tables point to the post-inspection ILB frontend
IP, not a specific gateway IP.
For migrations of existing deployments, confirm the migration API returned
success. Re-call the endpoint if needed. The API is idempotent.
## Related Topics
* Configuring Transit FireNet for Azure
* Attaching Spoke Gateways to Transit FireNet
* Transit FireNet Diagnostics