Private Endpoint vs Service Endpoint
Verdict: On-premises reachability, instance-level isolation, or "no public route" all force Private Endpoint - and it only works once the private DNS zone is linked to every consumer VNet. Service Endpoint stays in-VNet and keeps the service's public IP.
| Criterion | Private Endpoint | Service Endpoint |
|---|---|---|
| Maps to | One specific resource instance | The whole service, region-wide |
| IP | Private IP from your VNet | Service keeps its public IP |
| On-premises | Reachable over ExpressRoute private peering or VPN | In-VNet only - never from on-premises |
| Exfiltration protection | Instance-level - other resources in the service are unreachable | None: any instance of the service is reachable |
| DNS | Requires the Azure private DNS zone linked to each consumer VNet | No DNS change - FQDN unchanged |
Rules
- Choose Private Endpoint with private DNS zone integration and public access disabled when an auditor requires no possible public route.
- Link the private DNS zone to every consumer VNet - an unlinked spoke resolves the public IP and silently bypasses the endpoint.
- Choose Private Endpoint for on-premises consumers; Service Endpoints cannot be consumed from outside the VNet.
Traps
- Clients resolving the public IP two days after endpoint creation is a missing DNS zone link on the spoke - not a subnet or firewall problem.
- A firewall allow-list still leaves the database publicly reachable - allow-listing is not private connectivity.