Edit

Share via

About migrating to an availability zone-enabled ExpressRoute virtual network gateway

  • Article

When you create an ExpressRoute virtual network gateway, selecting the appropriate gateway SKU is crucial. Higher-level SKUs allocate more CPUs and network bandwidth to the gateway, enabling higher network throughput and more reliable connections to the virtual network.

Available SKUs for ExpressRoute Virtual Network Gateways

The following SKUs are available:

  • Standard
  • HighPerformance
  • UltraPerformance
  • ErGw1Az
  • ErGw2Az
  • ErGw3Az
  • ErGwScale (Preview)

Availability Zone-Enabled SKUs

The SKUs ErGw1Az, ErGw2Az, ErGw3Az, and ErGwScale (Preview) are referred to as Availability Zone (Az)-Enabled SKUs. These SKUs support deployment across multiple availability zones, providing enhanced resiliency and high availability by distributing the gateway infrastructure across zones.

In contrast, the Standard, HighPerformance, and UltraPerformance SKUs, also known as non-Az-enabled SKUs, are typically associated with Basic IPs and don't support distribution across availability zones.

Recommendation for enhanced reliability

For improved reliability, we recommend using an Az-enabled virtual network gateway SKU. These SKUs support zone-redundant configurations and are associated with Standard IPs by default. A zone-redundant setup ensures that the gateway infrastructure remains operational even if one availability zone encounters an issue. To learn more about zone-redundant gateways, see Availability Zone deployments.

Gateway migration experience

Previously, migrating between SKUs required using the Resize-AzVirtualNetworkGateway PowerShell command or manually deleting and recreating the virtual network gateway.

The guided gateway migration experience simplifies this process by allowing you to deploy a second virtual network gateway within the same GatewaySubnet. Azure automatically transfers the control plane and data path configurations from the old gateway to the new one. During the migration, both gateways operate simultaneously within the same GatewaySubnet. While this feature minimizes disruption, brief connectivity interruptions might still occur.

Once the migration is complete and the old gateway along with its connections are deleted, the newly created gateway is tagged with "CreatedBy : GatewaySKUMigration". This tag helps distinguish migrated gateways from others that haven't undergone migration and shouldn't be deleted.

Steps to Migrate to a New Gateway

  1. Validate: Confirm that all resources are in a succeeded state to ensure the gateway is ready for migration. If prerequisites aren't met, the validation process fails, and migration can't proceed.
  2. Prepare: Create a new virtual network gateway, public IP, and connections. This step can take up to 45 minutes. You can specify a preferred name for the new gateway and connections. If no name is provided, the system appends the tag _migrate by default. During this step, the existing virtual network gateway is locked, preventing any creation or modification of connections.
  3. Migrate: Transfer traffic from the old gateway to the new one by selecting the new gateway. This operation can take up to 15 minutes and could result in brief connectivity interruptions.
  4. Commit: Finalize the migration by deleting the old gateway and its connections.

Important

After completing the migration, validate your connectivity to ensure everything is functioning as expected. If needed, you can revert to the old gateway by selecting Abort after the prepare step. This action deletes the new gateway and its connections.

Migration source (Non-Az-enabled gateway SKU) Migration target (Az-enabled gateway SKU)
Standard, HighPerformance, UltraPerformance ErGw1Az, ErGw2Az, ErGw3Az, ErGwScale (Preview)
Basic IP Standard IP

Supported Migration Scenarios

Using Azure portal and Azure PowerShell

The guided gateway migration experience supports the following scenarios:

  • Migrating from a non-Az-enabled SKU with a Basic IP to a non-Az-enabled SKU with a Standard IP.
  • Migrating from a non-Az-enabled SKU with a Basic IP to an Az-enabled SKU with a Standard IP.

For enhanced reliability and high availability, we recommend migrating to an Az-enabled SKU. For detailed steps, see Migrate to an availability zone-enabled ExpressRoute virtual network gateway using PowerShell.

Limitations

The guided gateway migration experience has the following limitations:

  • Downgrade scenarios, such as migrating from an Az-enabled SKU to a non-Az-enabled SKU, aren't supported.
  • The GatewaySubnet must have a prefix of /27 or longer to proceed with the migration.
  • Private endpoints (PEs) in the virtual network connected through ExpressRoute private peering can experience connectivity issues during migration. For guidance on mitigating these issues, see Private endpoint connectivity.
  • ExpressRoute Gateways that were established or connected to circuits in 2017 or earlier.

Common Validation Errors

During the gateway migration process, it's essential to validate whether your resources are ready for migration. Below are some common validation errors you can encounter:

Virtual Network

  • MaxGatewayCountInVnetReached: This error indicates that the maximum number of gateways allowed in the virtual network was reached.

Next Steps