App Service VNet Integration and Private Endpoints

App Service VNet Integration is a feature that enables your App Service app to access resources in an Azure virtual network (VNet) but does not grant private inbound access to the app. It is designed for outbound traffic from your app to resources like databases, storage accounts, or other services inside a VNet. There are two types: Regional VNet Integration (recommended for most scenarios) and Gateway-required VNet Integration (legacy, used for connecting to classic VNets or on-premises via VPN).

When you enable Regional VNet Integration, Azure creates a delegated subnet in your VNet (minimum size /27 with 32 addresses) and attaches it to your App Service plan. Each App Service plan instance (VM) gets a virtual network interface (vNIC) in that subnet. The subnet must be empty and delegated to Microsoft.Web/serverFarms. Azure then configures routing so that outbound traffic from your app to addresses in the VNet range is sent over this vNIC, using private IPs from the delegated subnet. Traffic to the internet still goes through the normal outbound path (unless you force-tunnel).

A Private Endpoint is a network interface that connects your App Service to a specific resource (like a storage account or your app itself) over a private IP address from your VNet. For App Service, you can create a Private Endpoint for your app to allow inbound traffic only from your VNet. This replaces the public endpoint with a private IP in your VNet, making your app inaccessible from the public internet.

When you create a Private Endpoint for your App Service, Azure provisions a network interface in your VNet subnet with a private IP address. DNS configuration is updated so that the app's hostname (e.g., myapp.azurewebsites.net) resolves to that private IP when queried from within the VNet. From outside the VNet, the hostname still resolves to the public IP (unless you disable public access). You can also configure the app to deny public traffic entirely. Traffic from the VNet to the app flows over the Microsoft backbone, never leaving the Azure network.

These two features are complementary but serve different directions:

You can use both together: your app can receive traffic via a Private Endpoint and also access resources in the VNet via Regional VNet Integration. However, note that when you use VNet Integration, outbound traffic to the VNet uses the delegated subnet's IPs, not the Private Endpoint's IP. Also, if your app is integrated with a VNet and you use Private Endpoint for the same app, the VNet Integration subnet must be the same VNet as the Private Endpoint's subnet.

To enable Regional VNet Integration via Azure CLI:

az webapp vnet-integration add -g MyResourceGroup -n MyApp --vnet MyVNet --subnet MySubnet

To verify:

az webapp vnet-integration list -g MyResourceGroup -n MyApp

To create a Private Endpoint for an App Service:

az network private-endpoint create -g MyResourceGroup -n MyPE --connection-name MyConnection \
  --private-connection-resource-id $(az webapp show -g MyResourceGroup -n MyApp --query id -o tsv) \
  --group-id sites --subnet MySubnet --vnet-name MyVNet

To verify:

az network private-endpoint show -g MyResourceGroup -n MyPE --query customDnsConfigs

Regional VNet Integration adds minimal latency (sub-millisecond) because traffic stays within Azure's backbone. Private Endpoint also adds negligible latency. Both features scale automatically with your App Service plan. For high-throughput scenarios, ensure the delegated subnet has enough IP addresses (each instance uses one IP from the subnet). For Private Endpoint, each endpoint uses one IP regardless of instance count.

A financial services company deploys a microservices application on Azure App Service. The front-end app needs to communicate with a back-end API app, which in turn accesses an Azure SQL Database and a Storage Account, all inside a VNet. They use Regional VNet Integration on both App Services to allow them to access the database and storage over private IPs. To secure inbound traffic, they deploy Private Endpoints for both App Services, so that only traffic from within the VNet can reach them. They also disable public access on both apps. This ensures that all traffic stays within the Azure backbone, meeting compliance requirements. The company uses Premium V3 plan for better performance. The delegated subnets are /27 each. They monitor the NSG flow logs to detect any unexpected outbound traffic.

A retail company has an App Service that needs to access an on-premises database via a site-to-site VPN. They use Regional VNet Integration to connect the app to a VNet that has a VPN gateway. The VNet Integration subnet is in the same VNet. They add a custom route to the subnet's route table to send traffic to the on-premises IP range through the VPN gateway. The app can now access the database securely. For inbound access, they use a Private Endpoint so that only users connected to the corporate network (via VPN or ExpressRoute) can reach the app. They also implement Access Restrictions as a second layer, allowing only the VNet's address space.

A SaaS provider uses App Service with Regional VNet Integration to access Azure Storage via service endpoints. They enable service endpoints on the delegated subnet for Microsoft.Storage. This ensures that traffic from the app to the storage account goes over the Azure backbone and not the internet. They also use a Private Endpoint for the App Service itself to allow private inbound access from their management VNet. They note that service endpoints and Private Endpoints can coexist on the same subnet, but the Private Endpoint is for a different resource. They experience no issues with scale, but they ensure the delegated subnet has enough IPs for peak instance count (e.g., 40 instances need at least /27).