As we know, we now have service endpoints available for Microsoft.Web which enables locking down inbound traffic to selected VNet/subnets. You can configure and allow only a specific Subnet of a VNet to reach an App Service via the Networking >> Access Restrictions blade in App Services.
This feature, in conjunction with the new Regional App Service VNet Integration feature can do a lot of amazing things that only Apps in an App Service Environment (ASE) could do earlier. We’ll discuss about a few such use cases in this blog post.
You can read about Access Restrictions here. More about the new VNet Integration here.
Use Cases:
- Application Gateway Lockdown
AppGW could be configured with a multi-tenant App Service earlier as well. However, you could not block the App from directly receiving requests over its default hostname, <appname>.azurewebsites.net. That, to some extent, defeated the purpose of having an Application Gateway WAF. Redirects on the App Service would often expose the backend hostname to the end user. Using Access Restrictions, you can allow access only from the Subnet hosting the AppGW and block all other requests.
To get this to work properly, ensure that “Pick Hostname from backend address” option is unchecked on the Application Gateway. If you've checked “Pick hostname from backend address”, and there are redirect rules set up on the App Service, the redirected request coming over to <appname>.azurewebsites.net will be blocked. Here’s a link to my blog that explains this problem in detail:
http://www.unriddle.net/config/azure-application-gateway-app-service-redirects-exposing-azurewebsite...
- Allow Access TO and FROM a VNet
With VNet Integration, you can allow your App Service to access VNet resources (Azure VM for example), and Service Endpoint enabled resources (Azure SQL DB, Azure Storage Account for example), through the Integrated VNet. With Access Restrictions, you can lock down access to the App Service from that VNet only.
This almost replicates the isolated behavior of an ILB ASE. However, this is not exactly the same as having an App in an ILB ASE because the traffic to your App Service will still be over its inbound public IP. The Web App is still on public DNS. But, IPs not on the access restrictions ‘allow’ list will see an HTTP 403.
- Multi-Tier Applications
You can allow internet access to your Front End App Service, and lock down access to a backend API App Service using Access Restrictions. (See diagram below). You’ll need to set up VNet Integration from your Front End App to a Subnet and enable Access Restrictions to Backend API App.
Some customers may want to test this connectivity first before going ahead with deploying their code. Remember that tcpping would NOT BE A GOOD TEST in this scenario. This is because, you’ll still get a Connected response from the backend API App when you tcpping even from Apps that are not integrated with the VNet. The best test, in this case, will be a simple CURL command. Here’s what I mean:
Front End App: amaze.azurewebsites.net (this app is integrated with a subnet)
Backend API App: amaze-dest.azurewebsites.net (this app has access restrictions enabled on the subnet)
Some other unrelated App: unrelated.azurewebsites.net (this is a standalone app that has not been integrated with the subnet and is in no way related to the solution)
- TCPPing result from the unrelated App to Backend API App Service
- CURL result from the unrelated App to Backend API Service
- CURL result from Front End App to Backend API App Service
These are just a few use cases among the many powerful things you can do with these features.
I hope this helps!