Azure App Services — Network Connections
Nowadays, Organisations are following the digital transformation path and making strategies to modernise their applications to run in PAAS or containers. Refactoring an application in this fashion achieves many benefits of the cloud.
If we talk specifically about cloud environments, Azure App Service is among the famous choices. Deploying a new application in Azure App service is no big deal if we have an answer to some important questions.
- How will applications running in App services connect to resources in the virtual network(Same region)?
- How can the application stay internal and secure to my environment?
- How will the application connect to services running in different regions?
- How will the application connect to databases running on-premise(Without VPN or ExpressRoute)?
Sometimes it becomes very complex to gather information from different sources. So, let’s target these questions which will help you in planning the architecture and modernising your applications or IT environment.
How will applications running in App services connect to resources in the virtual network(Same region)?
The most common use case scenario for this approach is that your database is running in a virtual machine and you want your web app to integrate with the database.
App services have a feature called VNet Integration which gives the app access to resources in your VNet. It is used only to make outbound calls from your app into VNet as it doesn’t grant inbound private access to your app from the VNet.
Regional VNet integration is limited to a single region where app services and VNet are in the same region. Regional VNet Integration works by mounting virtual interfaces with addresses in the delegated subnet. Now the address is from your VNet and your application can access the same way a VM in your VNet would. Though the networking implementation is different than running a VM. Using regional VNet integration peered VNets can \be reached but they should in the same region.
Apps can also access on-premises resources by integrating with VNets that have site-to-site connections.
Once you setup WEBSITE_VNET_ROUTE_ALL to 1, all outbound traffic will be sent to your VNet, but this is limited to one regional VNet Integration per App Service plan. NSGs and UDRs will control the routing of the outbound traffic to your VNet. Hence, NSG and Route table will be assigned to the integration subnet which should be an unused subnet that’s a /27 with 32 addresses or larger in an Azure Resource Manager VNet.
One last point, VNet Integration feature requires a Standard, Premium, PremiumV2, or Elastic Premium pricing plan.
How will the applications connect to resources running in different regions?
Gateway-required VNet Integration supports connecting to a VNet in another region or to a classic virtual network.
Gateway-required VNet Integration is built on top of point-to-site VPN technology which restricts network access to the virtual machine that hosts the app. Once the app is configured to use gateway-required VNet Integration, certificates are created and assigned on the gateway and the application side which led the workers that are used to host your apps to directly connect to the virtual network gateway in the selected VNet.
If the VNet has site to site VPN setup then VPN gateway routes have to be manually updated with your point-to-site address blocks.
The gateway-required VNet Integration feature doesn’t integrate an app with a VNet that has an ExpressRoute gateway. Even if the ExpressRoute gateway is configured in coexistence mode, the VNet Integration doesn’t work. If you need to access resources through an ExpressRoute connection, use the regional VNet Integration feature.
If you want to use gateway-required VNet Integration with peering then enable Allow virtual network access and select Allow forwarded traffic and Allow gateway transit while creating peering.
How can the application stay internal and secure to my environment?
Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at a high scale.
App Service environments (ASEs) are used in scenarios where high scaling, high memory utilization and isolation and secure network access are required.
ASE is dedicated exclusively to a single subscription and can host 100 App Service Plan instances. It is composed of front ends and workers where front ends are responsible for HTTP/HTTPS termination and automatic load balancing of app requests within an ASE. ASE always exists in a virtual network, and more precisely, within a subnet of a virtual network. Security features of virtual networks to control inbound and outbound network communications for your apps are used. An ASE can be either internet-facing with a public IP address or internal-facing with only an Azure internal load balancer (ILB) address.
Enabling Service Endpoints on a resource creates routes with higher priority than all other routes. If you use Service Endpoints on any Azure service, with a forced tunneled ASE, the traffic to those services will not be forced tunneled.
If you deploy the ASE in a virtual network that has a VPN connection to the on-premises network, the apps in the ASE can access the on-premises resources. This capability is true regardless of whether the connection is a site-to-site VPN or Azure ExpressRoute.
Point to note — ASE comes with its own pricing tier and is costlier than normal App Service plans.
How will the application connect to databases running on-premise(Without VPN or ExpressRoute)?
In many cases, VPN or ExpressRoute connectivity may be a multi-hop setup for a remote site or not a possibility in establishing connectivity to the requested service. In those scenarios, your friend is Hybrid connections.
Using Hybrid connection, apps can access on-premises systems and services securely and it doesn’t require an internet-accessible endpoint too. It can be used to provide access to multiple networks from a single app.
Hybrid Connections requires a relay agent to be deployed where it can reach both the desired endpoint as well as to Azure. The relay agent, Hybrid Connection Manager (HCM), calls out to Azure Relay over port 443. It provides access from your app to a TCP endpoint and when used in App Service, each Hybrid Connection correlates to a single TCP host and port combination. From the web app site, the App Service infrastructure also connects to Azure Relay on your application’s behalf. Through the joined connections, your app is able to access the desired endpoint. The connection uses TLS 1.2 for security and shared access signature (SAS) keys for authentication and authorization.
I hope this information will help you with planning and designing Application networking.
For more details follow the below references.
