Design and Implement Private Access to Azure Services
Private Endpoint versus Service Endpoint
A Private Endpoint is a network interface in your subnet holding a private IP for a PaaS service instance (Storage, SQL, Key Vault, Cosmos DB, and so on). It uses Azure Private Link, so traffic never leaves the Microsoft backbone and is reachable from peered VNets and on-premises. Connections to services owned by another tenant require approval. A Service Endpoint instead extends the VNet identity to the service: the PaaS firewall restricts access to that subnet, traffic stays on the Azure backbone, but there is no private IP and access does not work from on-premises or across peering.
Making DNS work
A Private Endpoint is only as useful as its name resolution. Each service publishes a privatelink zone - for example privatelink.blob.core.windows.net - containing an A record for the private IP. Link that zone to every VNet that must resolve it. On-premises clients need a DNS forwarder in Azure that forwards the privatelink namespace to 168.63.129.16. Splitting storage into separate sub-resources (blob, file, queue) means each needs its own record - a favourite exam trap.
Overlaps and policies
Do not mix a service endpoint and a private endpoint for the same service on the same subnet. Network policies for private endpoints (NSGs and UDRs) are configurable, but if they are disabled, filtering and forced tunnelling will silently not apply.
Rule of thumb: if the consumer might be on-premises, in another VNet, or another tenant, use Private Endpoint. If the consumer is only ever inside one VNet and simplicity matters, a service endpoint plus the service firewall is enough.