VNET connection between Azure Function or App Service stops working – Service Association Links

By Benjamin Perkins · · , , , ,

I have this Azure Function that is integrated with an Azure Virtual Network, using Regional integration as shown in Figure 1.  Where Regional VNET Integration is ARM based and the resources are located in the same Azure region.  The other type of VNET integration is uses the classic integration method or if you need to connect to resources in another Azure region is commonly referred to as Gateway-required VNET integration.

image

Figure 1, Azure Function with VNET integration

Notice that the integration is configured to the VNET named CSHARPGUITAR-VNET and Subnet named GUITAR.  Behind the scenes there is a link created between the subnet and the App Service Plan which the function or app service is running on called ServiceAssociationLinks / serviceAssociationLinks.  You can find the value for this link using Azure Resource Explorer here or you can use Azure PowerShell.  As seen in Figure 2, you can navigate to the VNET which the integration have been configured into and search for serviceAssociationLinks which will provide the details of the configuration used to validate the connection.

image

Figure 2, Azure Function, Azure App Service with VNET integration, stops working, serviceAssociationLinks

Have a look at it now and take a snapshot, if it ever stops working then take another snapshot and compare the two.  The output you would see when the VNET integration is working is the same when viewed in the Azure Resource Explorer or via these PowerShell cmdlets.

$virtualNetwork = Get-AzVirtualNetwork -ResourceGroupName CSHARPGUITAR-VNET -Name CSHARPGUITAR-VNET
Get-AzVirtualNetworkSubnetConfig -Name GUITAR -VirtualNetwork $virtualNetwork

You need to replace the values to your own names.  The ServiceAssociationLinks bit looks like what’s illustrated in Figure 3.

image

Figure 3, Azure Function, Azure App Service with VNET integration, stops working, serviceAssociationLinks

Notice that the value for LinkResourceType is is the Resource Provider named Microsoft.Web/serverfarms, which you will also see in Figure 1 as part of the GUITAR subnet configuration.  The value for Link calls out the App Service Plan which is named CSHARPGUITAR-ASP and is where the Azure Function is running.

How to resolve the issue

If the connectivity stops working as expected between the regionally integrated resources, you should consider disconnecting the VNET integrated resource and rebuilding them.  This might at first seem a bit extreme, but the connection isn’t working anyway right?  Also, compare what you see in Azure Resource Provider or PowerShell to see if there are any differences, perhaps it got wiped out somehow….  I do not have any insights into this specifically and am just speculating, but it is common practice to cache information and then update it during a given timeframe.  Caching is a necessary evil, some might say.  So, you might see that the connection looks fine in the portal but not via PowerShell because of the way the Portal gets the configuration and the actual execution/implementation of the data transmissions.  Again, another speculation, but there is a lot of security going on behind the scenes and this configuration is likely checked and validated numerous times, unlikely the cached version, which is perhaps a reason for it appearing to be configured correctly, but not actually working.

NOTE: Also make sure you disconnect VNET integrated Apps and Functions before you delete them.