ExpressRoute virtual network gateway repeatedly fails with VmssGatewayDeploymentFailed in Australia East

Stop repeating the identical deployment and open an Azure support request for the Australia East gateway provisioning failure; if one controlled configuration test is required, use the Standard ExpressRoute gateway SKU with the Single-homed resiliency model for this one-circuit proof of concept.

Configuration to use

• Region: Australia East — supported for Azure Multicloud Interconnect Preview.
• Bandwidth: 1 Gbps — the supported preview bandwidth.
• Gateway type: ExpressRoute — required to connect the interconnect circuit to the VNet.
• Gateway SKU: Standard — a supported ExpressRoute gateway SKU.
• Resiliency model: Single-homed — appropriate when the gateway will connect to one circuit at one location.
• GatewaySubnet: /26 — sufficient; new ExpressRoute gateway deployments require /27 or larger.
• Public IP: allow Azure to assign the Standard public IP automatically.

Australia East, AWS, 1-Gbps bandwidth, and one gateway connection per Multicloud Interconnect are within the documented preview scope.^1^ The documented workflow is to create the ExpressRoute gateway and then create the connection from that gateway to the interconnect circuit.^2^

“Standard” can refer to two separate settings here:

1. ExpressRoute gateway SKU: Standard is supported, along with HighPerformance and UltraPerformance.
2. Public IP SKU: Azure now automatically assigns a Standard public IP to an ExpressRoute gateway.

Your /26 subnet exceeds the /27 minimum, so changing or recreating GatewaySubnet is not indicated by the documented requirements.^3^

Why Multi-homed is not the right PoC setting

Multi-homed is not documented as an Azure Multicloud Interconnect prerequisite. ExpressRoute Resiliency Guard defines it as a topology connected to either:

• at least two circuits in different physical locations, or
• an ExpressRoute Metro circuit.

Single-homed is the documented model for one circuit at one location.^4^ Because Multicloud Interconnect Preview supports one gateway connection per interconnect, a one-circuit PoC does not satisfy the documented multi-homed topology.

Resiliency Guard itself is also in public preview and requires subscription enablement through its preview form. If the portal exposed the resiliency setting but preview enrollment was not completed, include that fact in the support case rather than assuming enrollment succeeded.

Recovery and escalation

The public documentation does not confirm an active Australia East capacity incident matching this exact combination. Check both:

• Azure Service Health in the affected subscription, for subscription-specific advisories.
• The public ExpressRoute status page.^5^

The repeated VmssGatewayDeploymentFailed after four clean attempts, while the VNet, subnet, and circuit are healthy, needs Microsoft to inspect the managed gateway deployment. The underlying gateway VMs are created and managed by Azure and aren't directly accessible to customers.^6^

Create the request through Azure portal → Help + support → Create a support request, using the closest ExpressRoute / virtual network gateway provisioning problem classification. Include:

• Region: Australia East
• Resource ID of the VNet gateway
• VNet and GatewaySubnet resource IDs
• Multicloud Interconnect circuit resource ID
• Exact UTC start and failure times for all four attempts
• Activity Log correlationId, operation ID, and full JSON error
• Gateway SKU and resiliency model
• Confirmation that /26 has no NSG or route table
• Confirmation that no circuit connection exists yet
• Result of the portal diagnostics
• Whether Resiliency Guard Preview is enabled for the subscription

Ask support to verify:

1. Australia East VMSS placement/capacity for ExpressRoute gateways.
2. A regional or subscription-specific deployment stamp failure.
3. Multicloud Interconnect and Resiliency Guard preview registration.
4. Whether the failed resource has backend artifacts requiring cleanup.

A failed provisioning state records that the last control-plane operation failed; dependent operations can subsequently fail until the resource is returned to Succeeded.^7^ There is no documented customer-side repair command in the supplied guidance for a standalone Microsoft.Network/virtualNetworkGateways resource whose underlying VMSS never deployed.

Whether to try another SKU or region

• Single-homed test: justified, because it matches the planned one-circuit topology and differs materially from the four Multi-homed attempts.
• Higher SKU: not a documented fix for creation-time VmssGatewayDeploymentFailed; test only if Microsoft confirms SKU-specific capacity.
• Another supported region: useful as an isolation test, not as proof that Australia East has a capacity incident. The preview also supports East US, Germany West Central, and West US, but moving regions changes the PoC topology and provider-region mapping.^1^

References

1. Azure Multicloud Interconnect Preview availability and limits
2. Create an Azure Multicloud Interconnect Preview resource
3. Configure a virtual network gateway for ExpressRoute using the Azure portal
4. ExpressRoute Resiliency Guard (Preview)
5. Azure status
6. Reliability in Azure virtual network gateways (expressroute)
7. Troubleshoot Azure Microsoft.Network failed provisioning state