Start with the endpoint the client actually reaches
An Azure service endpoint is enabled on a subnet for a supported service such as Storage, SQL Database or Key Vault. It extends the virtual network identity to that service. You then configure a virtual network rule on the resource. The familiar service name still resolves to its public IP, but traffic from the enabled subnet takes an optimized route over the Microsoft backbone and presents the client's private VNet address to the service.
An Azure private endpoint is a read-only network interface with a private IP from your VNet. It maps to one supported Private Link resource and target subresource—for example, the blob subresource of a Storage account. Clients connect to that private IP through the service's normal FQDN after DNS has been configured for the private path.
If the requirement says “private IP,” “on-premises over VPN/ExpressRoute,” or “disable public network access,” think Private Link and private endpoints. If it accepts the service's public endpoint and only needs a simple subnet identity rule, a service endpoint may fit.
Private Endpoint vs Service Endpoint comparison
Neither option replaces identity authorization. Network reachability can allow a client to contact Storage or Key Vault, but Microsoft Entra authentication, Azure RBAC and service-specific authorization still determine what the identity may do.
DNS is the private endpoint control plane people miss
A private endpoint is useful only when clients resolve the service name to its private IP. Azure services commonly use a public FQDN that follows a CNAME chain into a privatelink zone. A private DNS zone linked to the VNet supplies the private address. The exact zone name depends on the service and subresource, so use Microsoft's current private endpoint DNS table rather than guessing.
For hybrid networks, an on-premises resolver normally needs conditional forwarding toward a DNS service that can resolve the Azure private zone. A successful VPN route is not enough if on-premises DNS still returns the public service address.
Service endpoints behave differently: Microsoft states that existing service DNS entries remain unchanged and continue to resolve to public IP addresses. That public resolution does not mean packets traverse the public internet; the subnet's service-endpoint route directs supported service traffic over the Azure backbone.
Worked scenario 1: private Storage access from spokes and on-premises
Requirement: Applications in peered spoke VNets and a datacenter connected through ExpressRoute must reach one Storage account without using its public network endpoint.
Create the private path
Create a private endpoint in a reachable VNet subnet for each required Storage subresource, such as Blob or File. Approve the connection when the workflow requires it.
Design DNS
Link the correct private DNS zone to the consuming VNets and configure hybrid DNS forwarding so the normal Storage FQDN resolves to the private IP.
Decide public access
After validating private connectivity, apply the Storage public network access setting required by policy. Do not assume endpoint creation changed it.
The requirement explicitly needs a private IP, hybrid connectivity and a design that can disable public access. A service endpoint cannot serve traffic that originates on-premises.
Worked scenario 2: simple subnet-restricted access
Requirement: Workloads in one Azure subnet must reach a supported regional PaaS service. The public service endpoint is acceptable, hybrid access is not required, and the team wants minimal endpoint management.
Enable the service endpoint on the workload subnet, then add that subnet to the service resource's virtual network rules. Validate the service's region and support constraints. This design extends subnet identity to the service without creating a private endpoint NIC or changing DNS to a private IP.
These are illustrative architecture scenarios for learning; they are not customer incidents or claims about a production deployment.
Production-style failure: the private endpoint is approved but access still fails
The portal shows an approved connection, yet a VM and an on-premises client time out. Avoid recreating the endpoint immediately. Follow the evidence from name resolution to application authorization.
- Resolve the exact FQDN from each client. It should return the expected private endpoint IP for the private path. Compare the CNAME chain and final A record.
- Inspect the private DNS zone. Verify the service-specific zone name, record, VNet links and that auto-registration assumptions are not masking a missing record.
- Trace hybrid resolution. Confirm the on-premises resolver forwards the private zone to an Azure-capable resolver and does not cache a public answer.
- Confirm connection state and subresource. An approved Blob endpoint does not automatically provide File, Queue or Table access.
- Check routes and network policy. Validate reachability to the private IP, NSG rules and UDR behavior where applicable.
- Check public-access intent separately. If DNS returns the public address while public access is disabled, the failure is expected.
- Check identity and service authorization. A working TCP path does not grant data-plane permission.
If Azure clients work but on-premises clients resolve the public endpoint, correct conditional forwarding and clear stale resolver caches. If every client resolves publicly, repair the private DNS zone link or record before changing routes or application code.
Common AZ-104 exam mistakes
- Calling a service endpoint a private IP connection.
- Assuming a private endpoint automatically disables the public endpoint.
- Choosing a service endpoint for an on-premises-origin requirement.
- Creating one Storage private endpoint and assuming it covers Blob, File, Queue and Table subresources.
- Using a private IP in application configuration instead of preserving the service FQDN and fixing DNS.
- Forgetting that the private endpoint is consumer-initiated; the service provider cannot use it to initiate arbitrary connections into the VNet.
- Ignoring identity authorization after network connectivity succeeds.
- Diagnosing every private endpoint failure as an NSG issue before checking DNS and approval state.
Frequently asked questions
What is the simplest difference between a private endpoint and a service endpoint?
A private endpoint gives a supported service a private IP address in your VNet through Azure Private Link. A service endpoint keeps the service on its public endpoint but extends the subnet identity to the service so a virtual network rule can allow that subnet.
Does a service endpoint make the Azure service private?
No. Microsoft documents that the service DNS name continues to resolve to a public IP. Traffic from the enabled subnet follows an optimized Azure backbone route, and service firewall rules can restrict the resource to selected virtual networks.
Does creating a private endpoint automatically disable public access?
Not necessarily. A private endpoint provides a private path, but public network access is a separate service-level control. Verify the target service configuration instead of assuming the public endpoint was disabled.
Why does a private endpoint often fail even when its connection is approved?
DNS is a frequent cause. The service FQDN must resolve to the private endpoint IP for clients using the private path. Check the private DNS zone, VNet link, record, CNAME chain and any on-premises conditional forwarding.
Can an on-premises client use a service endpoint?
Microsoft states that service endpoints cannot be used for traffic originating from on-premises. A private endpoint can be reached from on-premises through VPN or ExpressRoute when routing and DNS are configured correctly.
Official Microsoft references
Validate implementation details in Microsoft Learn: private endpoint overview, virtual network service endpoints, private endpoint DNS values and the official AZ-104 study guide.