Zip deploy to a VNET integrated function app fails with 504 Gateway Timeout

Question

I am working on an ARM template deployment that involves deploying a Function App and a Storage Account. To ensure private communication between these services, I created a VNET with two subnets: one for the Storage Account private endpoints and one for the Function App VNET integration. Public access for both services has been disabled, private DNS zones for the relevant Storage Account services have been created, and the private DNS zones have been linked to my VNET.

My template initially creates the Storage Account and the Function App, then updates the Function App settings by adding the private connection environment variables: WEBSITE_CONTENTOVERVNET, and WEBSITE_VNET_ROUTE_ALL (along with the WEBSITE_RUN_FROM_PACKAGE set to 1). However, when I attempt to deploy the zip file to the Function App using ZipDeploy, it consistently fails with a 504 Gateway error: The gateway did not receive a response from 'Microsoft.Web' within the specified time period. The VNET does not have any configured NSGs. Does anyone have any idea to what might be causing this issue and how to resolve it?

Answer 1

Hi @Idan Haitner

How are you deploying to the function? VScode/DevOps? Are you deploying the Infrastructure via ARM/Bicep? These may dictate the answer below, however, I'll detail how I do this.

For a Function with private networking these are typically the required app settings:

You'll need to grab the Storage Account key from the storage account keys area.

FUNCTIONS_EXTENSION_VERSION: '~4'
FUNCTIONS_WORKER_RUNTIME: 'DOTNET-ISOLATED' // example stack runtime
AzureWebJobsStorage: 'StorageAccountKey'
WEBSITE_CONTENTSHARE: 'FunctionName' // Required ONLY if deploying via ARM/BICEP template 
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: 'StorageAccountKey'
WEBSITE_DNS_SERVER: '168.63.129.16'

The two app values, whilst probably still work, are redundant: WEBSITE_CONTENTOVERVNET, and WEBSITE_VNET_ROUTE_ALL

As these can be natively set within the Networking > Vnet Integration like so now:

In addition, the subnet must have the Microsoft.Web/sites delegated to the subnet where the virtual network integration is connected with. You mentioned the DNS zone is vNet linked, so assuming you see the relevant A records for the storage account listed then this is good.

If you are deploying via VSCode, then with the function public access set to 'disabled' you will have presumably disabled the backend SCM deployment endpoint. You can add your IP temporarily to deploy:

Function > Settings > Networking > Public Network Access: Disabled > Selected Networks > Add your IP into the rule:

More info: https://learn.microsoft.com/en-us/azure/azure-functions/configure-networking-how-to?tabs=portal#restrict-your-storage-account-to-a-virtual-network

https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#website_contentshare

https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#website_dns_server