Deploy dedicated Azure services into virtual networks

When you deploy dedicated Azure services in a virtual network, you can communicate with the service resources privately, through private IP addresses.

Diagram of services deployed in a virtual network.

Deploying services within a virtual network provides the following capabilities:

  • Resources within the virtual network can communicate with each other privately, through private IP addresses. Example, directly transferring data between HDInsight and SQL Server running on a virtual machine, in the virtual network.

  • On-premises resources can access resources in a virtual network using private IP addresses over a Site-to-Site VPN (VPN Gateway) or ExpressRoute.

  • Virtual networks can be peered to enable resources in the virtual networks to communicate with each other, using private IP addresses.

  • Service instances are deployed into a subnet in a virtual network. Inbound and outbound network access for the subnet must be opened through network security groups, per guidance provided by the service.

  • Some services impose restrictions on the subnet they're deployed in to. This restriction limits the application of policies, routes or combining VMs and service resources within the same subnet. Check with each service on the specific restrictions as they may change over time. Examples of services are Azure NetApp Files, Dedicated HSM, Azure Container Instances, App Service.

  • Optionally, services might require a delegated subnet as an explicit identifier that a subnet can host a particular service. With delegation, services receive explicit permissions to create service-specific resources in the delegated subnet.

  • See an example of a REST API response on a virtual network with a delegated subnet. A comprehensive list of services that are using the delegated subnet model can be obtained via the Available Delegations API.

Services that can be deployed into a virtual network

Category Service Dedicated1 Subnet
Compute Virtual machines: Linux or Windows
Virtual machine scale sets
Cloud Service: Virtual network (classic) only
Azure Batch
Azure Baremetal Infrastructure
No
No
No
No2
No
Network Application Gateway - WAF
Azure Bastion
Azure Firewall
Azure Route Server
ExpressRoute Gateway
Network Virtual Appliances
VPN Gateway
Azure DNS Private Resolver
Yes
Yes
Yes
Yes
Yes
No
Yes
No
Data RedisCache
Azure SQL Managed Instance
Azure Database for MySQL - Flexible Server
Azure Database for PostgreSQL - Flexible Server
Yes
Yes
Yes
Yes
Analytics Azure HDInsight
Azure Databricks
No2
No2
Identity Microsoft Entra Domain Services No
Containers Azure Kubernetes Service (AKS)
Azure Container Instance (ACI)
Azure Container Service Engine with Azure Virtual Network CNI plug-in
Azure Functions
No2
Yes
No
Yes
Web API Management
Web Apps
App Service Environment
Azure Logic Apps
Azure Container Apps environments
Yes
Yes
Yes
Yes
Yes
Hosted Azure Dedicated HSM
Azure NetApp Files
Yes
Yes
Azure Spring Apps Deploy in Azure virtual network (VNet injection)
Yes
Virtual desktop infrastructure Azure Lab Services
Yes
DevOps Azure Load Testing
Yes

1 'Dedicated' implies that only service specific resources can be deployed in this subnet and can't be combined with customer VM/VMSSs
2 It's recommended as a best practice to have these services in a dedicated subnet, but not a mandatory requirement imposed by the service.