Azure App Service and on-premises resources
Updated: Jan 10, 2020
There are several ways to integrate Azure App Service to allow access on-premises (and other vNet resources).
Each of them has specific advantages and constraints. There are many aspects to consider when choosing what integration is the most appropriate. Microsoft provides excellent documentation but quick at-glance comparison seemed missing so created diagram below. Hope this will be helpful for other folks to make a decision when to use each of them.
Some of considerations are listed below - will add more as we learn more on our cloud journey.
Connectivity and flow constraints
For example if you need ability to invoke your App Service from on-premises:
Without traversing Internet ASE seems is the only way to go
But App Service Firewall can mitigate the risk for publicly accessible App Services
Both ASE and vNet integration require dedicated subnets.
At the time of this writing new vNet Integration is still in preview and the old one is being replaced. Therefore tough choice selecting between soon-to-be-obsolete and awkward initial implementation and new nice approach which is unfortunately still in preview.
If you use Hybrid Connections in addition to there being an App Service plan SKU requirement, there is an additional cost to using Hybrid Connections. There is a charge for each listener used by a Hybrid Connection. (See Hybrid Connections Pricing for details). Of course you also need to add cost of the VM on-premises hosting Connection Manager.
New vNet Integration
Seems very simple to setup and tests usually work right away but can get flaky (which is ok for preview).
Now lets deploy Azure SQL Test application (source code azure-app-service-database in GutHub) and test database connectivity.
In screen shots below we can see that the publicly deployed application (*.azurewebsites.net) successfully connects to database with 10.x IP address not publicly routable on the global internet (RFC-1918). This is possible due to vNet Integration we configured for App Service.
vNet Integration Restrictions
Dedicated subnet: One things which may not be necessarily clear from Microsoft documentation is that each App Service Plan that needs new vNet Integration requires a dedicated subnet. With 5 IP addresses reserved by Azure on each subnet and the number of App Service Plans in large organizations this can become a nuisance.
As for now as per Microsoft support "Request for different app service plans to share same subnet – The answer is No. One subnet can have only one App Service plan associated with it for Regional Vnet integration."
Hope this restriction can be lifted and Microsoft will allow sharing of the subnet between App Service Plans as it allows for example for Application Gateways.
no routing for non-1918 IP addresses:
As per Microsoft Integrate your app with an Azure Virtual Network we can use regional vNet integration for following scenarios:
to reach an RFC 1918 address (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) in the same region
to reach RFC 1918 endpoints across ExpressRoute
to reach resources across service endpoints
Regional vNet integration does not support reaching non-RFC 1918 addresses across ExpressRoute. To do that you need to use an ASE for now.
Other related post on App Service Integration