Private access to Azure services

Private endpoint, service endpoint or neither

Quick rules: need on-premises or peered-VNet private access, no public endpoint, or exfiltration protection means private endpoint. Need free, simple subnet-to-service lockdown with no DNS work means service endpoint. Microsoft recommends private endpoints for new designs. Neither applies when the answer is just a firewall allowlist or NSG service tag.

Private endpoints

How they work

• A private endpoint is a network interface in a subnet of your VNet. It gets a private IP and is connected by Private Link to a specific Azure resource instance (a storage account’s blob service, an Azure SQL logical server, a Key Vault, a web app…).
• Traffic from the VNet (and from peered VNets and on-premises networks) goes to that private IP, and stays on the Microsoft backbone.
• One resource can have many private endpoints. One endpoint maps to one sub-resource (the group ID: for storage blob, file, queue, table, dfs, web; for Azure SQL sqlServer; for Key Vault vault; for web apps sites). You need one endpoint per sub-resource you use (blob and file need two).
• Endpoints can be in a different region than the target and in a different subscription or tenant (with approval).

Planning

• Subnet: any subnet with available IPs. Plan address space for each endpoint. Many designs use a dedicated subnet for endpoints. No delegation is needed.
• Network policies: by default a private endpoint ignores NSGs and UDRs on its subnet. Enable the subnet’s private endpoint network policies (NSG and/or route table) to make NSG rules apply to endpoint traffic and to allow UDR /32 routes. Without that, you can’t filter endpoint traffic with NSGs.
• Name and DNS: decide the private DNS zone for each service and where it’s linked (see below).
• Cost and scale: hourly charge plus per-GB processing. Consolidate where it makes sense. Check per-subscription limits.
• Public network access: after creating the endpoint, set the service’s public network access to Disabled (or use its firewall) if the requirement is “no public exposure”.

Creating and approving

• Create from the resource (Networking blade) or from Private Link Center, choosing the VNet, subnet, target resource and sub-resource, and the DNS integration option.
• Connection approval:
  • Auto-approved when you have RBAC permission on the target resource (the Microsoft.<provider>/<resource>/privateEndpointConnectionsApproval/action permission, included in Owner/Contributor).
  • Pending when you don’t. The resource owner must approve (or reject) the connection. Connection states are Pending, Approved, Rejected, Disconnected.
• Endpoints to your own Private Link service use manual approval unless the consumer subscription is on the auto-approval list.

Controlling access to the endpoint

• NSG on the endpoint subnet (with network policies on): allow only the client subnets that should reach it (inbound rules apply to the endpoint IP). NSGs don’t support service tags for the endpoint’s destination service.
• Application security groups can be attached to the endpoint NIC.
• RBAC: who can create or approve connections.
• Service-side firewall: disable public access, choose selected networks and private endpoints.
• Azure Policy: require private endpoints, deny public network access, or deploy DNS records (DeployIfNotExists) for the correct zone.

DNS integration

This is the most tested part of the topic. With a private endpoint, the service’s public name must resolve to the private IP inside your network. If it doesn’t, clients keep going to the public IP, and with public access disabled they are blocked.

How it works:

1. The client asks for mystorage.blob.core.windows.net.
2. Public DNS returns a CNAME to mystorage.privatelink.blob.core.windows.net.
3. If a private DNS zone privatelink.blob.core.windows.net is linked to the client’s VNet and has an A record for mystorage, the client gets the private IP. Otherwise it gets the public IP.

Key facts:

• Use the recommended zone name per service. Don’t invent names. Common ones:

• Creating the endpoint in the portal with Integrate with private DNS zone creates the zone, the A record and the VNet link (for the VNet the endpoint is in).
• Other VNets (spokes, peered VNets) must also be linked to the zone, or must forward DNS to a resolver that can see it. Peering doesn’t make the zone visible.
• Hub-and-spoke: centralize one set of private DNS zones in the hub subscription, linked to the hub (and spokes, or the hub’s DNS forwarder/Private Resolver). Avoid creating duplicate zones per spoke. Duplicate zones are the classic cause of wrong answers.
• Custom DNS server in the VNet: configure it to forward privatelink and the public zone to 168.63.129.16 (the Azure resolver). Don’t just forward the privatelink name to the internet.
• Don’t override the public zone with a private zone (for example an Azure SQL private zone named database.windows.net) because it breaks resolution of other servers. Use the privatelink zone.
• Manual option: host file or custom A records in your DNS server. Works, but doesn’t scale and ignores IP changes.
• Verify with nslookup <name> from a VM in the VNet. It should return the private IP and a privatelink CNAME chain.

On-premises DNS

On-premises clients that use a private endpoint need to resolve to the private IP over VPN or ExpressRoute:

• Create a conditional forwarder in the on-premises DNS server for the public zone suffix of the service (for example blob.core.windows.net) pointing to a DNS resolver in Azure: the Azure DNS Private Resolver inbound endpoint (preferred, managed) or a DNS forwarder VM that forwards to 168.63.129.16.
• The resolver (in a VNet linked to the private DNS zone) then returns the private IP.
• Forwarding privatelink.blob... also works, but forwarding the public suffix is the documented pattern, because the client queries the public name first.
• Also needed: routing to the endpoint IP (VPN or ER advertises the VNet prefix) and NSGs allowing it.
• Without a resolver, on-premises machines would resolve the public IP and bypass the endpoint.

Private Link service

Private Link service lets you expose your own service (running behind an Azure Standard Load Balancer) to consumers in other VNets, subscriptions or tenants through private endpoints, without peering, public IPs or VNet address overlap concerns.

Pick a Private Link service for SaaS-style exposure of an internal app to customers or partner VNets, or for private origins for Front Door Premium (internal LB behind a Private Link service). The NAT IP subnet must have private link service network policies disabled (it’s not for NSG filtering on the NAT subnet). Scale limits are per-service: more NAT IPs allow more connections (each NAT IP supports around 64,000 TCP flows per backend).

Private Link service with on-premises clients

On-premises consumers can reach a service published through Private Link in two ways:

• Create a private endpoint to the service in an Azure VNet that on-premises is connected to (VPN or ExpressRoute private peering). On-premises clients then use the endpoint’s private IP (DNS to the private zone via conditional forwarder or Private Resolver).
• If the on-premises system is the provider (service in a different network), the Private Link service must sit in Azure in front of a Standard LB that routes to on-premises backends (IP-based backend pool). That’s allowed since backends can be IP addresses reachable over the connection.
• In both, routing (BGP/UDR) and DNS must be set and the on-premises firewall must allow the traffic.

Service endpoints

How they work

A service endpoint extends your subnet’s identity to a service. Traffic from the subnet to the service takes the backbone (not the internet) and arrives with the subnet/VNet identity instead of a public IP, so the service can allow that VNet or subnet in its firewall. The target stays the public endpoint.

• Enable per subnet for each service type: Microsoft.Storage, Microsoft.Sql, Microsoft.KeyVault, Microsoft.AzureCosmosDB, Microsoft.ServiceBus, Microsoft.EventHub, Microsoft.Web and more. Also Microsoft.Storage.Global for storage in any region (regional by default, in the VNet’s region and its paired region).
• Then in the service’s firewall/networking settings, add the VNet rule for the subnet. Both steps are needed: the subnet-side enablement and the service-side rule.
• Enabling service endpoints adds a system route with next hop VirtualNetworkServiceEndpoint for the service’s prefixes, and changes the source IP the service sees from public to private. Existing firewall rules that allowed the old public IP stop matching during the switch, so plan for a short interruption.
• No cost, no DNS change, no extra IP addresses.
• Not reachable from on-premises. For on-premises clients going through ExpressRoute or VPN, they see the service’s public endpoint. Private endpoints solve this.
• Forced tunneling: service endpoint routes override the default route to a firewall or on-premises, so service traffic still goes direct to the service. If you must inspect it, use a private endpoint or disable the service endpoint.
• Works only for the VNet’s own subnets and peered VNets don’t inherit endpoints (enable on each subnet).

Service endpoint policies

By default a service endpoint reaches every resource of that type, including storage accounts you don’t own, which is an exfiltration risk. A service endpoint policy is attached to a subnet and filters egress to only the specific resources listed.

• Supported for Azure Storage (Microsoft.Storage). Definitions list allowed storage accounts, resource groups or subscriptions (by resource ID), or an alias for Azure-managed storage needed by the platform.
• The policy applies to traffic over the service endpoint for that service. It’s not needed for traffic to private endpoints.
• Combine with the storage account’s own firewall (allow only that subnet) for both directions of control.

Configuring access

1. Enable the service endpoint on the subnet (VNet > Subnets, choose the service).
2. On the service, set the networking to selected networks and add the VNet/subnet. Optionally add IP rules for on-premises public IPs.
3. Optionally create a service endpoint policy and associate it with the subnet.
4. Check effective routes on the NIC for the endpoint route. Verify with NSG outbound rules (use the Storage or Sql service tags to allow the traffic if your NSG denies internet).

Service endpoint or private endpoint, scenarios

Troubleshooting

• Name resolves to a public IP from a VM: private DNS zone missing, not linked to that VNet, no A record, or the VM uses a custom DNS server that doesn’t forward to Azure.
• Name resolves to the private IP but connection fails: connection is Pending/Rejected, NSG with network policies blocks it, route problem for on-premises clients, or the service’s firewall blocks.
• Works from VNet, not on-premises: no conditional forwarder, or no route to the endpoint subnet.
• Service endpoint 403 from storage: subnet endpoint not enabled, VNet rule missing, or the request came from a peered VNet or on-premises IP.
• Use Network Watcher connection troubleshoot and the private endpoint “DNS configuration” tab, nslookup, and Private Link Center to see connection state.