Skip to main content
In this lesson you’ll learn about Azure Virtual Network service endpoints — a mechanism that lets resources in a virtual network securely access supported Azure PaaS services over the Microsoft backbone network. Service endpoints allow you to use a virtual network (and specific subnets) as an allowlist for Azure services, keeping traffic between your VMs and PaaS services off the public internet. This lesson covers:
  • What a service endpoint is and how it works.
  • How to enable service endpoints on a subnet so resources in that subnet can securely access supported Azure services.
A presentation slide titled "Learning objectives" with two points: "What is a Service Endpoint?" and "Add Service Endpoints to a subnet," shown beside a turquoise left panel and colorful numbered markers.
Let’s get started with a clear definition and why you’d use service endpoints. What is a service endpoint?
  • A service endpoint extends your virtual network identity to a supported Azure service. When enabled on a subnet, traffic to the selected PaaS service (for example, Azure Storage or Azure SQL Database) stays on the Microsoft backbone instead of going over the public internet.
  • The PaaS service can then be configured to accept traffic only from the virtual network/subnet — effectively using the VNet/subnet IP range as an allowlist.
How service endpoints work (high level)
  1. You enable one or more service endpoints on a subnet and select which Azure service namespace(s) (for example, Microsoft.Storage) are allowed.
  2. Resources in that subnet (VMs, App Service Environment, etc.) route to the PaaS service using Azure’s internal network.
  3. The PaaS service sees the request coming from the VNet/subnet and can enforce firewall rules to allow only that VNet/subnet.
Key benefits
  • Traffic remains on Microsoft’s private backbone, improving security and reducing exposure to the internet.
  • You can lock down service-level firewalls to accept traffic only from specific VNets/subnets.
  • Simple to configure and useful for many common scenarios where private connectivity is required but private endpoints are not feasible.
Commonly used service endpoints (examples)
Service endpoint namespaceTypical Azure service
Microsoft.StorageAzure Storage (Blob, File, etc.)
Microsoft.SqlAzure SQL Database
Microsoft.DocumentDBAzure Cosmos DB
Microsoft.EventHubEvent Hubs
Microsoft.ServiceBusService Bus
Microsoft.ContainerRegistryAzure Container Registry
For the complete, up-to-date list of supported services and namespaces, see the Azure docs:
Service endpoints are often the fastest way to lock down access to a PaaS service from a VNet. However, for scenarios that require private IP addresses inside your VNet, DNS-based resolution of the service endpoint, or finer-grained resource-level access, consider using Private Endpoints instead. See the “Considerations” section below.
How to enable service endpoints
  • Azure Portal (GUI)
    1. Navigate to your Virtual Network > Subnets.
    2. Select the subnet you want to modify.
    3. Under “Service endpoints”, click Add, then choose the service namespace(s) (for example, Storage).
    4. Save the subnet settings. Next, configure the target PaaS resource’s firewall to allow the VNet/subnet.
  • Azure CLI 
# Enable a service endpoint for Storage on a subnet
az network vnet subnet update \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --name MySubnet \
  --service-endpoints Microsoft.Storage
  • Azure PowerShell
# Example: Add Microsoft.Storage service endpoint to a subnet config and update the vnet
$vnet = Get-AzVirtualNetwork -Name MyVNet -ResourceGroupName MyResourceGroup
Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name MySubnet -AddressPrefix 10.0.0.0/24 -ServiceEndpoint @("Microsoft.Storage")
$vnet | Set-AzVirtualNetwork
After enabling the endpoint on the subnet, update the PaaS service firewall (for example, Storage account firewall) to add the virtual network rule that references the VNet/subnet. Advanced options and policies
  • Service Endpoint Policies let you restrict which service resources (for example, which Storage accounts) a subnet can access even when the service endpoint is enabled. This provides control over which specific service instances are reachable.
  • Network Security Groups (NSGs) are applied to subnets and still control traffic flow; enabling a service endpoint does not bypass NSG rules.
Limitations and considerations
  • Service endpoints do not provide a private IP address for the PaaS service within your VNet. For a private IP in your VNet, use Private Endpoints.
  • Some services are better secured with Private Endpoints (preview: using private DNS zones and private IPs). Review each service’s security model before deciding.
  • Service endpoints rely on the Azure backbone; cross-region behavior should be verified for your architecture and compliance requirements.
  • Ensure your PaaS resource firewall rules are configured to accept VNet/subnet traffic after enabling the endpoint.
Private Endpoints provide stronger isolation and a private IP address in your VNet. If your compliance or security requirements mandate private IPs or resource-level access control, prefer Private Endpoints over Service Endpoints.
Examples and common scenarios
  • Locking down an Azure Storage account to only accept traffic from a production VNet/subnet.
  • Allowing backend VMs in a subnet to access a managed SQL Database without traversing the internet.
  • Using Service Endpoint Policies to ensure a subnet can only reach approved storage accounts.
References and further reading Next steps
  • Practice enabling a service endpoint on a non-production subnet and verify traffic flows via the Microsoft backbone.
  • Configure a Storage account firewall to allow your VNet and confirm access from a VM in that subnet.

Watch Video