Troubleshoot Application Gateway deployment, scaling, and deletion failures

Summary

This article provides step-by-step guidance to diagnose and resolve failures that occur when you deploy, scale, or delete Azure Application Gateway.

Application Gateway deployment, scaling, and deletion operations might fail for several reasons, including:

• The deploying identity lacks required role-based access control (RBAC) permissions.
• The resource locks block lifecycle operations.
• The Application Gateway subnet is misconfigured (wrong size, conflicting delegations, or a universal user-defined route (UDR) as the default route that doesn't point to the internet).
• Orphaned configuration references exist and prevent scaling or deletion.
• Azure Key Vault certificate access is denied.

Symptoms

You might encounter one or more of the following symptoms:

• Azure Resource Manager (ARM) deployment fails and returns "code": "AuthorizationFailed" and the following message:

  The client '{OBJECT_ID}' with object id '{OBJECT_ID}' doesn't have authorization to perform 'Microsoft.Network/applicationGateways/write' over scope '/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/{RESOURCE_GROUP}/providers/Microsoft.Network/applicationGateways/{RESOURCE_NAME}'.

• Deployment or deletion fails and returns "code": "ScopeLocked" and the following message:

  The scope '/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/{RESOURCE_GROUP}' or a parent scope has a delete lock. Remove the lock before performing the delete operation..

• Deployment or update fails amd returns "code": "OperationNotAllowed" and a message that references a locked resource.

• The provisioning state is stuck at Updating or Failed, and the gateway is unresponsive to further configuration changes.

• Deployment fails and returns "code": "SubnetTooSmall" or the following message:

  Application Gateway V2 requires a subnet of at least /24 size.

• Deployment fails and returns "code": "InvalidSubnet" and the following message:

  Subnet '{SUBNET_NAME}' is delegated to a different service and can't be used by Application Gateway.

• Deployment fails and returns "code": "ApplicationGatewaySubnetCannotHaveOtherResourceTypes", and other resources (such as virtual machines (VMs) and private endpoints) exist in the Application Gateway subnet.

• Deployment or network security group (NSG) attach fails and returns "code": "ApplicationGatewaySubnetInboundTrafficBlockedByNetworkSecurityGroup" and the following message:

  Network security group ... blocks incoming internet traffic on ports 65200 - 65535 ... This isn't permitted for Application Gateways that have V2 Sku..

• Scaling or deletion fails and returns "code": "InternalServerError" and details that reference an orphaned path-map rule, back-end pool, or HTTP settings that reference a deleted resource.

• Deployment fails and returns the following message:

  The default route in the Application Gateway subnet must have a next hop type of 'Internet'.

• Deployment or update fails and returns "code": "LinkedAccessCheckFailed" and the following message that references Key Vault:

  The user, group, or application... doesn't have secrets get permission on key vault....

• Deployment fails and returns "code": "ApplicationGatewayKeyVaultSecretException" and the following message:

  Unable to retrieve certificate '{CERT_NAME}' from Key Vault '{VAULT_NAME}'.

• Deletion appears to stop responding, and the Azure portal shows a deletion in progress for more than 30 minutes.

• az network application-gateway show returns "provisioningState": "Failed" without a clear error message.

• Deployment fails and returns "code": "ResourceProviderNotRegistered" and the following message:

  The subscription isn't registered to use namespace 'Microsoft.Network'.

• Application Gateway autoscales to many more instances than expected. This problem causes cost spikes or capacity concerns. No deployment error occurs. However, unexpected scaling behavior occurs.

Prerequisites

To troubleshoot Application Gateway deployment, scaling, and deletion failures, you need the following items:

• Permissions required: Contributor role on the resource group (or Owner role for RBAC assignment operations), Network Contributor role for subnet operations.
• Tools: Azure CLI 2.x, or an AI agent that has Azure MCP access
• Required variables and examples of those variables, as shown in the following table

Diagnostic steps

Step 1

Check whether the deployment succeeded, failed, or is stuck. Also, check the specific error code and message from the ARM deployment operation.

Run the following commands in Azure CLI:

Option 1: Application Gateway already exists (update, scale, or delete failures)

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{provisioningState:provisioningState, operationalState:operationalState, sku:sku, autoscale:autoscaleConfiguration}" \
  --output json

Option 2: A new deployment that failed

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG

az deployment group list \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[?properties.provisioningState=='Failed'].{name:name, timestamp:properties.timestamp, error:properties.error}" \
  --output json

To get detailed error information from a specific failed deployment:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$DEPLOYMENT_NAME" ] && read -rp "Deployment Name: " DEPLOYMENT_NAME

az deployment operation group list \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$DEPLOYMENT_NAME" \
  --query "[?properties.provisioningState=='Failed'].{resource:properties.targetResource.resourceType, statusCode:properties.statusCode, errorCode:properties.statusMessage.error.code, errorMessage:properties.statusMessage.error.message}" \
  --output json

Interpret the results

Step 2

Check whether the Microsoft.Network resource provider is registered in the subscription. Unregistered providers cause all network resource deployments to fail.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION

az provider show \
  --namespace Microsoft.Network \
  --subscription "$SUBSCRIPTION" \
  --query "{registrationState:registrationState, namespace:namespace}" \
  --output json

Interpret the results

Step 3

Check whether the identity that performs the deployment (user, service principal, or managed identity) has the required permissions to create or modify Application Gateway resources and join the subnet.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG

az role assignment list \
  --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$RG" \
  --subscription "$SUBSCRIPTION" \
  --include-inherited \
  --query "[].{principal:principalName, role:roleDefinitionName, scope:scope}" \
  --output table

To check the specific identity that failed, use the {OBJECT_ID} from the AuthorizationFailed error message:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$OBJECT_ID" ] && read -rp "Identity Object ID: " OBJECT_ID

az role assignment list \
  --assignee "$OBJECT_ID" \
  --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$RG" \
  --subscription "$SUBSCRIPTION" \
  --include-inherited \
  --query "[].{role:roleDefinitionName, scope:scope}" \
  --output table

Required permissions for Application Gateway lifecycle operations

Interpret the results

Step 4a

Check whether the Application Gateway subnet meets all requirements, including minimum size, no conflicting delegations, no other resource types present, and correct network configuration.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$VNET_NAME" ] && read -rp "VNet Name:       " VNET_NAME
[ -z "$SUBNET_NAME" ] && read -rp "Subnet Name:     " SUBNET_NAME

az network vnet subnet show \
  --vnet-name "$VNET_NAME" \
  --name "$SUBNET_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{addressPrefix:addressPrefix, delegations:delegations[].serviceName, ipConfigurations:ipConfigurations[].id, routeTable:routeTable.id, networkSecurityGroup:networkSecurityGroup.id, serviceEndpoints:serviceEndpoints[].service, privateEndpointNetworkPolicies:privateEndpointNetworkPolicies}" \
  --output json

Interpret the results

Step 4b

Check whether the NSG on the Application Gateway subnet allows the required inbound management traffic from the GatewayManager service tag.

Extract the NSG name from the Step 4a output, then run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$NSG_NAME" ] && read -rp "NSG Name:        " NSG_NAME

az network nsg rule list \
  --nsg-name "$NSG_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, direction:direction, access:access, priority:priority, sourcePrefix:sourceAddressPrefix, destPorts:destinationPortRange}" \
  --output table

Interpret the results

Step 5

Check whether any delete or read-only locks exist on the resource group or individual resources that block deployment, update, scaling, or deletion operations.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG

az lock list \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output table

To also check subscription-level locks:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION

az lock list \
  --subscription "$SUBSCRIPTION" \
  --query "[?level=='Subscription'].{name:name, level:level, lockLevel:properties.level, notes:notes}" \
  --output table

Interpret the result

Step 6

Check whether a UDR on the Application Gateway subnet has a 0.0.0.0/0 default route that points to the internet. Application Gateway v2 requires that the default route next hop is the internet. Routing through a network virtual appliance (NVA) or VPN gateway causes deployment and health probe failures.

If Step 4a showed a route table attached to the subnet, extract the route table name from the resource ID, and then run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$ROUTE_TABLE_NAME" ] && read -rp "Route Table Name: " ROUTE_TABLE_NAME

az network route-table route list \
  --route-table-name "$ROUTE_TABLE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, addressPrefix:addressPrefix, nextHopType:nextHopType, nextHopIp:nextHopIpAddress}" \
  --output table

Interpret the results

Step 7

Check whether the Application Gateway's managed identity has the required permissions to read certificates from Key Vault, and whether the Key Vault network configuration allows access from the Application Gateway subnet.

Run the following commands in Azure CLI:

1. Identify the managed identity that's assigned to the Application Gateway:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "identity" \
  --output json

2. Record the {MANAGED_IDENTITY_PRINCIPAL_ID} from identity.userAssignedIdentities.<id>.principalId.
3. Check the Key Vault access policy or RBAC for that identity:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:  " VAULT_NAME

az keyvault show \
  --name "$VAULT_NAME" \
  --subscription "$SUBSCRIPTION" \
  --query "{enableRbacAuthorization:properties.enableRbacAuthorization, enableSoftDelete:properties.enableSoftDelete, networkAcls:properties.networkAcls}" \
  --output json

4. If Key Vault uses access policies (enableRbacAuthorization is false), check the access policy for the managed identity:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:       " SUBSCRIPTION
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:        " VAULT_NAME
[ -z "$IDENTITY_PRINCIPAL_ID" ] && read -rp "Identity Principal ID: " IDENTITY_PRINCIPAL_ID

az keyvault show \
  --name "$VAULT_NAME" \
  --subscription "$SUBSCRIPTION" \
  --query "properties.accessPolicies[?objectId=='$IDENTITY_PRINCIPAL_ID'].{objectId:objectId, secretPermissions:permissions.secrets, certificatePermissions:permissions.certificates}" \
  --output json

5. If Key Vault uses RBAC (enableRbacAuthorization is true), check the role assignments for the managed identity:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:          " SUBSCRIPTION
[ -z "$IDENTITY_PRINCIPAL_ID" ] && read -rp "Identity Principal ID:    " IDENTITY_PRINCIPAL_ID
[ -z "$KV_RG" ] && read -rp "Key Vault Resource Group: " KV_RG
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:           " VAULT_NAME

az role assignment list \
  --assignee "$IDENTITY_PRINCIPAL_ID" \
  --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$KV_RG/providers/Microsoft.KeyVault/vaults/$VAULT_NAME" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{role:roleDefinitionName}" \
  --output table

6. Check Key Vault network access:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:  " VAULT_NAME

az keyvault network-rule list \
  --name "$VAULT_NAME" \
  --subscription "$SUBSCRIPTION" \
  --output json

Interpret the result

Step 8

Check whether the Application Gateway configuration contains references to deleted or nonexistent back-end pools, HTTP settings, probes, or certificates that prevent scaling, updates, or deletion.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output json > appgw-config.json

Inspect the configuration for cross-reference integrity.

Option 1: Check the URL path maps for orphaned back-end references

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{pathMaps:urlPathMaps[].{name:name, defaultBackend:defaultBackendAddressPool.id, defaultHttpSettings:defaultBackendHttpSettings.id, rules:pathRules[].{path:paths, backend:backendAddressPool.id, httpSettings:backendHttpSettings.id}}, backends:backendAddressPools[].{name:name, id:id}, httpSettings:backendHttpSettingsCollection[].{name:name, id:id}}" \
  --output json

Option 2: Check routing rules for orphaned listener or back-end references

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "requestRoutingRules[].{name:name, ruleType:ruleType, listener:httpListener.id, backendPool:backendAddressPool.id, backendSettings:backendHttpSettings.id, urlPathMap:urlPathMap.id}" \
  --output json

Interpret the results

Step 9

Check whether autoscaling is configured to have effective minimum and maximum instance bounds. A gateway can report provisioningState: "Succeeded" while still scaling beyond expectations because no maximum capacity is set. This step exposes the discriminating items (the sku tier and the autoscaleConfiguration bounds) that separate an unbounded-autoscaling cost spike from a genuinely healthy gateway.

Run the following commands in Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{tier:sku.tier, capacity:sku.capacity, autoscaleConfiguration:autoscaleConfiguration}" \
  --output json

Interpret the results

Decision map

Use the following decision map table to determine the appropriate next steps based on your diagnostic results.

Resolution A

The Microsoft.Network resource provider isn't registered in the subscription. All Azure networking resource deployments (including Application Gateway) require this provider to be registered.

Run the following commands in Azure CLI:

1. Register the provider:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION

az provider register \
  --namespace Microsoft.Network \
  --subscription "$SUBSCRIPTION"

2. Wait for the registration to complete (1-5 minutes). After five minutes, check the status:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION

az provider show \
  --namespace Microsoft.Network \
  --subscription "$SUBSCRIPTION" \
  --query registrationState \
  --output tsv

3. Wait until the output shows Registered.
4. Rerun the deployment.

The ResourceProviderNotRegistered error shouldn't occur.

If the deployment still fails with a different error, return to Step 1 and continue diagnosis.

Resolution B

The identity performing the Application Gateway deployment (user account, service principal, or managed identity) doesn't have sufficient permissions to create, update, or delete the Application Gateway resource and join the subnet.

Common contributing causes include:

• The service principal used in Continuous Integration (CI) and Continuous Delivery (CD) has Reader instead of Contributor permissions.
• The managed identity used in infrastructure-as-code (IaC) hasn't been assigned a role on the target resource group.
• The VNet is in a different resource group and the identity lacks Network Contributor permissions on that resource group.
• A custom role definition is missing for Microsoft.Network/virtualNetworks/subnets/join/action.

Run the following commands in Azure CLI:

1. Identify the deployment scenario and the minimum role required for the identity performing the deployment.

2. Assign the required roles to the identity performing the deployment.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$OBJECT_ID" ] && read -rp "Identity Object ID: " OBJECT_ID
[ -z "$ROLE_NAME" ] && read -rp "Role Name:          " ROLE_NAME

az role assignment create \
  --assignee "$OBJECT_ID" \
  --role "$ROLE_NAME" \
  --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$RG" \
  --subscription "$SUBSCRIPTION"

If the VNet is in a different resource group, assign it to the correct one:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:     " SUBSCRIPTION
[ -z "$OBJECT_ID" ] && read -rp "Identity Object ID:  " OBJECT_ID
[ -z "$VNET_RG" ] && read -rp "VNet Resource Group: " VNET_RG

az role assignment create \
  --assignee "$OBJECT_ID" \
  --role "Network Contributor" \
  --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$VNET_RG" \
  --subscription "$SUBSCRIPTION"

3. Wait five minutes for the RBAC role assignments to propagate.
4. Rerun the deployment.

The AuthorizationFailed error should no longer occur.

If the deployment still fails with a different error, return to Step 1 and continue diagnosis.

Resolution C

The Application Gateway subnet doesn't meet one or more of the following requirements:

• Size: Microsoft recommends at least /24 (256 addresses) for v2 so autoscaling has IP headroom. v1 requires enough IPs for the configured instance count plus five. A v2 subnet smaller than /24 might provision initially but can later fail to scale out.
• Dedication: The subnet must contain only Application Gateway resources and no VMs, private endpoints, or other NICs.
• Delegations: The subnet must not have a service delegation to another service (for example, Microsoft.Sql/managedInstances or Microsoft.Web/serverFarms).

Run the following commands in Azure CLI (when applicable).

1. Review the output from Step 4a to identify which condition isn't met.
2. If the subnet is too small, create a new subnet with a larger address prefix and deploy the Application Gateway into that subnet.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$VNET_NAME" ] && read -rp "VNet Name:         " VNET_NAME
[ -z "$NEW_SUBNET_NAME" ] && read -rp "New Subnet Name:   " NEW_SUBNET_NAME
[ -z "$NEW_SUBNET_PREFIX" ] && read -rp "New Subnet Prefix: " NEW_SUBNET_PREFIX

az network vnet subnet create \
  --vnet-name "$VNET_NAME" \
  --name "$NEW_SUBNET_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --address-prefixes "$NEW_SUBNET_PREFIX"

3. If the subnet has a conflicting delegation, remove the delegation from the subnet.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$VNET_NAME" ] && read -rp "VNet Name:       " VNET_NAME
[ -z "$SUBNET_NAME" ] && read -rp "Subnet Name:     " SUBNET_NAME

az network vnet subnet update \
  --vnet-name "$VNET_NAME" \
  --name "$SUBNET_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --remove delegations

4. If the subnet contains VMs, private endpoints, or other NICs, identify each ipConfigurations entry from Step 4a and determine which resource it belongs to.

5. Rerun the deployment targeting the corrected or new subnet.

The SubnetTooSmall, InvalidSubnet, or ApplicationGatewaySubnetCannotHaveOtherResourceTypes errors shouldn't occur.

If the deployment still fails with a different error, return to Step 1 and continue diagnosis.

Resolution D

The NSG on the Application Gateway subnet blocks inbound management traffic on ports 65200–65535 (v2) or 65503–65534 (v1) from the GatewayManager service tag. Azure infrastructure requires this traffic to communicate with Application Gateway instances.

Run the following commands in Azure CLI (when applicable).

1. Determine if the NSG is blocking management traffic.

For Application Gateway v2

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$NSG_NAME" ] && read -rp "NSG Name:        " NSG_NAME

az network nsg rule create \
  --nsg-name "$NSG_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name Allow-AppGW-V2-Management \
  --priority 100 \
  --direction Inbound \
  --source-address-prefix GatewayManager \
  --destination-port-range "65200-65535" \
  --protocol Tcp \
  --access Allow

For Application Gateway v1

Replace the destination port range with 65503-65534.

2. Configure the NSG to allow inbound traffic on the listener ports (typically 80 and 443) if the Application Gateway has a public frontend IP.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$NSG_NAME" ] && read -rp "NSG Name:        " NSG_NAME

az network nsg rule create \
  --nsg-name "$NSG_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name Allow-HTTP-HTTPS \
  --priority 200 \
  --direction Inbound \
  --source-address-prefix Internet \
  --destination-port-ranges 80 443 \
  --protocol Tcp \
  --access Allow

3. Rerun Step 4a.

The management port rule should now appear. Retry the deployment or wait for the gateway to recover.

Resolution E

A CanNotDelete or ReadOnly lock on the resource group (or on an individual resource like the public IP, VNet, or NSG) prevents the Application Gateway lifecycle operation from completing.

• CanNotDelete locks prevent deletion and some updates that require resource recreation.
• ReadOnly locks prevent all write operations including deployment, scaling, configuration updates, and deletion.

1. Review the output from Step 5 and record the {LOCK_NAME} and the scope (resource group or specific resource).
2. Remove the lock from the resource group or resource.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$LOCK_NAME" ] && read -rp "Lock Name:       " LOCK_NAME

az lock delete \
  --name "$LOCK_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION"

If the lock is on a specific resource:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:      " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:       " RG
[ -z "$LOCK_NAME" ] && read -rp "Lock Name:            " LOCK_NAME
[ -z "$LOCKED_RESOURCE_NAME" ] && read -rp "Locked Resource Name: " LOCKED_RESOURCE_NAME
[ -z "$LOCKED_RESOURCE_TYPE" ] && read -rp "Locked Resource Type: " LOCKED_RESOURCE_TYPE

az lock delete \
  --name "$LOCK_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --resource-name "$LOCKED_RESOURCE_NAME" \
  --resource-type "$LOCKED_RESOURCE_TYPE"

3. Rerun the deployment, update, scaling, or deletion operation that previously failed.
4. After the operation completes successfully, reapply the lock to maintain governance controls.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$LOCK_NAME" ] && read -rp "Lock Name:       " LOCK_NAME
[ -z "$LOCK_TYPE" ] && read -rp "Lock Type (CanNotDelete or ReadOnly): " LOCK_TYPE

az lock create \
  --name "$LOCK_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --lock-type "$LOCK_TYPE"

5. Verify that the operation completed successfully (check provisioningState via Step 1) and that the lock is reapplied (rerun Step 5).

Resolution F

The route table attached to the Application Gateway subnet has a 0.0.0.0/0 (default) route value with a next hop type other than Internet. Application Gateway v2 requires symmetric routing as management traffic arrives from the internet and the response must go back the same way. Routing the default route through an NVA, VPN gateway, or dropping it (None) breaks this communication.

1. Review the output from Step 6 to identify the route table and default route that needs to be updated.

Option 1: Re-create the default route with Internet as the next hop

A 0.0.0.0/0 route that currently points to a VirtualAppliance can't simply be updated with --next-hop-type Internet as this change doesn't clear the inherited next-hop IP address. This condition causes the update to fail with NextHopIpAddressNotAllowed. The --next-hop-ip-address "" parameter is also rejected. Delete the default route and re-create it with no next-hop IP.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$ROUTE_TABLE_NAME" ] && read -rp "Route Table Name:   " ROUTE_TABLE_NAME
[ -z "$DEFAULT_ROUTE_NAME" ] && read -rp "Default Route Name: " DEFAULT_ROUTE_NAME

az network route-table route delete \
  --route-table-name "$ROUTE_TABLE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$DEFAULT_ROUTE_NAME"

az network route-table route create \
  --route-table-name "$ROUTE_TABLE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name default-internet \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type Internet

Option 2: Create a dedicated route table for the Application Gateway subnet

If the existing route table is shared with other subnets that require forced tunneling, create a new route table with the default route to Internet and associate it only with the Application Gateway subnet.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$VNET_NAME" ] && read -rp "VNet Name:       " VNET_NAME
[ -z "$SUBNET_NAME" ] && read -rp "Subnet Name:     " SUBNET_NAME

az network route-table create \
  --name appgw-route-table \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION"

az network route-table route create \
  --route-table-name appgw-route-table \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name default-internet \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type Internet

az network vnet subnet update \
  --vnet-name "$VNET_NAME" \
  --name "$SUBNET_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --route-table appgw-route-table

2. Add specific routes for your back-end subnets or on-premises networks through the NVA while keeping the 0.0.0.0/0 default route to the internet.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:       " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:        " RG
[ -z "$ROUTE_TABLE_NAME" ] && read -rp "Route Table Name:      " ROUTE_TABLE_NAME
[ -z "$BACKEND_SUBNET_PREFIX" ] && read -rp "Backend Subnet Prefix: " BACKEND_SUBNET_PREFIX
[ -z "$NVA_IP" ] && read -rp "NVA IP Address:        " NVA_IP

az network route-table route create \
  --route-table-name "$ROUTE_TABLE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name to-backend-via-nva \
  --address-prefix "$BACKEND_SUBNET_PREFIX" \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address "$NVA_IP"

3. Rerun Step 6.

The default route should now show nextHopType: Internet. Retry the deployment or wait for the gateway provisioning to recover.

Resolution G

The Application Gateway's user-assigned managed identity either doesn't exist or isn't associated with the gateway, doesn't have Get permissions on Key Vault secrets and certificates, or the Key Vault network firewall blocks access from the Application Gateway subnet.

Run the following commands in Azure CLI (when applicable):

1. Create a user-assigned managed identity and assign it to the Application Gateway.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG

az identity create \
  --name appgw-identity \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION"

2. Record the {IDENTITY_RESOURCE_ID} from the output (the full resource ID) and {IDENTITY_PRINCIPAL_ID} (the principalId).
3. Assign the identity to the Application Gateway:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:      " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:       " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:     " RESOURCE_NAME
[ -z "$IDENTITY_RESOURCE_ID" ] && read -rp "Identity Resource ID: " IDENTITY_RESOURCE_ID

az network application-gateway identity assign \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --identity "$IDENTITY_RESOURCE_ID"

4. Grant the managed identity Get permissions on Key Vault secrets and certificates.

If Key Vault uses access policies

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:       " SUBSCRIPTION
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:        " VAULT_NAME
[ -z "$IDENTITY_PRINCIPAL_ID" ] && read -rp "Identity Principal ID: " IDENTITY_PRINCIPAL_ID

az keyvault set-policy \
  --name "$VAULT_NAME" \
  --subscription "$SUBSCRIPTION" \
  --object-id "$IDENTITY_PRINCIPAL_ID" \
  --secret-permissions get \
  --certificate-permissions get

If Key Vault uses RBAC

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:          " SUBSCRIPTION
[ -z "$IDENTITY_PRINCIPAL_ID" ] && read -rp "Identity Principal ID:    " IDENTITY_PRINCIPAL_ID
[ -z "$KV_RG" ] && read -rp "Key Vault Resource Group: " KV_RG
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:           " VAULT_NAME

az role assignment create \
  --assignee "$IDENTITY_PRINCIPAL_ID" \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$KV_RG/providers/Microsoft.KeyVault/vaults/$VAULT_NAME" \
  --subscription "$SUBSCRIPTION"

5. If the Key Vault has a network firewall enabled, add the Application Gateway subnet to the Key Vault's allowed network rules.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$VNET_NAME" ] && read -rp "VNet Name:       " VNET_NAME
[ -z "$SUBNET_NAME" ] && read -rp "Subnet Name:     " SUBNET_NAME
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:  " VAULT_NAME

az keyvault network-rule add \
  --name "$VAULT_NAME" \
  --subscription "$SUBSCRIPTION" \
  --subnet "/subscriptions/$SUBSCRIPTION/resourceGroups/$RG/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

6. If the subnet doesn't have the Key Vault service endpoint enabled, enable it:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$VNET_NAME" ] && read -rp "VNet Name:       " VNET_NAME
[ -z "$SUBNET_NAME" ] && read -rp "Subnet Name:     " SUBNET_NAME

az network vnet subnet update \
  --vnet-name "$VNET_NAME" \
  --name "$SUBNET_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --service-endpoints Microsoft.KeyVault

7. Rerun Step 7.

The managed identity now has the required permissions and network access. Retry the deployment or update.

8. If the issue persists, verify that the certificate that's referenced in the Application Gateway SSL configuration actually exists in the Key Vault:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$VAULT_NAME" ] && read -rp "Key Vault Name:   " VAULT_NAME
[ -z "$CERT_NAME" ] && read -rp "Certificate Name: " CERT_NAME

az keyvault certificate show \
  --vault-name "$VAULT_NAME" \
  --name "$CERT_NAME" \
  --query "{name:name, enabled:attributes.enabled, expires:attributes.expires}" \
  --output json

Resolution H

The Application Gateway configuration contains references to back-end pools, HTTP settings, probes, listeners, or SSL certificates that you deleted or are in an inconsistent state. This condition commonly occurs if you:

• Delete a back-end pool by using the Azure portal or an ARM template, but a URL path map still references it.
• Remove HTTP settings, but a routing rule or path map still points to them.
• Delete a listener but a redirect configuration that references it.
• Partially update an ARM template and remove some components but leave cross-references intact.

Run the following commands in Azure CLI (when applicable).

1. Review the output from Step 8. For each orphaned reference or record:

• Where it's referenced, including the path map name, routing rule name, or redirect configuration name.
• What's referenced, including the back-end pool name or ID, HTTP settings name or ID, or listener name or ID that no longer exists.

2. Decide whether to delete the orphaned reference or re-create the missing resource in place.

Begin by verifying how many routing rules the gateway has. The deletion approach is only viable if at least one other routing rule remains:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway rule list \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].name" \
  --output json

Interpret the results

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:   " RESOURCE_NAME
[ -z "$PATH_MAP_NAME" ] && read -rp "Path Map Name:      " PATH_MAP_NAME
[ -z "$ORPHANED_RULE_NAME" ] && read -rp "Orphaned Rule Name: " ORPHANED_RULE_NAME

az network application-gateway url-path-map rule delete \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --path-map-name "$PATH_MAP_NAME" \
  --name "$ORPHANED_RULE_NAME"

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:        " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:         " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:       " RESOURCE_NAME
[ -z "$PATH_MAP_NAME" ] && read -rp "Path Map Name:          " PATH_MAP_NAME
[ -z "$ROUTING_RULE_NAME" ] && read -rp "Routing Rule Name:      " ROUTING_RULE_NAME

az network application-gateway rule delete \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$ROUTING_RULE_NAME"

az network application-gateway url-path-map delete \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$PATH_MAP_NAME"

3. If the orphaned reference is in the gateway's only routing rule, re-create the missing resource in place.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:      " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:       " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:     " RESOURCE_NAME
[ -z "$MISSING_BACKEND_POOL_NAME" ] && read -rp "Missing Backend Pool: " MISSING_BACKEND_POOL_NAME
[ -z "$BACKEND_IP_OR_FQDN" ] && read -rp "Backend IP or FQDN:   " BACKEND_IP_OR_FQDN

az network application-gateway address-pool create \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$MISSING_BACKEND_POOL_NAME" \
  --servers "$BACKEND_IP_OR_FQDN"

4. If a routing rule references a deleted listener or back-end pool, run the following commands:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name:   " RESOURCE_NAME
[ -z "$ORPHANED_RULE_NAME" ] && read -rp "Orphaned Rule Name: " ORPHANED_RULE_NAME

az network application-gateway rule delete \
  --gateway-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$ORPHANED_RULE_NAME"

5. If multiple orphaned references exist, and individual cleanup is impractical, export the resource group as an ARM template.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG

az group export \
  --name "$RG" \
  --subscription "$SUBSCRIPTION" \
  --output json > appgw-template.json

6. To remove the orphaned references, edit appgw-template.json.
7. Before you redeploy, apply the following mandatory edits (the raw az group export output isn't redeployable verbatim):

• Remove the Application Gateway's top-level dependsOn array. az group export issues a circular dependency for Application Gateway resources. Therefore, the redeployment fails and returns InvalidTemplate: Circular dependency detected. ARM infers the correct ordering from the resourceId(...) property references. Therefore, you can delete the top-level dependsOn on the Microsoft.Network/applicationGateways resource to resolve it.
• Supply values for the exported resource-name parameters. az group export creates name parameters (for example, the gateway, virtual network, and public IP name parameters) without any defaultValue. Therefore, the redeployment stalls in a stdin state as it waits for input unless you pass them. Provide a value for each exported name parameter by using --parameters <paramName>=<value> on the redeploy command (see the following commands).

8. Redeploy the edited template. Supply a value for each exported name parameter.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME
[ -z "$VNET_NAME" ] && read -rp "VNet Name:        " VNET_NAME
[ -z "$PUBLIC_IP_NAME" ] && read -rp "Public IP Name:   " PUBLIC_IP_NAME

# Pass a value for each exported name parameter. Inspect the
# "parameters" block of appgw-template.json and add a matching
# --parameters <name>=<value> for every name parameter it declares.
az deployment group create \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --template-file appgw-template.json \
  --mode Incremental \
  --parameters applicationGateways_${RESOURCE_NAME}_name="$RESOURCE_NAME" \
  --parameters virtualNetworks_${VNET_NAME}_name="$VNET_NAME" \
  --parameters publicIPAddresses_${PUBLIC_IP_NAME}_name="$PUBLIC_IP_NAME"

9. Rerun Step 8.

All references should now resolve to existing resources. Retry the scaling, update, or deletion operation.

Resolution I

Application Gateway v2 that has autoscaling enabled has no minimum or maximum instance count configured. Therefore, it scales aggressively in response to traffic spikes. This configuration can cause unexpected cost increases or reach subscription capacity limits.

Run the following commands in Azure CLI (when applicable):

1. Review the current autoscaling configuration and SKU capacity.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{sku:sku, autoscaleConfiguration:autoscaleConfiguration}" \
  --output json

Interpret the results

2. If minCapacity and maxCapacity aren't set, configure them to appropriate values.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:  " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:   " RG
[ -z "$RESOURCE_NAME" ] && read -rp "App Gateway Name: " RESOURCE_NAME

az network application-gateway update \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --min-capacity 2 \
  --max-capacity 10

3. Rerun step 1, and verify that minCapacity and maxCapacity are set.
4. To verify scaling stays within bounds, Monitor CurrentCapacity metric over the next 24–48 hours.

References

• Application Gateway infrastructure configuration requirements
• Application Gateway v2 subnet requirements
• Supported Azure resource providers and types
• Azure built-in roles for networking
• Lock resources to prevent unexpected changes
• Application Gateway TLS policy overview and Key Vault integration
• Troubleshoot Azure Application Gateway
• Application Gateway v2 autoscaling and zone-redundancy