VNet Integration Tips
Azure App Service regional virtual network integration is a great feature and has been in a preview for a long time providing App Service capability reach endpoints in Azure VNets and in on-premises datacenters.
With recent release additional features make it has become even more useful.
One of the most important new features for us was was capability to access endpoints with non-RFC1918 IP addresses (which were previously unreachable).
Note 1: by default, your app will only route RFC1918 traffic into your VNet. If you want to route all of your outbound traffic into your VNet, apply the application setting WEBSITE_VNET_ROUTE_ALL to your app.
Note 2: Unfortunately this feature seems to be supported only in Windows as per Microsoft documentation (Regional VNet Integration) The Linux form of the feature still only supports making calls to RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
In combination with the ability to configure your App Service to leverage corporate DNS servers (and therefore access internal corporate DNS names not published to Internet) this significantly improves App Service integration with existing data-center services.
You can configure the DNS server that your app will use with WEBSITE_DNS_SERVER and WEBSITE_DNS_ALT_SERVER application settings.
Who is using my subnets?
If you have limited number of app services and app service plans then it is quite easy to find the ones that leverage specific subnet. But if you manage medium or large enterprise with dozens and possibly hundreds App Services this task becomes more difficult. Iterating over all App Service plans seems counter-productive and there seem no capability to see this information in Azure portal subnet blade at the moment. This can become an annoyance when it prevents you from deleting subnet or to removing subnet delegation.
Luckily there this information is easily available using PowerShell.
Relevant fragment of output is shown below