7.1 Virtual Network Service Endpoints & Policies

Virtual Network Service Endpoints & Policies

Securing enterprise access to Azure Platform-as-a-Service (PaaS) resources requires establishing perimeter controls that isolate critical data stores and application backends from the public internet. Historically, Azure PaaS services—such as Azure Storage, Azure SQL Database, Azure Key Vault, and Azure Cosmos DB—were exposed exclusively via public IP addresses and accessible over the public internet.

Azure Virtual Network (VNet) Service Endpoints provide direct, secure connectivity to Azure PaaS services over the optimized Microsoft Azure backbone network. By extending a virtual network's private IP identity to PaaS services, Service Endpoints allow network engineers to lock down PaaS firewalls strictly to authorized subnets, shutting down access from arbitrary internet clients.

1. Service Endpoints Architecture & Packet Routing Mechanics

When a VNet Service Endpoint is enabled on a subnet for a supported Azure service (e.g., Microsoft.Storage or Microsoft.Sql), Azure dynamically modifies the routing and identity of traffic originating from that subnet destined for the service's public IP ranges.

+-----------------------------------------------------------------------------+
|                   SERVICE ENDPOINT PACKET ROUTING MECHANICS                 |
|                                                                             |
|   WITHOUT SERVICE ENDPOINTS:                                                |
|   [VM: 10.1.0.4] --(Outbound SNAT / Public IP)--> [Public Internet]        |
|                                                          |                  |
|                                                          v                  |
|                                                [Azure Storage Public IP]    |
|                                                (PaaS Firewall Open/Public)  |
|                                                                             |
|   WITH SERVICE ENDPOINTS ENABLED ON SUBNET:                                 |
|   [VM: 10.1.0.4] --(Direct Microsoft Backbone Route)-----------------------> |
|                     - Route: VirtualNetworkServiceEndpoint                   |
|                     - Source IP Preserved: 10.1.0.4                          |
|                     - Next Hop: Azure Internal Backbone                      |
|                                                          |                  |
|                                                          v                  |
|                                                [Azure Storage Public IP]    |
|                                                (PaaS Firewall: ACL Subnet)  |
+-----------------------------------------------------------------------------+

System Route Injection (VirtualNetworkServiceEndpoint)

Enabling a Service Endpoint on a subnet triggers the Azure Software-Defined Networking (SDN) fabric to inject specialized system routes into the subnet's effective route table:

1. Route Destination: The destination prefix represents the regional or global public IP CIDR ranges of the target Azure PaaS service (e.g., Microsoft.Storage.EastUS or Microsoft.Sql).
2. Next Hop Type: The next hop is set to VirtualNetworkServiceEndpoint.
3. Longest Prefix Match Precedence: Because the injected PaaS route prefixes are specific public IP ranges (e.g., 20.150.0.0/17), they take precedence over broader routes such as 0.0.0.0/0 (Internet or Network Virtual Appliance).

Source IP Identity Shift

When an application on a Virtual Machine (e.g., 10.1.0.4) communicates with a PaaS resource over a Service Endpoint:

• The destination IP address remains the public IP address of the PaaS service (e.g., resolved via public DNS for mystorage.blob.core.windows.net).
• The packet does not undergo Source Network Address Translation (SNAT) to a public IP address or NAT Gateway IP.
• The underlying Azure physical network encapsulates the packet and presents the private IP address (10.1.0.4) and the Subnet Resource ID directly to the PaaS service firewall.

[!IMPORTANT] DNS and Public IP Retention: Service Endpoints do not allocate a private IP to the PaaS resource. The PaaS resource retains its fully qualified domain name (FQDN) and public IP address. Service Endpoints change the egress routing path and source identity verification on the Azure backbone, not the PaaS destination IP.

2. PaaS Firewall ACLs, Service Tags & System Route Precedence

To lock down PaaS infrastructure using Service Endpoints, administrators configure two interconnected components: enabling the endpoint on the subnet, and configuring the PaaS service firewall.

Configuring PaaS Firewall Virtual Network Rules

Once the Service Endpoint is enabled on a subnet, the PaaS service (e.g., Azure Storage Account or Azure SQL Server) can be configured with Virtual Network firewall rules:

1. Navigate to the PaaS resource's Networking / Firewalls and virtual networks blade.
2. Set Public network access to Enabled from selected virtual networks and IP addresses.
3. Add the specific Subnet Resource ID under Virtual networks.
4. Optionally allow trusted Microsoft first-party services (e.g., Azure Backup, Azure Monitor) via exception flags.

+-----------------------------------------------------------------------------+
|                    PAAS FIREWALL CONFIGURATION PATTERN                      |
|                                                                             |
|   Azure Storage Account / SQL Server:                                       |
|   - Public network access: Selected networks                                |
|   - Allowed Virtual Networks:                                               |
|       * Subscription: Sub-Prod-01                                           |
|       * VNet: VNet-Core-EastUS                                              |
|       * Subnet: Subnet-AppTier (Microsoft.Storage enabled)                  |
|   - Firewall IP Allowlist: (Optional corporate egress public CIDRs)         |
|   - Exceptions: Allow Azure services on the trusted services list           |
+-----------------------------------------------------------------------------+

Service Tags in Network Security Groups (NSGs)

When restricting outbound traffic from a subnet using Network Security Groups, you can use Service Tags to simplify rule creation without managing changing IP address lists.

Interaction Between Service Endpoints and User-Defined Routes (UDRs)

Network administrators frequently deploy a default route (0.0.0.0/0 -> Next Hop: VirtualAppliance) on subnets to force all outbound internet traffic through an Azure Firewall or third-party Network Virtual Appliance (NVA) for deep packet inspection.

+-----------------------------------------------------------------------------+
|               UDR VS. SERVICE ENDPOINT ROUTE PRECEDENCE                     |
|                                                                             |
|   Route Table on Subnet:                                                    |
|   1. User-Defined Route (UDR):  0.0.0.0/0 -> Next Hop: 10.1.0.100 (NVA)    |
|   2. Injected System Route:     20.150.0.0/17 (Storage) -> Next Hop:        |
|                                 VirtualNetworkServiceEndpoint               |
|                                                                             |
|   RESULT:                                                                   |
|   Storage traffic matches the more specific /17 prefix and bypasses the     |
|   NVA, flowing DIRECTLY over the Microsoft backbone.                        |
|   Non-storage internet traffic matches 0.0.0.0/0 and routes to the NVA.    |
+-----------------------------------------------------------------------------+

If corporate security policy mandates that all PaaS traffic must pass through an NVA, administrators must either:

• Remove the Service Endpoint from the subnet and inspect public PaaS traffic through the NVA, or
• Deploy Azure Private Endpoints instead.

3. Service Endpoint Policies for Azure Storage

While VNet Service Endpoints secure PaaS services against external internet attackers, they introduce a subtle internal security vulnerability: Data Exfiltration.

The Data Exfiltration Problem with Standard Service Endpoints

When you enable Microsoft.Storage as a Service Endpoint on a subnet, Azure allows workloads on that subnet to route traffic across the Microsoft backbone to any Azure Storage Account in the world—including storage accounts in other subscriptions, other organizations, or an attacker's personal Azure tenant.

+-----------------------------------------------------------------------------+
|                 DATA EXFILTRATION RISK WITH SERVICE ENDPOINTS               |
|                                                                             |
|   [Compromised VM in Subnet]                                                |
|       |                                                                     |
|       |--- (Legitimate Traffic) ----> [Corporate Storage: corpdata.blob...]  |
|       |                                (Allowed by PaaS Firewall)           |
|       |                                                                     |
|       +--- (EXFILTRATION ATTACK) ---> [Attacker Storage: rogue.blob...]     |
|                                        (ALLOWED by default Service Endpoint)|
|                                        (Transfers company secrets out!)     |
+-----------------------------------------------------------------------------+

Service Endpoint Policies (SEP) Architecture

Service Endpoint Policies (SEP) allow organizations to filter and restrict outbound Service Endpoint traffic originating from a subnet to specific, authorized Azure Storage accounts.

+-----------------------------------------------------------------------------+
|                 SERVICE ENDPOINT POLICY RESTRICTION SCOPES                  |
|                                                                             |
|   Scope Level            Resource ID Format                                 |
|   --------------------   ------------------------------------------------   |
|   Specific Account       /subscriptions/{subId}/resourceGroups/{rgName}/    |
|                          providers/Microsoft.Storage/storageAccounts/{name} |
|                                                                             |
|   All Accounts in RG     /subscriptions/{subId}/resourceGroups/{rgName}     |
|                                                                             |
|   All Accounts in Sub    /subscriptions/{subId}                             |
|                                                                             |
|   All Accounts in Tenant /tenants/{tenantId}                                |
+-----------------------------------------------------------------------------+

How Service Endpoint Policies Operate:

1. Resource Association: A Service Endpoint Policy is created and linked directly to the target subnet where the Microsoft.Storage Service Endpoint is active.
2. Policy Definition: The policy contains one or more policy definitions specifying allowed Service Endpoint Policy Definitions (e.g., Microsoft.Storage/accounts or Microsoft.Storage/accounts/table).
3. Strict Whitelisting: Once applied, any outbound request to a storage account not explicitly defined in the policy is immediately dropped by the Azure SDN fabric before leaving the subnet, returning an HTTP 403 Forbidden / network timeout to the client.

[!NOTE] Service Endpoint Policy Scope Limitation: As of current Azure networking specifications, Service Endpoint Policies are supported exclusively for Azure Storage services (Blobs, Tables, Queues, Files, and Azure Data Lake Storage Gen2). They are not available for Azure SQL Database, Key Vault, or Cosmos DB.

4. Key Limitations, Hybrid Routing Constraints & Design Matrix

While Service Endpoints offer simple implementation and zero additional service cost, they have fundamental architectural constraints that influence network design.

1. No Transitive Hybrid Connectivity (VPN / ExpressRoute)

Traffic originating from an on-premises network connected to Azure via Site-to-Site (S2S) VPN, Point-to-Site (P2S) VPN, or ExpressRoute cannot access PaaS resources over a Service Endpoint enabled on an Azure VNet.

• Azure Virtual Network Gateways do not perform gateway transit for Service Endpoints.
• If an on-premises client attempts to access a PaaS service whose firewall is locked down to a VNet subnet, the on-premises traffic arrives with the on-premises public egress IP and is rejected by the PaaS firewall.

2. Multi-Region and Global Service Endpoint Scope

Service Endpoints are generally regional in nature:

• Enabling Microsoft.Storage on a subnet in East US optimizes traffic to Storage Accounts in East US and paired regions (West US).
• Cross-region access to other remote regions (e.g., North Europe) may route over standard Azure public IP infrastructure unless regional service endpoint policies or cross-region service tags are configured.

3. Service Endpoints vs. Private Endpoints Quick Comparison