As we know, we now have service endpointsavailable 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 Restrictionsblade 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 anApp Service Environment(ASE) could do earlier. We’ll discuss about a few such use cases in this blog post.
You can read about Access Restrictionshere. More about the new VNet Integrationhere.
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.
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 VNetonly.
Thisalmostreplicates the isolated behavior of an ILB ASE. However, this isnot exactly the sameas having an App in an ILB ASE becausethe 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.
You can allow internet access to yourFront End App Service, and lock down access to a backend API App Service usingAccess 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 aConnectedresponse 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.