This chapter covers Azure App Service VNet Integration, a critical feature for securely connecting web apps to resources inside a virtual network without public internet exposure. For the AZ-104 exam, this topic appears in approximately 5-10% of questions under Objective 3.2 (Configure and manage compute resources), often as part of a larger scenario involving network security, hybrid connectivity, or multi-tier applications. You must understand the two types of integration (regional and gateway-required), when to use each, and how they differ from private endpoints and service endpoints.
Jump to a section
Imagine your company rents office space in a large shared building. By default, all employees enter through the main lobby (the public internet) and can be seen by everyone. But you need a private wing for your HR team that connects directly to your corporate headquarters across the street without going through the lobby. You build a private corridor that connects the wing's internal hallway directly to the headquarters' private entrance. The corridor is a dedicated path: only HR employees can use it, and traffic flows only from the wing to headquarters (outbound). If headquarters needs to send a package to HR, they must use the main lobby because the corridor is one-way. However, you can add a second corridor for inbound traffic by configuring a special gateway at the headquarters side. The key is that the wing still has its own main lobby access for general internet traffic, but the private corridor gives it secure, direct access to a specific resource without exposing that resource to the public. In Azure App Service, VNet Integration creates this private corridor between your App Service (the office wing) and a virtual network (the headquarters), allowing outbound calls to resources in that VNet without going over the internet.
What is App Service VNet Integration?
Azure App Service VNet Integration allows a web app, API app, or function app to access resources in an Azure virtual network (VNet) but does not allow inbound access to the app from the VNet. It is an outbound-only feature. The app continues to be reachable via its public endpoint (unless you also configure access restrictions or private endpoints). VNet Integration is used when your app needs to connect to databases, storage accounts, or other services that are locked down to a specific VNet.
Two Types of VNet Integration
Regional VNet Integration – The app connects directly to a VNet in the same region. This is the modern, recommended approach. It uses a delegated subnet in the VNet. The app's outbound traffic from the app service plan instances is routed through the delegated subnet. No gateways or VPNs are required.
Gateway-required VNet Integration – The app connects to a VNet in a different region or to a classic VNet. This requires a point-to-site VPN gateway in the target VNet. The app's outbound traffic is routed through the gateway. This is legacy and not recommended for new deployments.
How Regional VNet Integration Works (the mechanism)
When you enable regional VNet Integration, Azure creates a network interface (vNIC) for each instance of your App Service plan in the delegated subnet. These vNICs are used for outbound traffic only. The routing works as follows:
All outbound traffic from the app (except traffic to the app's own endpoint and certain Azure management endpoints) is sent via the delegated subnet.
The default route (0.0.0.0/0) in the subnet's route table is used for internet-bound traffic. If you want to force all outbound traffic through a firewall or NVA, you can add a route with next hop Virtual Appliance, but you must also add a route for the Azure management IPs (168.63.129.16) and the App Service internal addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to avoid breaking the app.
Traffic to private IPs in the VNet (e.g., a VM at 10.1.0.4) is routed directly via the subnet.
Traffic to peered VNets or on-premises via VPN/ExpressRoute is routed if the routes are present in the subnet's route table.
Subnet Requirements
The delegated subnet must be empty (no other resources) and must have a minimum size of /27 (32 addresses). Azure reserves 5 addresses per subnet, so /27 gives 27 usable addresses. For production, a /26 (64 addresses) or larger is recommended to support scale-out (each App Service plan instance uses one IP).
The subnet must be delegated to Microsoft.Web/serverFarms.
The subnet cannot be a gateway subnet or a subnet that already has other delegations.
DNS and Name Resolution
By default, the app uses Azure DNS. If the VNet has custom DNS servers, the app will not automatically use them unless you configure the app's VNet integration to use the VNet's DNS. In the Azure portal, under Networking > VNet Integration, you can set "Route All Traffic" to enable custom DNS. Alternatively, you can set the app setting WEBSITE_VNET_ROUTE_ALL to 1.
Key Differences from Private Endpoint and Service Endpoint
Service Endpoints: Secure Azure service resources (e.g., storage, SQL) to a VNet. They are not used for App Service itself. You can use service endpoints on the delegated subnet to restrict outbound traffic to specific Azure services.
Private Endpoints: Assign a private IP from your VNet to an Azure resource (e.g., storage, SQL) so it becomes reachable from the VNet. For App Service, you can use private endpoints for inbound traffic (users access the app via a private IP). VNet Integration is for outbound traffic from the app. They can be used together.
Gateway-Required VNet Integration Details
This is used when the VNet is in a different region or is a classic VNet. It requires a point-to-site VPN gateway in the target VNet. The gateway must be configured with a root certificate that matches the one Azure uses. The route advertisement from the gateway determines which routes the app sees. This integration has a limit of 10 VNets per App Service plan. It is less performant and more complex than regional integration. The exam expects you to know that gateway-required is legacy and that regional is preferred.
Configuration Steps (Azure CLI example)
# Create a resource group
az group create --name myResourceGroup --location eastus
# Create an App Service plan (must be Standard or higher for VNet Integration)
az appservice plan create --name myPlan --resource-group myResourceGroup --sku S1
# Create a web app
az webapp create --name myWebApp --resource-group myResourceGroup --plan myPlan
# Create a VNet and subnet
az network vnet create --name myVNet --resource-group myResourceGroup --address-prefix 10.0.0.0/16 --subnet-name mySubnet --subnet-prefix 10.0.1.0/27
# Delegate the subnet to Microsoft.Web/serverFarms
az network vnet subnet update --name mySubnet --resource-group myResourceGroup --vnet-name myVNet --delegations Microsoft.Web/serverFarms
# Enable regional VNet Integration
az webapp vnet-integration add --resource-group myResourceGroup --name myWebApp --vnet myVNet --subnet mySubnetVerification
# List VNet integrations
az webapp vnet-integration list --resource-group myResourceGroup --name myWebApp
# Check the app's outbound IPs (they will now include addresses from the delegated subnet)
az webapp show --resource-group myResourceGroup --name myWebApp --query outboundIpAddressesPerformance and Scale
Each App Service plan instance uses one IP from the delegated subnet. If you scale to 10 instances, you need 10 IPs. The subnet must have enough free IPs. Also, the total number of outbound connections from the app is limited by the number of SNAT ports. Regional VNet Integration does not use SNAT for traffic to the VNet; it uses direct routing. For internet-bound traffic, SNAT is still used.
Limitations
VNet Integration does not allow inbound traffic from the VNet to the app. For that, use private endpoints or service endpoints.
You cannot delete the delegated subnet if there are integrated apps. You must first remove the integration.
The app and the VNet must be in the same Azure region (for regional integration). For cross-region, use gateway-required.
The app must be running on a Standard, Premium, PremiumV2, PremiumV3, or Isolated App Service plan.
The VNet must not be a classic VNet (unless using gateway-required).
Interaction with Network Security Groups (NSGs)
You can apply NSGs to the delegated subnet. However, the NSG applies to outbound traffic from the app. By default, all outbound traffic is allowed. You can restrict outbound traffic to specific destinations. For example, you can block internet access but allow traffic to a specific database subnet. Remember that Azure management traffic (to 168.63.129.16) must be allowed.
Interaction with Route Tables (UDRs)
You can apply a route table to the delegated subnet. This is how you force tunnel all outbound traffic through a firewall. Add a 0.0.0.0/0 route with next hop Virtual Appliance. But you must also add routes for the management IPs and the App Service internal addresses to ensure the app remains healthy.
Common Troubleshooting
App cannot connect to resources in the VNet: Check that the subnet is delegated correctly, that the app has been restarted after integration, and that NSG/UDR are not blocking traffic.
App is unreachable from the internet: VNet Integration does not change inbound access. Check Access Restrictions or Private Endpoint configuration.
Scale-out failures: The delegated subnet may have run out of IPs. Increase the subnet size.
Performance issues: Gateway-required integration adds latency. Use regional integration instead.
How the Exam Tests This
The AZ-104 exam will present scenarios where you must choose between VNet Integration, private endpoints, and service endpoints. Common questions: - "You need to allow a web app to access a SQL database that is secured to a VNet. What should you configure?" Answer: VNet Integration (regional) on the web app side, and a private endpoint or service endpoint on the database side. - "You need to allow users to access a web app privately from a VNet. What should you configure?" Answer: Private endpoint for the web app. - "You need to restrict outbound traffic from a web app to only a specific VNet. What should you configure?" Answer: VNet Integration with NSG on the delegated subnet.
Be careful: The exam may ask about "hybrid connections" or "App Service Environment" as alternatives. Hybrid Connections are for on-premises resources, not VNet. App Service Environment (ASE) is a fully isolated environment but is more expensive and not always needed.
Exam-Specific Numbers
Minimum subnet size: /27 (32 addresses)
Delegation: Microsoft.Web/serverFarms
Supported plans: Standard, Premium, PremiumV2, PremiumV3, Isolated
Maximum number of VNets per App Service plan (gateway-required): 10
Regional integration requires same region.
Gateway-required requires a point-to-site VPN gateway.
The app setting WEBSITE_VNET_ROUTE_ALL = 1 forces all traffic through the VNet (including internet-bound).
Azure management IP: 168.63.129.16
Create App Service Plan
Before you can enable VNet Integration, the App Service plan must be at least the Standard tier (S1 or higher). The plan determines the compute resources and features available. If the plan is Free or Shared, the VNet Integration option will be grayed out. The plan also dictates the number of instances you can scale to, which affects the IP address consumption from the delegated subnet. For production, consider PremiumV2 or PremiumV3 for better performance and more features.
Create Virtual Network and Subnet
The VNet must exist in the same region as the App Service plan for regional integration. The subnet must be dedicated to the App Service plan and cannot contain any other resources. The minimum size is /27 (32 addresses). Azure reserves five addresses in each subnet (e.g., the first four and the last one). For a /27, you have 27 usable addresses. If you plan to scale to many instances, use a larger prefix like /26 (64 addresses). The subnet must be delegated to Microsoft.Web/serverFarms, which tells Azure that this subnet is reserved for App Service VNet Integration.
Delegate Subnet to App Service
Delegation is a critical step that allows Azure to create network interfaces in the subnet on behalf of the App Service. Without delegation, the integration will fail. You can delegate using the Azure portal, CLI, or PowerShell. When you delegate, the subnet becomes dedicated to that service. You cannot deploy other resources in it. The delegation is done at the subnet level and is irreversible until you remove all integrations. The CLI command is: az network vnet subnet update --delegations Microsoft.Web/serverFarms.
Enable Regional VNet Integration
In the Azure portal, navigate to your web app, select Networking, then VNet Integration. Click 'Add VNet' and choose the VNet and delegated subnet. The app will be restarted automatically. Behind the scenes, Azure creates a vNIC for each existing instance and assigns an IP from the delegated subnet. For new instances created during scale-out, IPs are assigned dynamically. The integration is complete when the status shows 'Connected'. You can verify using CLI: az webapp vnet-integration list.
Configure DNS and Routing if Needed
By default, the app uses Azure DNS. If your VNet uses custom DNS servers, the app will not automatically use them. To enable custom DNS, set the app setting WEBSITE_VNET_ROUTE_ALL to 1. This forces all outbound traffic (including DNS queries) to go through the VNet. Alternatively, you can configure the VNet integration settings in the portal to 'Route All Traffic'. Additionally, if you want to force all internet-bound traffic through a firewall, add a route table to the delegated subnet with a 0.0.0.0/0 route to the firewall. Remember to add a route for 168.63.129.16/32 with next hop Internet to allow Azure management traffic.
Scenario 1: Multi-tier Application with Database in VNet
A company has a web app (App Service) that needs to read/write to an Azure SQL Database that is secured with a private endpoint in a VNet. The web app is public-facing but must connect to the database without traversing the internet. The solution: Enable regional VNet Integration on the web app, delegating a /26 subnet in the same VNet where the SQL private endpoint resides. The web app's outbound traffic to the SQL database's private IP is routed directly through the VNet. The database remains inaccessible from the internet. In production, they scale to 20 instances, requiring 20 IPs from the subnet. They also apply an NSG on the delegated subnet to allow outbound traffic only to the SQL subnet (port 1433) and block all other outbound traffic. They set WEBSITE_VNET_ROUTE_ALL to 1 to ensure DNS queries for the SQL server's private zone are resolved via the VNet's DNS. Common misconfiguration: forgetting to add the route for 168.63.129.16, causing the app to be unreachable for management operations.
Scenario 2: Force Tunneling All Traffic Through a Firewall
A financial services company requires all outbound traffic from their web app to be inspected by a network virtual appliance (NVA) for compliance. They use regional VNet Integration with a route table on the delegated subnet that has a 0.0.0.0/0 route to the NVA's IP. They also add a route for 168.63.129.16/32 with next hop Internet to keep Azure management traffic direct. They set WEBSITE_VNET_ROUTE_ALL to 1 so that even internet-bound traffic goes through the VNet to the NVA. The NVA inspects traffic and then forwards it to the internet. One pitfall: the NVA must be able to handle the scale of traffic from the App Service, which can be thousands of connections. They also need to ensure that the NVA's route table includes a default route to the internet. If the NVA fails, the app loses outbound connectivity.
Scenario 3: Hybrid Application Accessing On-Premises Resources
A company has a web app that needs to access an on-premises SQL Server via a site-to-site VPN or ExpressRoute. They create a VNet with a VPN gateway connected to on-premises. They enable regional VNet Integration on the web app, delegating a subnet in that VNet. The app can then reach the on-premises SQL Server using its private IP. The on-premises network must advertise the routes to the VNet. Performance is good, but latency is higher than cloud-native solutions. They use a /27 subnet because they have only 2 instances. They also configure the app's connection string to use the private IP of the on-premises server. Misconfiguration: if the on-premises network does not advertise the route back to the app's subnet, the SQL Server cannot send responses. They must ensure proper routing and firewall rules on-premises.
What the AZ-104 Tests
Objective 3.2 covers "Configure and manage compute resources," including App Service VNet Integration. The exam expects you to:
Differentiate between regional and gateway-required integration.
Know the subnet requirements (minimum /27, delegation to Microsoft.Web/serverFarms).
Understand that VNet Integration is outbound-only; for inbound, use Private Endpoint.
Know that the App Service plan must be Standard or higher.
Understand that you can use NSGs and route tables on the delegated subnet.
Know the app setting WEBSITE_VNET_ROUTE_ALL.
Common Wrong Answers
"Use Private Endpoint for outbound connectivity" – Private endpoints are for inbound connectivity to the app from the VNet, not outbound. Candidates confuse the two. Remember: Private Endpoint = inbound to the app; VNet Integration = outbound from the app.
"Use Service Endpoint on the App Service" – Service endpoints are applied to the source subnet, not the App Service. You can use service endpoints on the delegated subnet to secure outbound traffic to Azure services, but they do not enable outbound connectivity to the VNet.
"Gateway-required is always better" – Regional integration is newer, faster, and simpler. Gateway-required is legacy and only needed for cross-region or classic VNets. The exam may present a scenario where both are possible; choose regional if same region.
"VNet Integration allows inbound traffic from the VNet" – This is false. The feature is outbound-only. For inbound, you need Private Endpoint or Access Restrictions.
Specific Numbers and Terms
Subnet size: /27 minimum
Delegation: Microsoft.Web/serverFarms
Plan tiers: Standard, Premium, PremiumV2, PremiumV3, Isolated
App setting: WEBSITE_VNET_ROUTE_ALL = 1
Management IP: 168.63.129.16
Gateway-required limit: 10 VNets per plan
Regional integration: same region only
Edge Cases
If you enable VNet Integration on a slot (deployment slot), the slot gets its own integration. You can have different integrations for different slots.
You cannot use VNet Integration with App Service on Linux in some older regions; check documentation.
If you delete the delegated subnet, the integration breaks. You must first remove the integration.
VNet Integration does not work with App Service Environment (ASE) because ASE is already in a VNet.
Eliminating Wrong Answers
When you see a question about connecting an App Service to resources in a VNet, immediately ask: Is the connection inbound or outbound? If outbound, VNet Integration is the answer. If inbound, Private Endpoint. If the question mentions "restrict access" or "secure to a VNet," it's likely about service endpoints or private endpoints on the target resource. If the question mentions "on-premises," consider Hybrid Connections or point-to-site VPN.
VNet Integration provides outbound-only connectivity from App Service to a VNet. Inbound connectivity requires Private Endpoint.
Regional VNet Integration requires a delegated subnet of at least /27 in the same region as the App Service plan.
The App Service plan must be at least Standard tier (S1 or higher) to use VNet Integration.
The delegated subnet must be empty and delegated to Microsoft.Web/serverFarms.
Set WEBSITE_VNET_ROUTE_ALL=1 to force all outbound traffic through the VNet and use custom DNS.
Gateway-required VNet Integration is legacy, used for cross-region or classic VNets, and requires a point-to-site VPN gateway.
NSGs and route tables can be applied to the delegated subnet to control outbound traffic, but must allow Azure management IP 168.63.129.16.
Each App Service instance uses one IP from the delegated subnet; plan subnet size accordingly for scale-out.
These come up on the exam all the time. Here's how to tell them apart.
Regional VNet Integration
Same region only
No VPN gateway required
Faster and lower latency
Delegated subnet minimum /27
Recommended for new deployments
Gateway-Required VNet Integration
Cross-region or classic VNets
Requires point-to-site VPN gateway
Higher latency due to gateway
No subnet delegation needed
Legacy, not recommended for new deployments
Mistake
VNet Integration allows inbound traffic from the VNet to the app.
Correct
VNet Integration is strictly outbound-only. The app's public endpoint remains the only way to reach it from the VNet unless you also configure a Private Endpoint for inbound access.
Mistake
You can use any subnet size for VNet Integration.
Correct
The delegated subnet must be at least /27 (32 addresses). Smaller subnets will fail. Azure reserves 5 addresses per subnet, so /27 yields 27 usable IPs. For production, use /26 or larger to accommodate scale-out.
Mistake
Gateway-required VNet Integration is the only option for modern deployments.
Correct
Regional VNet Integration is the recommended approach for same-region VNets. Gateway-required is legacy and should only be used for cross-region connections or classic VNets. Regional is faster, simpler, and does not require a VPN gateway.
Mistake
VNet Integration works with any App Service plan tier.
Correct
VNet Integration requires a Standard, Premium, PremiumV2, PremiumV3, or Isolated plan. Free and Shared plans do not support it. The exam often tests this tier requirement.
Mistake
VNet Integration automatically uses the VNet's DNS servers.
Correct
By default, the app uses Azure DNS. To use custom DNS servers in the VNet, you must set the app setting WEBSITE_VNET_ROUTE_ALL to 1 or enable 'Route All Traffic' in the portal. This forces all outbound traffic (including DNS) through the VNet.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
VNet Integration is for outbound traffic from the app to resources in a VNet. Private Endpoint is for inbound traffic from the VNet to the app. They serve opposite directions. You can use both together: Private Endpoint for users to access the app privately, and VNet Integration for the app to access backend resources in the VNet.
Yes, if the VNet is connected to on-premises via VPN or ExpressRoute. Enable regional VNet Integration on the app to that VNet. The app can then reach on-premises resources using their private IPs, assuming proper routing is in place.
The minimum subnet size is /27 (32 addresses). Azure reserves 5 addresses, leaving 27 usable. For production, use /26 or larger to support scale-out. The subnet must be delegated to Microsoft.Web/serverFarms.
Check these common issues: (1) The delegated subnet may be too small and out of IPs. (2) NSG or route table on the subnet may be blocking traffic. (3) The app may need to be restarted after integration. (4) DNS resolution may be failing; set WEBSITE_VNET_ROUTE_ALL=1 if using custom DNS. (5) The target resource's firewall may not allow traffic from the app's outbound IPs (which are from the delegated subnet).
Yes, regional VNet Integration is supported for App Service on Linux in most regions. However, there were some regional limitations in early 2021; check the latest Azure documentation. Gateway-required integration is not supported on Linux.
Enable regional VNet Integration and apply a route table to the delegated subnet with a 0.0.0.0/0 route to the firewall's private IP. Set WEBSITE_VNET_ROUTE_ALL=1 to ensure internet-bound traffic also goes through the VNet. Add a route for 168.63.129.16/32 with next hop Internet to allow Azure management traffic.
VNet Integration connects an App Service to resources in an Azure VNet. Hybrid Connections connect an App Service to on-premises resources via a relay agent. Hybrid Connections do not require a VNet and are useful for on-premises connectivity without VPN.
You've just covered App Service VNet Integration — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?