WELCOME TO CLOUD MATTER

Search
  • Roman 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.


Cost

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.


References

Other related post on App Service Integration

298 views0 comments

Recent Posts

See All

Databricks is an amazing platform for data engineering, data science and machine learning. One of the critical requirements of secure data processing is data audit - the ability to identity what data

SAS access to storage account is very convenient and easy and while Microsoft recommends that you use Azure AD credentials when possible as security best practice still SAS sometimes hard to avoid. Le

 

Subscribe

 

CONTACT

Your details were sent successfully!

Computers