Platform services such as Azure SQL and Storage have public endpoints by default. Private endpoints and service endpoints both keep traffic on Microsoft’s network, but they work very differently, and private endpoints depend on correct DNS configuration.
| Private endpoint | Service endpoint | |
|---|---|---|
| Target | A private IP in your VNet | The service’s public endpoint, reached over the Azure backbone |
| Reachable from on-premises | Yes, over ExpressRoute private peering or VPN | No, Azure subnets only |
| Public access | Can be disabled | Still a public endpoint |
- ExpressRoute Microsoft peering still reaches public endpoints; public peering is deprecated.
- Forced tunnelling sends traffic for Azure SQL’s public endpoint via on-premises, adding latency. A Microsoft.Sql service endpoint makes that traffic bypass the tunnel, and service endpoints are free. Moving the database to MI or to VMs doesn’t fix the routing.
DNS for private endpoints
A private endpoint is only useful if clients resolve the service’s name to its private IP. A private DNS zone linked to the VNet holds the private A record, but it is queryable only via Azure’s resolver at 168.63.129.16, which is unreachable from on-premises. On-premises clients therefore resolve through this chain: client, on-premises DNS server (conditional forwarder), a forwarder VM in the VNet (or Azure DNS Private Resolver), 168.63.129.16, the private zone, and finally the private IP.
Common trap: Forwarding on-premises DNS queries to the public DNS zone — that resolves to the public endpoint; forward to the private zone via Azure’s resolver (through a forwarder VM or DNS Private Resolver).
App Service to a private database
Connecting App Service privately to SQL uses two features in opposite directions. Regional VNet integration is outbound (App Service to private IPs, such as VMs or a private endpoint), while a private endpoint is inbound. VNet integration needs a subnet delegated to Microsoft.Web/serverFarms; the SQL private endpoint needs another, non-delegated subnet, so the design uses two subnets. Link the privatelink.database.windows.net private DNS zone to the VNet; a public zone can’t return private IPs.
Figure 12.2 shows the two subnets and the DNS lookup that make the connection private.
Common trap: Using a single subnet plus DNS Private Resolver for App Service to SQL — you need two subnets (one delegated for VNet integration, one for the private endpoint) and a linked private DNS zone.
Administrative access without public IPs
Azure Bastion gives RDP/SSH access to VMs over TLS from the Azure portal, so the VMs need no public IP addresses.
Common trap: Publishing administrative access through Front Door — Front Door publishes HTTP(S) only; use Azure Bastion for RDP/SSH.