top of page


  • Writer's pictureRoman Guoussev-Donskoi

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).

This includes:

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

Infrastructure Constraints

Both ASE and vNet integration require dedicated subnets.

Maturity level

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 (* 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 (,, 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

483 views0 comments

Recent Posts

See All

Query SQL using OpenAI and Langchain

LLMs (such as OpenAI) are good for reasoning but they lack capability interface with outside world. This is where Langchain agents step in: agents provide LLMs with tools to perform actions (for examp

Home: Blog2


Home: GetSubscribers_Widget


Your details were sent successfully!

Home: Contact
bottom of page