Rediģēt

Kopīgot, izmantojot

Azure Functions networking options

  • Raksts

This article describes the networking features available across the hosting options for Azure Functions. All the following networking options give you some ability to access resources without using internet-routable addresses or to restrict internet access to a function app.

The hosting models have different levels of network isolation available. Choosing the correct one helps you meet your network isolation requirements.

Feature Flex Consumption plan Premium plan Dedicated plan/ASE Container Apps* Consumption plan
Inbound IP restrictions ✅Yes ✅Yes ✅Yes ✅Yes ✅Yes
Inbound Private Endpoints ✅Yes ✅Yes ✅Yes ❌No ❌No
Virtual network integration ✅Yes (Regional) ✅Yes (Regional) ✅Yes (Regional and Gateway) ✅Yes ❌No
Virtual network triggers (non-HTTP) ✅Yes ✅Yes ✅Yes ✅Yes ❌No
Outbound IP restrictions ✅Yes ✅Yes ✅Yes ✅Yes ❌No

*For more information, see Networking in Azure Container Apps environment.

Quickstart resources

Use the following resources to quickly get started with Azure Functions networking scenarios. These resources are referenced throughout the article.

Inbound networking features

The following features let you filter inbound requests to your function app.

Inbound access restrictions

You can use access restrictions to define a priority-ordered list of IP addresses that are allowed or denied access to your app. The list can include IPv4 and IPv6 addresses, or specific virtual network subnets using service endpoints. When there are one or more entries, an implicit "deny all" exists at the end of the list. IP restrictions work with all function-hosting options.

Access restrictions are available in the Flex Consumption plan, Elastic Premium, Consumption, and App Service.

Note

With network restrictions in place, you can deploy only from within your virtual network, or when you've put the IP address of the machine you're using to access the Azure portal on the Safe Recipients list. However, you can still manage the function using the portal.

To learn more, see Azure App Service static access restrictions.

Private endpoints

Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. Private Endpoint uses a private IP address from your virtual network, effectively bringing the service into your virtual network.

You can use Private Endpoint for your functions hosted in the Premium and App Service plans.

If you want to make calls to Private Endpoints, then you must make sure that your DNS lookups resolve to the private endpoint. You can enforce this behavior in one of the following ways:

  • Integrate with Azure DNS private zones. When your virtual network doesn't have a custom DNS server, this is done automatically.
  • Manage the private endpoint in the DNS server used by your app. To do this you must know the private endpoint address and then point the endpoint you are trying to reach to that address using an A record.
  • Configure your own DNS server to forward to Azure DNS private zones.

To learn more, see using Private Endpoints for Web Apps.

To call other services that have a private endpoint connection, such as storage or service bus, be sure to configure your app to make outbound calls to private endpoints. For more details on using private endpoints with the storage account for your function app, visit restrict your storage account to a virtual network.

Service endpoints

Using service endpoints, you can restrict many Azure services to selected virtual network subnets to provide a higher level of security. Regional virtual network integration enables your function app to reach Azure services that are secured with service endpoints. This configuration is supported on all plans that support virtual network integration. To access a service endpoint-secured service, you must do the following:

  1. Configure regional virtual network integration with your function app to connect to a specific subnet.
  2. Go to the destination service and configure service endpoints against the integration subnet.

To learn more, see Virtual network service endpoints.

Use Service Endpoints

To restrict access to a specific subnet, create a restriction rule with a Virtual Network type. You can then select the subscription, virtual network, and subnet that you want to allow or deny access to.

If service endpoints aren't already enabled with Microsoft.Web for the subnet that you selected, they're automatically enabled unless you select the Ignore missing Microsoft.Web service endpoints check box. The scenario where you might want to enable service endpoints on the app but not the subnet depends mainly on whether you have the permissions to enable them on the subnet.

If you need someone else to enable service endpoints on the subnet, select the Ignore missing Microsoft.Web service endpoints check box. Your app is configured for service endpoints in anticipation of having them enabled later on the subnet.

Screenshot of the "Add IP Restriction" pane with the Virtual Network type selected.

You can't use service endpoints to restrict access to apps that run in an App Service Environment. When your app is in an App Service Environment, you can control access to it by applying IP access rules.

To learn how to set up service endpoints, see Establish Azure Functions private site access.

Virtual network integration

Virtual network integration allows your function app to access resources inside a virtual network. Azure Functions supports two kinds of virtual network integration:

  • The dedicated compute pricing tiers, which include the Basic, Standard, Premium, Premium v2, and Premium v3.
  • The App Service Environment, which deploys directly into your virtual network with dedicated supporting infrastructure and is using the Isolated and Isolated v2 pricing tiers.

The virtual network integration feature is used in Azure App Service dedicated compute pricing tiers. If your app is in an App Service Environment, it's already in a virtual network and doesn't require use of the VNet integration feature to reach resources in the same virtual network. For more information on all the networking features, see App Service networking features.

Virtual network integration gives your app access to resources in your virtual network, but it doesn't grant inbound private access to your app from the virtual network. Private site access refers to making an app accessible only from a private network, such as from within an Azure virtual network. Virtual network integration is used only to make outbound calls from your app into your virtual network. The virtual network integration feature behaves differently when it's used with virtual networks in the same region and with virtual networks in other regions. The virtual network integration feature has two variations:

  • Regional virtual network integration: When you connect to virtual networks in the same region, you must have a dedicated subnet in the virtual network you're integrating with.
  • Gateway-required virtual network integration: When you connect directly to virtual networks in other regions or to a classic virtual network in the same region, you need an Azure Virtual Network gateway created in the target virtual network.

The virtual network integration feature:

  • Requires a supported Basic or Standard, Premium, Premium v2, Premium v3, or Elastic Premium App Service pricing tier.
  • Supports TCP and UDP.
  • Works with App Service apps and function apps.

There are some things that virtual network integration doesn't support, like:

  • Mounting a drive.
  • Windows Server Active Directory domain join.
  • NetBIOS.

Gateway-required virtual network integration provides access to resources only in the target virtual network or in networks connected to the target virtual network with peering or VPNs. Gateway-required virtual network integration doesn't enable access to resources available across Azure ExpressRoute connections or work with service endpoints.

No matter which version is used, virtual network integration gives your app access to resources in your virtual network, but it doesn't grant inbound private access to your app from the virtual network. Private site access refers to making your app accessible only from a private network, such as from within an Azure virtual network. Virtual network integration is only for making outbound calls from your app into your virtual network.

Virtual network integration in Azure Functions uses shared infrastructure with App Service web apps. To learn more about the two types of virtual network integration, see:

To learn how to set up virtual network integration, see Enable virtual network integration.

Enable virtual network integration

  1. In your function app in the Azure portal, select Networking, then under VNet Integration select Click here to configure.

  2. Select Add VNet.

    Select VNet Integration

  3. The drop-down list contains all of the Azure Resource Manager virtual networks in your subscription in the same region. Select the virtual network you want to integrate with.

    Select the VNet

    • The Functions Flex Consumption and Elastic Premium plans only supports regional virtual network integration. If the virtual network is in the same region, either create a new subnet or select an empty, pre-existing subnet.

    • To select a virtual network in another region, you must have a virtual network gateway provisioned with point to site enabled. Virtual network integration across regions is only supported for Dedicated plans, but global peerings work with regional virtual network integration.

During the integration, your app is restarted. When integration is finished, you see details on the virtual network you're integrated with. By default, Route All is enabled, and all traffic is routed into your virtual network.

If you wish for only your private traffic (RFC1918 traffic) to be routed, please follow the steps in the app service documentation.

Regional virtual network integration

Using regional virtual network integration enables your app to access:

  • Resources in the same virtual network as your app.
  • Resources in virtual networks peered to the virtual network your app is integrated with.
  • Service endpoint secured services.
  • Resources across Azure ExpressRoute connections.
  • Resources across peered connections, which include Azure ExpressRoute connections.
  • Private endpoints

When you use regional virtual network integration, you can use the following Azure networking features:

  • Network security groups (NSGs): You can block outbound traffic with an NSG that's placed on your integration subnet. The inbound rules don't apply because you can't use virtual network integration to provide inbound access to your app.
  • Route tables (UDRs): You can place a route table on the integration subnet to send outbound traffic where you want.

Note

When you route all of your outbound traffic into your virtual network, it's subject to the NSGs and UDRs that are applied to your integration subnet. When virtual network integrated, your function app's outbound traffic to public IP addresses is still sent from the addresses that are listed in your app properties, unless you provide routes that direct the traffic elsewhere.

Regional virtual network integration isn't able to use port 25.

For the Flex Consumption plan:

  1. Ensure that the Microsoft.App Azure resource provider is enabled for your subscription by following these instructions. The subnet delegation required by Flex Consumption apps is Microsoft.App/environments.
  2. The subnet delegation required by Flex Consumption apps is Microsoft.App/environments. This is a change from Elastic Premium and App Service which have a different delegation requirement.
  3. You can plan for 40 IP addresses to be used at the most for one function app, even if the app scales beyond 40. For example, if you have fifteen Flex Consumption function apps that will be VNet integrated into the same subnet, you can plan for 15x40 = 600 IP addresses used at the most. This limit is subject to change, and is not enforced.
  4. The subnet can't already be in use for other purposes (like private or service endpoints, or delegated to any other hosting plan or service). While you can share the same subnet with multiple Flex Consumption apps, the networking resources will be shared across these function apps and this can lead to one function app impacting the performance of others on the same subnet.

There are some limitations with using virtual network:

  • The feature is available from Flex Consumption, Elastic Premium, and App Service Premium V2 and Premium V3. It's also available in Standard but only from newer App Service deployments. If you are on an older deployment, you can only use the feature from a Premium V2 App Service plan. If you want to make sure you can use the feature in a Standard App Service plan, create your app in a Premium V3 App Service plan. Those plans are only supported on our newest deployments. You can scale down if you desire after that.
  • The integration subnet can be used by only one App Service plan.
  • The feature can't be used by Isolated plan apps that are in an App Service Environment.
  • The feature requires an unused subnet that's a /28 or larger in an Azure Resource Manager virtual network.
  • The app and the virtual network must be in the same region.
  • You can't delete a virtual network with an integrated app. Remove the integration before you delete the virtual network.
  • You can have up to two regional virtual network integrations per App Service plan. Multiple apps in the same App Service plan can use the same integration subnet.
  • You can't change the subscription of an app or a plan while there's an app that's using regional virtual network integration.

Subnets

Virtual network integration depends on a dedicated subnet. When you provision a subnet, the Azure subnet loses five IPs from the start. For the Elastic Premium and App Service plans, one address is used from the integration subnet for each plan instance. When you scale your app to four instances, then four addresses are used. For Flex Consumption this does not apply and instances share IP addresses.

When you scale up or down in size, the required address space is doubled for a short period of time. This affects the real, available supported instances for a given subnet size. The following table shows both the maximum available addresses per CIDR block and the effect this has on horizontal scale:

CIDR block size Max available addresses Max horizontal scale (instances)*
/28 11 5
/27 27 13
/26 59 29

*Assumes that you need to scale up or down in either size or SKU at some point.

Since subnet size can't be changed after assignment, use a subnet that's large enough to accommodate whatever scale your app might reach. To avoid any issues with subnet capacity for Functions Elastic Premium plans, you should use a /24 with 256 addresses for Windows and a /26 with 64 addresses for Linux. When creating subnets in Azure portal as part of integrating with the virtual network, a minimum size of /24 and /26 is required for Windows and Linux respectively.

When you want your apps in another plan to reach a virtual network that's already connected to by apps in another plan, select a different subnet than the one being used by the pre-existing virtual network integration.

The feature is fully supported for both Windows and Linux apps, including custom containers. All of the behaviors act the same between Windows apps and Linux apps.

Network security groups

You can use network security groups to block inbound and outbound traffic to resources in a virtual network. An app that uses regional virtual network integration can use a network security group to block outbound traffic to resources in your virtual network or the internet. To block traffic to public addresses, you must have virtual network integration with Route All enabled. The inbound rules in an NSG don't apply to your app because virtual network integration affects only outbound traffic from your app.

To control inbound traffic to your app, use the Access Restrictions feature. An NSG that's applied to your integration subnet is in effect regardless of any routes applied to your integration subnet. If your function app is virtual network integrated with Route All enabled, and you don't have any routes that affect public address traffic on your integration subnet, all of your outbound traffic is still subject to NSGs assigned to your integration subnet. When Route All isn't enabled, NSGs are only applied to RFC1918 traffic.

Routes

You can use route tables to route outbound traffic from your app to wherever you want. By default, route tables only affect your RFC1918 destination traffic. When Route All is enabled, all of your outbound calls are affected. When Route All is disabled, only private traffic (RFC1918) is affected by your route tables. Routes that are set on your integration subnet won't affect replies to inbound app requests. Common destinations can include firewall devices or gateways.

If you want to route all outbound traffic on-premises, you can use a route table to send all outbound traffic to your ExpressRoute gateway. If you do route traffic to a gateway, be sure to set routes in the external network to send any replies back.

Border Gateway Protocol (BGP) routes also affect your app traffic. If you have BGP routes from something like an ExpressRoute gateway, your app outbound traffic is affected. By default, BGP routes affect only your RFC1918 destination traffic. When your function app is virtual network integrated with Route All enabled, all outbound traffic can be affected by your BGP routes.

Azure DNS private zones

After your app integrates with your virtual network, it uses the same DNS server that your virtual network is configured with and will work with the Azure DNS private zones linked to the virtual network.

Restrict your storage account to a virtual network

Note

To quickly deploy a function app with private endpoints enabled on the storage account, please refer to the following template: Function app with Azure Storage private endpoints.

When you create a function app, you must create or link to a general-purpose Azure Storage account that supports Blob, Queue, and Table storage. You can replace this storage account with one that is secured with service endpoints or private endpoints.

This feature is supported for all Windows and Linux virtual network-supported SKUs in the Dedicated (App Service) plan and for the Elastic Premium plans, as well as the Flex Consumption plan. The Consumption plan isn't supported. To learn how to set up a function with a storage account restricted to a private network, see Restrict your storage account to a virtual network.

Use Key Vault references

You can use Azure Key Vault references to use secrets from Azure Key Vault in your Azure Functions application without requiring any code changes. Azure Key Vault is a service that provides centralized secrets management, with full control over access policies and audit history.

If virtual network integration is configured for the app, Key Vault references may be used to retrieve secrets from a network-restricted vault.

Virtual network triggers (non-HTTP)

Currently, you can use non-HTTP trigger functions from within a virtual network in one of two ways:

  • Run your function app in an Elastic Premium plan and enable virtual network trigger support.
  • Run your function app in a Flex Consumption, App Service plan or App Service Environment.

Elastic Premium plan with virtual network triggers

The Elastic Premium plan lets you create functions that are triggered by services inside a virtual network. These non-HTTP triggers are known as virtual network triggers.

By default, virtual network triggers don't cause your function app to scale beyond their pre-warmed instance count. However, certain extensions support virtual network triggers that cause your function app to scale dynamically. You can enable this dynamic scale monitoring in your function app for supported extensions in one of these ways:

  1. In the Azure portal, navigate to your function app.

  2. Under Settings select Configuration, then in the Function runtime settings tab set Runtime Scale Monitoring to On.

  3. Select Save to update the function app configuration and restart the app.

VNETToggle

Tip

Enabling the monitoring of virtual network triggers may have an impact on the performance of your application, though this impact is likely to be very small.

Support for dynamic scale monitoring of virtual network triggers isn't available in version 1.x of the Functions runtime.

The extensions in this table support dynamic scale monitoring of virtual network triggers. To get the best scaling performance, you should upgrade to versions that also support target-based scaling.

Extension (minimum version) Runtime scale monitoring only With target-based scaling
Microsoft.Azure.WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure.WebJobs.Extensions.DurableTask > 2.0.0 n/a
Microsoft.Azure.WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure.WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure.WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Queue storage only.

Important

When you enable virtual network trigger monitoring, only triggers for these extensions can cause your app to scale dynamically. You can still use triggers from extensions that aren't in this table, but they won't cause scaling beyond their pre-warmed instance count. For a complete list of all trigger and binding extensions, see Triggers and bindings.

App Service plan and App Service Environment with virtual network triggers

When your function app runs in either an App Service plan or an App Service Environment, you can use non-HTTP trigger functions. For your functions to get triggered correctly, you must be connected to a virtual network with access to the resource defined in the trigger connection.

For example, assume you want to configure Azure Cosmos DB to accept traffic only from a virtual network. In this case, you must deploy your function app in an App Service plan that provides virtual network integration with that virtual network. Integration enables a function to be triggered by that Azure Cosmos DB resource.

Hybrid Connections

Hybrid Connections is a feature of Azure Relay that you can use to access application resources in other networks. It provides access from your app to an application endpoint. You can't use it to access your application. Hybrid Connections is available to functions that run on Windows in all but the Consumption plan.

As used in Azure Functions, each hybrid connection correlates to a single TCP host and port combination. This means that the hybrid connection's endpoint can be on any operating system and any application as long as you're accessing a TCP listening port. The Hybrid Connections feature doesn't know or care what the application protocol is or what you're accessing. It just provides network access.

To learn more, see the App Service documentation for Hybrid Connections. These same configuration steps support Azure Functions.

Important

Hybrid Connections is only supported on Windows plans. Linux isn't supported.

Outbound IP restrictions

Outbound IP restrictions are available in a Flex Consumption plan, Elastic Premium plan, App Service plan, or App Service Environment. You can configure outbound restrictions for the virtual network where your App Service Environment is deployed.

When you integrate a function app in an Elastic Premium plan or an App Service plan with a virtual network, the app can still make outbound calls to the internet by default. By integrating your function app with a virtual network with Route All enabled, you force all outbound traffic to be sent into your virtual network, where network security group rules can be used to restrict traffic. For Flex Consumption all traffic is already routed through the virtual network and Route All is not needed.

To learn how to control the outbound IP using a virtual network, see Tutorial: Control Azure Functions outbound IP with an Azure virtual network NAT gateway.

Automation

The following APIs let you programmatically manage regional virtual network integrations:

Testing considerations

When testing functions in a function app with private endpoints, you must do your testing from within the same virtual network, such as on a virtual machine (VM) in that network. To use the Code + Test option in the portal from that VM, you need to add following CORS origins to your function app:

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

If you've restricted access to your function app with private endpoints or any other access restriction, you also must add the service tag AzureCloud to the allowed list. To update the allowed list:

  1. Navigate to your function app and select Settings > Networking and then select Inbound access configuration > Public network access.

  2. Make sure that Public network access is set to Enabled from select virtual networks and IP addresses.

  3. Add a rule under Site access and rules:

    1. Select Service Tag as the Source settings Type and AzureCloud as the Service Tag.

    2. Make sure the action is Allow, and set your desired name and priority.

Troubleshooting

The feature is easy to set up, but that doesn't mean your experience will be problem free. If you encounter problems accessing your desired endpoint, there are some utilities you can use to test connectivity from the app console. There are two consoles that you can use. One is the Kudu console, and the other is the console in the Azure portal. To reach the Kudu console from your app, go to Tools > Kudu. You can also reach the Kudo console at [sitename].scm.azurewebsites.net. After the website loads, go to the Debug console tab. To get to the Azure portal-hosted console from your app, go to Tools > Console.

Tools

In native Windows apps, the tools ping, nslookup, and tracert won't work through the console because of security constraints (they work in custom Windows containers). To fill the void, two separate tools are added. To test DNS functionality, we added a tool named nameresolver.exe. The syntax is:

nameresolver.exe hostname [optional: DNS Server]

You can use nameresolver to check the hostnames that your app depends on. This way you can test if you have anything misconfigured with your DNS or perhaps don't have access to your DNS server. You can see the DNS server that your app uses in the console by looking at the environmental variables WEBSITE_DNS_SERVER and WEBSITE_DNS_ALT_SERVER.

Note

The nameresolver.exe tool currently doesn't work in custom Windows containers.

You can use the next tool to test for TCP connectivity to a host and port combination. This tool is called tcpping and the syntax is:

tcpping.exe hostname [optional: port]

The tcpping utility tells you if you can reach a specific host and port. It can show success only if there's an application listening at the host and port combination, and there's network access from your app to the specified host and port.

Debug access to virtual network-hosted resources

A number of things can prevent your app from reaching a specific host and port. Most of the time it's one of these things:

  • A firewall is in the way. If you have a firewall in the way, you hit the TCP timeout. The TCP timeout is 21 seconds in this case. Use the tcpping tool to test connectivity. TCP timeouts can be caused by many things beyond firewalls, but start there.
  • DNS isn't accessible. The DNS timeout is 3 seconds per DNS server. If you have two DNS servers, the timeout is 6 seconds. Use nameresolver to see if DNS is working. You can't use nslookup, because that doesn't use the DNS your virtual network is configured with. If inaccessible, you could have a firewall or NSG blocking access to DNS or it could be down.

If those items don't answer your problems, look first for things like:

Regional virtual network integration

  • Is your destination a non-RFC1918 address and you don't have Route All enabled?
  • Is there an NSG blocking egress from your integration subnet?
  • If you're going across Azure ExpressRoute or a VPN, is your on-premises gateway configured to route traffic back up to Azure? If you can reach endpoints in your virtual network but not on-premises, check your routes.
  • Do you have enough permissions to set delegation on the integration subnet? During regional virtual network integration configuration, your integration subnet is delegated to Microsoft.Web/serverFarms. The VNet integration UI delegates the subnet to Microsoft.Web/serverFarms automatically. If your account doesn't have sufficient networking permissions to set delegation, you'll need someone who can set attributes on your integration subnet to delegate the subnet. To manually delegate the integration subnet, go to the Azure Virtual Network subnet UI and set the delegation for Microsoft.Web/serverFarms.

Gateway-required virtual network integration

  • Is the point-to-site address range in the RFC 1918 ranges (10.0.0.0-10.255.255.255 / 172.16.0.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
  • Does the gateway show as being up in the portal? If your gateway is down, then bring it back up.
  • Do certificates show as being in sync, or do you suspect that the network configuration was changed? If your certificates are out of sync or you suspect that a change was made to your virtual network configuration that wasn't synced with your ASPs, select Sync Network.
  • If you're going across a VPN, is the on-premises gateway configured to route traffic back up to Azure? If you can reach endpoints in your virtual network but not on-premises, check your routes.
  • Are you trying to use a coexistence gateway that supports both point to site and ExpressRoute? Coexistence gateways aren't supported with virtual network integration.

Debugging networking issues is a challenge because you can't see what's blocking access to a specific host:port combination. Some causes include:

  • You have a firewall up on your host that prevents access to the application port from your point-to-site IP range. Crossing subnets often requires public access.
  • Your target host is down.
  • Your application is down.
  • You had the wrong IP or hostname.
  • Your application is listening on a different port than what you expected. You can match your process ID with the listening port by using "netstat -aon" on the endpoint host.
  • Your network security groups are configured in such a manner that they prevent access to your application host and port from your point-to-site IP range.

You don't know what address your app actually uses. It could be any address in the integration subnet or point-to-site address range, so you need to allow access from the entire address range.

More debug steps include:

  • Connect to a VM in your virtual network and attempt to reach your resource host:port from there. To test for TCP access, use the PowerShell command Test-NetConnection. The syntax is:
Test-NetConnection hostname [optional: -Port]
  • Bring up an application on a VM and test access to that host and port from the console from your app by using tcpping.

On-premises resources

If your app can't reach a resource on-premises, check if you can reach the resource from your virtual network. Use the Test-NetConnection PowerShell command to check for TCP access. If your VM can't reach your on-premises resource, your VPN or ExpressRoute connection might not be configured properly.

If your virtual network-hosted VM can reach your on-premises system but your app can't, the cause is likely one of the following reasons:

  • Your routes aren't configured with your subnet or point-to-site address ranges in your on-premises gateway.
  • Your network security groups are blocking access for your point-to-site IP range.
  • Your on-premises firewalls are blocking traffic from your point-to-site IP range.
  • You're trying to reach a non-RFC 1918 address by using the regional virtual network integration feature.

Deleting the App Service plan or web app before disconnecting the VNet integration

If you deleted the web app or the App Service plan without disconnecting the VNet integration first, you will not be able to do any update/delete operations on the virtual network or subnet that was used for the integration with the deleted resource. A subnet delegation 'Microsoft.Web/serverFarms' will remain assigned to your subnet and will prevent the update/delete operations.

In order to do update/delete the subnet or virtual network again you need to re-create the VNet integration and then disconnect it:

  1. Re-create the App Service plan and web app (it is mandatory to use the exact same web app name as before).
  2. Navigate to the 'Networking' blade on the web app and configure the VNet integration.
  3. After the VNet integration is configured, select the 'Disconnect' button.
  4. Delete the App Service plan or web app.
  5. Update/Delete the subnet or virtual network.

If you still encounter issues with the VNet integration after following the steps above, please contact Microsoft Support.

Network troubleshooter

You can also use the Network troubleshooter to resolve connection issues. To open the network troubleshooter, go to the app in the Azure portal. Select Diagnostic and solve problem, and then search for Network troubleshooter.

Connection issues - It checks the status of the virtual network integration, including checking if the Private IP has been assigned to all instances of the plan and the DNS settings. If a custom DNS isn't configured, default Azure DNS is applied. The troubleshooter also checks for common Function app dependencies including connectivity for Azure Storage and other binding dependencies.

Screenshot that shows running troubleshooter for connection issues.

Configuration issues - This troubleshooter checks if your subnet is valid for virtual network Integration.

Screenshot that shows running troubleshooter for configuration issues.

Subnet/VNet deletion issue - This troubleshooter checks if your subnet has any locks and if it has any unused Service Association Links that might be blocking the deletion of the VNet/subnet.

Next steps

To learn more about networking and Azure Functions: