Azure App Service supports connecting to Application (App) Server and Database (DB) Server hosted in Azure VM or on-premise server using vNET integration that is part of App Service Plan(ASP). You get such scenarios often if you are migrating your applications landscape to Azure from on-premise. You will have different scenarios like shared DBs or may be DB team is not ready yet to DBs to PaaS, or there is no PaaS DB service available for the like of DB2, Oracle database services. App Service vNET integration is a useful feature if you do not chose to go with App Service Environment (ASE).
When you configure the vNET integration, your WebApp will get private IP from the vNET. App Service will be able to communicate with a VM in the vNET or another vNET peered in the same region, or a server on-premises over express route or s2s VPN.
I will be focusing on regional vNET Integration and sharing my recent learnings working with WebApps in this blog. I am listing the required pre-requisites for vNET integration below.
- You need to choose Standard, Premium or Isolated App Service plan. Other plans do not support vNET integration.
- You need to have dedicated subnet with delegation for doing the vNET integration.
- Minimum subnet size should /27 for standard and /26 for premium plans.
Let me list down some of the points that you must remember when you need to deal with App Service vNET integration.
- All the WebApp deployed in an ASP can only be integrate it with one vNET.
- Integrating ASP with multiple vNET is not supported.
- The vNET integration subnet can be utilized by one App Service plan only.
- You can apply required UDRs to route traffic to NVAs.
- Plan number of instances to be deployed, each instance would consume one Ipaddress each.
- Only WebApp can initiate communication to a VM but a VM cannot initiate a communication using vNET integration.
- If you configure NSG, only outbound rules will be applied on the WebApp.
- Inbound rules doesn’t work as App Service does not accept inbound.
- If you planning to use ARM to deploy App Service, you need to configure vNET integration also with ARM. If not, it would not work.
- If you face issues with vNET integration, delete the subnet, re-create subnet and assign delegation for WebApp. It is not documented but we learned it in a hard way.
- You can use TCPPING for testing your port to the destination VM.
- By default, your app routes only RFC1918 traffic into your VNet. If you want to route all of your outbound traffic into your VNet, apply the app setting WEBSITE_VNET_ROUTE_ALL to your app.
- You can’t reach resources across global peering connections.
- One dedicated subnet is required per ASP you deploy.
- Both WebApp and the VNet must be in the same Azure region.
- You can only integrate with VNet in the same subscription as the WebApp.
- You can’t delete a VNet with an integrated app. Remove the integration before you delete the VNet.
- You can’t change the subscription of an WebApp or a plan while there’s an app that’s using regional VNet Integration.
- Your app cannot resolve addresses in Azure DNS Private Zones without configuration changes
I don’t know why Microsoft did not update their documentation properly when they updated the policy, not to allow a subnet size less than /27 for Standard and /26 for premium. It was allowed a month ago but they applied a new policy to deny using that without documenting that. It was a hard learning for me when I worked with a client last month. However, existing vNET integration looks to be working at this moment. However, if you disconnect, you will not able to re-use that subnet.
You can read details of vNET integration from this URL.
I hope to cover some more App Service topics in my upcoming blogs.
I believe this will be helpful and please do not forget to comments if you have a query or suggestion. Thanks for reading my blog.
anoop.blog 