Repeated VpnGw1AZ deployment failure in West US: VmssGatewayDeploymentFailed on clean recreation

Open an Azure support request for VPN Gateway deployment/provisioning failure and ask Microsoft to trace the listed correlation IDs, because the clean VpnGw1AZ recreation failing before P2S configuration leaves the underlying VMSS allocation as the next actionable investigation.

What to submit to Microsoft

In the Azure portal, go to Help + support → Create a support request, select the affected subscription, and use:

• Service: Virtual Network / VPN Gateway
• Problem type: Deployment or provisioning failure
• Region: West US
• SKU: VpnGw1AZ
• Severity: Select the level appropriate to the evaluation environment’s impact

Azure customers can create and manage VPN Gateway support requests through the portal.^1^

Include:

1. All three correlation IDs and both operation IDs.
2. Exact UTC timestamps for each failure.
3. Deployment name Microsoft.VirtualNetworkGateway-20261022142019.
4. Error codes:
   • VmssGatewayDeploymentFailed
   • ResourceOperationFailure
   • ResourceDeploymentFailure
   • CannotResetGatewayInFailedState
5. The minimal recreation parameters: West US, VpnGw1AZ, route-based, Generation 2, inactive BGP and active-active, and no P2S configuration.
6. Confirmation that:
   • The original gateway was deleted.
   • A clean gateway deployment reproduced the failure.
   • The failure occurred before P2S was configured.
   • The policy event was Audit, completed successfully, and was not Deny.
7. This explicit request:

Please trace the backend VPN Gateway/VMSS deployment operations for these correlation IDs and determine whether the failures are caused by allocation capacity, a regional platform fault, or orphaned backend resources. Please clear any stuck backend operation or allocation associated with the deleted gateway and confirm when a new VpnGw1AZ deployment can be retried in West US.

Correlation IDs are specifically useful for tracing failed resource deployments in support investigations.^2^

Check subscription-specific health information

Before submitting—or attach the result to the case—open:

1. Azure portal → Service Health
2. Select Service issues, then Health history
3. Filter by:
   • The affected subscription
   • West US
   • VPN Gateway
   • October 22, 2026
4. Open Resource Health for the gateway if the failed resource still exists.

Service Health contains subscription- and region-specific incidents that might not appear on the public Azure Status page; public status primarily reports widespread outages.^3^ Service Health events remain visible in Health History for up to 90 days after becoming inactive.^4^

No public status information currently establishes a West US + VpnGw1AZ + October 22, 2026 incident. That does not exclude a subscription-, cluster-, or allocation-specific platform problem.

What can and cannot be concluded

The evidence does not identify a confirmed root cause yet. However:

• P2S authentication and client-pool configuration are excluded by the minimal deployment failing before P2S was added.
• Another gateway reset is not applicable because Azure has already rejected reset while the gateway is in Failed.
• Another unchanged write is unlikely to add diagnostic value because it has already reproduced the same backend error.
• VmssGatewayDeploymentFailed has occurred in other regions during backend or capacity problems, including a case where Microsoft’s backend team confirmed capacity constraints and resolved them by increasing capacity.^5^ That case does not prove West US currently has the same cause, but it supports requesting a backend capacity/allocation trace.

Microsoft documentation says a persistent failed state that cannot be recovered is a platform-side condition requiring an Azure support request.^6^

Same-region recovery

A new VpnGw1AZ gateway can generally be deployed in a region even if that region does not provide zone redundancy; in that case, the AZ-capable SKU operates regionally.^7^ Therefore, moving the existing VNet is not established as necessary.

The appropriate same-region recovery sequence is:

1. Have Microsoft confirm or clear the failed backend allocation.
2. Wait for support to confirm that a retry is safe.
3. Redeploy the same minimal gateway in West US.
4. Confirm provisioningState: Succeeded.
5. Add P2S and other configuration only after base provisioning succeeds.

Do not use a generic GET/PUT failed-state repair on the deleted gateway. That procedure is intended to restore an existing resource’s state by issuing another write; the clean replacement has already shown that a fresh write reaches the same backend failure.^8^

References

1. Support and troubleshooting for Azure VPN Gateway
2. Open a support request for an Azure VMware Solution deployment or provisioning failure
3. Azure Service Health FAQ
4. Azure Service Health portal
5. VPN VNG - Deployment Failing in Chile Central - Microsoft Q&A
6. Troubleshoot a Site-to-Site or Point-to-Site VPN tunnel that won't connect in Azure VPN Gateway
7. VPN Gateway SKU consolidation and migration
8. Troubleshoot Azure Microsoft.Network failed provisioning state