[Azure] Azure backend may select App Service/Functions integration subnet, causing SubnetWithExternalResourcesCannotBeUsedByOtherResources #3931

When using the Azure backend with a custom VNet, dstack selects the first subnet returned by Azure that passes its current eligibility checks. In some VNets, this can select an Azure Functions/App Service VNet Integration subnet associated with Microsoft.Web/serverfarms. Azure rejects VM NIC creation in that subnet.

Observed error:

azure.core.exceptions.HttpResponseError:
(SubnetWithExternalResourcesCannotBeUsedByOtherResources)
Subnet .../virtualNetworks//subnets/10..0_24
referenced by .../networkInterfaces/nic_config-.../ipConfigurations/ip_config
cannot be used because it contains external resources.
The external resources in this subnet are
(Microsoft.Web/serverfarms,
.../providers/Microsoft.Web/serverfarms/).
You need to delete these external resources before deploying into this subnet.

Steps to reproduce:

1. Configure Azure backend with vpc_ids pointing to an existing VNet.
2. In that VNet, have multiple subnets.
3. Use one subnet for Azure Functions/App Service VNet Integration, so it is associated with Microsoft.Web/serverFarms.
4. Ensure that subnet is returned before the VM-compatible subnet by Azure’s subnet list API.
5. Run a dstack workload on Azure.
6. dstack may select the App Service/Functions subnet and VM creation fails with SubnetWithExternalResourcesCannotBeUsedByOtherResources.

Why this happens:

Microsoft.Web/serverfarms is the Azure resource type for App Service Plans. Azure Functions may run on App Service/Premium plans. App Service VNet Integration subnets must be empty, including no NICs or virtual machines, and delegated to Microsoft.Web/serverFarms. Azure subnet metadata also exposes serviceAssociationLinks as references to services injecting into a subnet. Therefore dstack should not select subnets with App Service/Functions service association links or Microsoft.Web/serverFarms delegation for VM provisioning.

Proposed fix:

One possible fix is to detect which subnets are associated with App Service/Functions and skip them. Possibly this ai generated idea would work:

subnet.service_association_links[*].linked_resource_type == "Microsoft.Web/serverfarms"
subnet.delegations[*].service_name == "Microsoft.Web/serverFarms"

This avoids relying as heavily on Azure’s subnet list order and prevents dstack from selecting subnets that Azure will reject for VM NIC creation.

Another possible solution would be to just allow the specification of subnet in the backend configuration next (or within?) to the vpc_ids