Azure App Service with Private endpoints does not support deployment slots

Question

Hi,

I am currently in the process of deploying infrastructure using ARM (and bicep), the requirements for this infrastructure will see the deployment of a virtual network into which I need to host both Azure SQL Database and Azure App Service, both using private endpoints. I have a set of working templates that can deploy the resources and configuration I need, including the necessary private DNS zones and configuration for privatelink.azurewebsites.net and privatelink.database.windows.net.

The problem I have subsequently encountered in that the private DNS zone configuration generated when creating the private endpoint only creates DNS records that support the primary deployment slot on the web app:

The image shows 2 web apps created along with the associated kudu site host pointing to the appropriate private IP addresses. This works as expected from within the virtual network, a ping to ***-aweb01.azurewebsites.net returns the expected IP address of 10.200.10.5, however if any deployment slots are present they are not accessible, with a ping for ***-aweb01-slotname.azurewebsites.net not resolving within the private DNS zone and instead returning the public IP address, leading to a 403 if any attempt is made to visit the URL within the virtual network.

The only workaround I have found requires that a set of manually added DNS records needs to be created for each slot, this is a more difficult task to perform within ARM templates but also means that private endpoints for web app are not fully compatible with all app service features.

I don't feel like this workaround should be required and that the DNS configuration options within the private endpoint should be respinsible for maintaining this records?

----------

Answer 1

@Shawn Sullivan It turns out this is indeed supported at this time but not particularly well-documented. I reverse engineered some of the requirements from the REST traffic on the portal. In particular:

1. The private connection resource ID is the parent app service (or production slot, if you prefer) resource ID rather than the deployment slot resource ID.
2. The group ID parameter is formatted such as sites-<deploymentSlotName>. If you have a deployment slot named test, the group ID value should be sites-test to tie the private endpoint to that slot.

Here's a sample in PowerShell below to demonstrate.

   $subscriptionId = "00000000-0000-0000-0000-000000000000"  
   $vnetRgName = "myrg"  
   $vnetName = "myrg-vnet"  
   $subnetName = "myrg-vnet-dmzsn"  
   $fxRgName = "myrg"  
   $fxName = "myrg-fx"  
   $slotName = "stage"  
   $endpointRgName = "myrg"  
   $endpointName = "myrg-fx-stage-pe"  
   $connectionName = "myrg-fx-stage-pe-conn"  
     
   az network private-endpoint create --name $endpointName --resource-group $endpointRgName --subnet /subscriptions/$subscriptionId/resourceGroups/$vnetRgName/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName --private-connection-resource-id /subscriptions/$subscriptionId/resourceGroups/$fxRgName/providers/Microsoft.Web/sites/$fxName --group-id sites-$slotName --connection-name $connectionName  

This command would look something like:
az network private-endpoint create --name myrg-fx-stage-pe --resource-group myrg --subnet /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myrg/providers/Microsoft.Network/virtualNetworks/myrg-vnet/subnets/myrg-vnet-dmzsn --private-connection-resource-id /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myrg/providers/Microsoft.Web/sites/myrg-fx --group-id sites-stage --connection-name myrg-fx-stage-pe-conn

Answer 2

Hi @Phil Oyston ,

Private endpoints for App Service deployment slots is not supported. See https://learn.microsoft.com/en-us/azure/app-service/networking/private-endpoint#limitations. However, I am aware that this something the team is working to implement. Unfortunately, I can't give you a timeframe of when to expect it to roll out. I'll update the thread once I hear something more concrete or feel free to @ me in a comment down below.

Regards,
Ryan