![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(80, 91%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMA%3C/text%3E%3C/svg%3E)
Azure VPN Gateway
An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
Stop retrying or changing SKUs and have Azure VPN Gateway Support inspect the backend deployment records for all failed correlation IDs, because the configuration described meets the documented subnet and public-IP prerequisites and the generic VmssGatewayDeploymentFailed response does not expose the underlying cause.
What can be concluded
-
GatewaySubnetat/27is valid for VpnGw1AZ and VpnGw2AZ;/27or larger is required for non-Basic SKUs. An empty subnet without an NSG or route table also matches the documented requirements.^1^ - A Standard, static, IPv4 public IP covering zones 1, 2, and 3 is a supported zone-redundant configuration. For an AZ gateway SKU, the public IP's zone selection determines gateway placement.^2^
- VpnGw1AZ and VpnGw2AZ are the correct SKU family for zone-aware deployment.^3^
- The successful gateway in the same subscription and region reduces the likelihood of a subscription-wide quota or region-wide incompatibility, but it does not rule out capacity affecting a particular deployment stamp or another backend provisioning fault.
- There is no publicly confirmed Central India capacity incident tied to these failures. Azure Status covers broad incidents, whereas Service Health and Resource Health provide subscription- and resource-specific information.^4^
The exact backend cause—capacity placement, an orphaned internal deployment, or another fabric error—cannot be determined from the portal error or correlation ID outside Microsoft. A displayed-empty GatewaySubnet also cannot prove or disprove an internal stale reservation.
Required support action
Update the existing Severity B request rather than launching a seventh deployment:
- In Azure portal → Help + support → Support requests, open the existing case.
- Request transfer to the Azure Networking / VPN Gateway backend provisioning team.
- Ask them to query every failed operation by correlation ID and UTC timestamp and answer:
- Which internal VMSS/fabric operation failed?
- Did placement fail because of Central India zonal capacity?
- Does the VNet or
GatewaySubnetretain an orphaned gateway allocation after deletion of the Basic gateway? - Is cleanup required before redeployment?
- Can Microsoft provide a confirmed deployment stamp, zone, or SKU workaround?
- Attach the Activity Log JSON for every
Microsoft.Network/virtualNetworkGateways/writefailure—not only the summarized portal message. - Include the resource IDs of:
- The VNet and
GatewaySubnet - Each failed gateway
- Each associated public IP
- The working same-region gateway for comparison
- The VNet and
- State that six attempts using two AZ SKUs and fresh public IP resources failed over 11 hours, while policy, subnet sizing, subnet associations, and resource cleanup were already checked.
Microsoft documents Azure Support as the escalation path when VPN Gateway self-help does not resolve a deployment failure.^5^
Check tenant-specific platform health
While Support investigates:
- Open Azure portal → Service Health → Health advisories.
- Filter by the affected subscription, Central India, and VPN Gateway/Networking.
- Check Resource Health for the failed gateway before deleting it, if another attempt is authorized.
- Save screenshots or event details showing
Unavailable,Unknown, or a platform event and attach them to the case.
Resource Health distinguishes detected platform events from customer-triggered events and can expose support options for an unavailable resource.^6^
Conditional workaround
If Support confirms a zone-capacity problem and the partner's availability requirements permit a temporary zonal deployment, create a new Standard static public IP in one specified zone and deploy the AZ gateway against it. Specifying one zone makes the gateway zonal rather than zone-redundant.^2^
Do not use this merely as another blind retry: it reduces zone resilience and is appropriate only after Support identifies zonal placement as the failure or explicitly recommends the test. Similarly, do not recreate GatewaySubnet unless Support confirms stale backend state; the current /27 already satisfies the documented requirement.
References