Azure App Service Networking

This week we saw the launch of the preview of Private Link for Azure Web Applications. This prompted a very valid question from @MotoWilliams on twitter.

Is there a post somewhere on the differences between private link and vnet integration for app services? Why you would use one or the other.

— 🎯 Eric Williams 🏹 (@MotoWilliams) March 17, 2020

There are now a lot of different networking services available to work with Azure Web Apps, each one providing a different service. It can be pretty confusing which service to use and when, so in this article, we’ll have a look at this.

No Networking

Before we dive into these networking options, it’s worth knowing that you don’t have to use any of them. If all you want is a web application that is accessible to anyone on the internet, doesn’t need to talk to any service in a virtual network and doesn’t need to use anything behind a service endpoint, then you don’t need any extra complication. You can spin up a web app, and off you go.

Private Link

Private Link is in preview for Azure Web applications and provides a way to inject the ingress of your web application into your virtual network. It is important to note that this is purely about ingress. Using Private Link does not result in your web application being able to access resources in your vNet; it just means that things in your vNet can access the web app privately.

When you use private Link, your web application is injected into your virtual network and gets a private IP address. Resources in your virtual network can talk to this over the private IP, meaning you can now restrict egress from your network to your web app only, rather than having to allow it to all web apps. Using Private Link also means that you can disable access to your web application to only your Virtual network, making the ingress private. Previously this was only possible with an App Service Environment.

Private Link supports access over global vNet peering, VPN and ExpressRoute.

Bear in mind that Private Link for Azure Web app does have some limitations:

• Private Link requires a premium SKU web application
• Currently NSG’s do not apply to Private Links
• When private Link is enabled the access restrictions on the web app are not evaluated

More details - https://docs.microsoft.com/en-gb/azure/app-service/networking/private-endpoint

Service Endpoints (Ingress)

App Service also supports service endpoints for ingress. There is often confusion between Service Endpoints and Private Link as they are quite similar. Service Endpoints provide a way to lock down access to your Web App to specific virtual networks or IP ranges, but the web application is still accessed using its public IP. Think of Service Endpoints like a firewall for your Web App on the internet, whereas Private Link is moving this application inside your network.

Generally, you would use either Service Endpoints or Private Link, not both. If you need to grant access to your web application to resources not in your Azure vNet (or joined to it via VPN or ExpressRoute), then you would use Service Endpoints. If you solely want to access your Web App from your vNet, then Private Link is the way to go (once GA)

More Details - https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview

Access Restrictions

Access Restrictions are a simple tool that allows you to restrict access to your web application to specific IP addresses. Using IP restrictions, you can either allow specific IP’s and deny all others, or deny specific IPs and allow all others.

More details - https://docs.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions

Regional Virtual Network Integration

vNet integration provides a way for you to join your App Service to your virtual network, but for egress. This integration is the opposite of Private Link. With vNet integration traffic from your App Service can flow into your virtual network so that it can access your resources inside that virtual network, such as databases, file stores etc.

vNet integration also means that the App Service can access resources that are not directly attached to your vNet but that are protected by service endpoints. Because traffic from your Web App flows through the vNet, it can access all the resources configured with a service endpoint allowing traffic from this vNet. Using this you can access PaaS services such as SQL, Key Vault, Service Bus etc. that are protected by Service Endpoints.

Regional vNet integration does not require any additional services to set up, it can all be configured through the web application.

More details - https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet

Gateway vNet Integration

An older version of vNet integration is using a Virtual Network Gateway. Generally, you would use the easier regional vNet integration unless:

1. You need to connect to a classic vNet
2. You need to connect to a vNet in a different region to the web application

More Detials - https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet

Hybrid Connection

Hybrid Connection is another tool that can be used to allow your Web Application to access private resources (in Azure or outside). Hybrid Connection uses an agent running on your network called Hybrid Connection Manager, along with Service Bus Relay to allow the Web App to send traffic to your private network.

Hybrid Connection is still a great option if you need to connect to resources that are not in Azure and not connected to Azure using ExpressRoute/VPN. If you need to access resources in Azure, I would recommend using Regional vNet integration.

Note that currently, Hybrid Connection is only available on Windows Web Applications.

More details - https://docs.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections

Service Summary

To summarise all of the services above, this is how I would recommend you use them:

• Restricting access to your web app to just your Virtual Network - Private Link (or Service Endpoints)
• Connecting to resource in your Virtual Network from your Web App - Regional vNet Integration
• Connecting to resources not attached to an Azure Virtual Network - Hybrid Connection

Bringing it Together

Each of these networking services provides a specific featured for your App Service. They can be used on their own, but you might also want to bring them together.

In the past, the only way to get a fully private App Service was to use the App Service Environment. This is created in your vNet but is very expensive. However, if we now combine Private Link and Regional vNet integration, we can replicate the same thing (In terms of isolation only). Our App Service is now accessible directly in our vNet, with a private IP, not accessible to the internet, with egress traffic flowing through our vNet, accessing any private resources required.

If we also have on-prem resources that are not connected to our vNet, we can implement Hybrid Connection alongside this.

A Note on ASE

App Service Environment (ASE) is the service that lets you deploy a single-tenant, private App Service into your vNet. The services we talk about here let you replicate the private networking setup of ASE for a significantly reduced cost if this is all you used an ASE for then you could probably replace it. However, ASE offers more than just private networking. If you need a single-tenant service, or the ability to scale your hardware, based on your needs, then ASE is still the service that you need.