Explains Azure Private Link and Private Endpoints, how to privately connect PaaS services via private IPs over the Microsoft backbone, deployment steps, DNS configuration and security considerations.
Azure Private Link lets you access Azure PaaS services (Storage, SQL, App Service, etc.) and partner services privately from your virtual networks or on-premises environments — without exposing those services to the public internet. Traffic flows over the Microsoft backbone using private IP addresses, reducing surface area and improving security posture.Pay attention to the diagram below: a virtual machine in a peered network accesses a private endpoint using a private IP address. This removes public IP exposure for the PaaS resource.
A private endpoint is an elastic network interface (ENI) in your VNet with a private IP mapped to a single Azure resource. Even if other parts of the VNet are compromised, an attacker cannot reach the PaaS instance unless they can interact with that specific private endpoint NIC and bypass any NSG/other controls — drastically reducing attack surface.On the right side of the diagram you can see Azure PaaS and partner services accessed via Azure Private Link — not via the public internet. Internet traffic is blocked and communication occurs over the Microsoft backbone using private IP addresses.
A private endpoint projects an Azure service into your virtual network by assigning it a private IP address. For example, an Azure Storage blob can appear inside a VNet subnet as a local IP. DNS resolves the service name to the private endpoint’s IP, so communication between a VM (or other compute) and the service stays on the Microsoft backbone and never traverses the public internet.
This configuration blocks direct internet access to the resource, which reduces exposure to brute-force or port scanning attacks while preserving full service functionality via the private IP.
Read the next diagram left-to-right: it shows a consumer network connecting privately to a provider network over the Microsoft backbone — no public internet. On the consumer side you have a private endpoint (for example, 10.0.1.5). The client resolves the service name to that private IP and connects. The dotted line denotes Private Link: the private pipe mapping consumer private endpoints to the provider.On the provider side the Private Link service privately publishes the provider’s application. It sits behind a standard load balancer that fans out to backend VMs. The provider controls who can connect and must approve consumer private endpoint connections.Quick definitions:
Private Link = the private network pipe across the Microsoft backbone.
Private Endpoint = the consumer’s private IP (the NIC in the VNet).
Private Link service = how a provider privately publishes an application (backed by a load balancer and backend pool).
In the Storage Account > Networking, set Public network access to Disabled. This blocks public endpoints and forces private connectivity (private endpoint) for access.
After disabling public access, attempts to reach the blob via the public path fail with an authorization or access error:
Copy
kodekloud@vm-service-endpoints:~$ curl https://sanavidm.blob.core.windows.net/data/gl2.jpeg<?xml version="1.0" encoding="utf-8"?><Error> <Code>AuthorizationFailure</Code> <Message>This request is not authorized to perform this operation.</Message> <RequestId>b0cf934e-701e-0073-55c6-187af6000000</RequestId> <Time>2025-08-29T09:25:30.3316246Z</Time></Error>
Choose subscription, resource group (can reuse), and endpoint name (e.g., PEST — portal will append NIC).
Select resource type (Storage -> blob).
Pick the VNet and subnet where the private endpoint NIC will be placed. You can place it in the same subnet as your VMs or isolate private endpoints in a dedicated subnet.
DNS: choose how DNS resolution maps the service name to the private IP. Options:
Integrate with Azure Private DNS zones (recommended for Azure VMs and simplest).
Use your own DNS server with conditional forwarding.
Use host file overrides (not recommended for production).
If you enable Azure Private DNS integration in the portal, Azure will create the appropriate privatelink zone (for example, privatelink.blob.core.windows.net) and link it to your VNet automatically.
Continue through Tags, Review + create, and then Create.
Networking detail to plan for: private endpoints interact with subnet-level User Defined Routes (UDRs) and network policies. If you have UDRs routing traffic through a firewall, private endpoint traffic may bypass those UDRs unless the subnet’s “Network policies for private endpoints” is enabled so that NSGs and route tables apply to the private endpoint NIC. If you want UDRs/NSGs to affect the private endpoint NIC, enable network policies on the subnet; if you intentionally want the private endpoint to bypass subnet policies, keep it disabled.Depending on your firewall (Azure Firewall or an NVA) you may need SNAT configuration to enable required egress flows.
For this lab the network policy was left at its default, so no firewall configuration was required.After deployment the private endpoint NIC is attached to a “private link resource” representing the storage account. The portal shows DNS entries created for the private link — you should see the storage name resolving to the private IP (for example, 10.0.1.5) if the private DNS zone is linked and the VM uses Azure DNS.
Back on the VM, nslookup now should resolve the storage account to the private endpoint IP:
At this point traffic from the VM to the storage account flows to 10.0.1.5 (the private endpoint) over the Microsoft backbone, avoiding the public internet.
If you must access private endpoints from on‑premises, plan DNS carefully: use conditional forwarding to Azure DNS, deploy Azure Private Resolver, or configure conditional forwarders so on‑prem DNS queries resolve privatelink zones to private IPs.
Integration with edge services (example: Front Door)
If using edge services like Azure Front Door (Standard/Premium), you can enable “Enable Private Link Service” for origin groups. That forces Front Door to reach origins over Private Link rather than the public endpoint, allowing you to disable public access to the origin and ensure all traffic is inspected by edge protections (WAF, etc.).
Note: App Service Private Endpoint support requires a paid App Service tier — Free/Shared tiers do not support Private Link. Use Standard or higher for full feature support.
If your subnet uses UDRs or a firewall, explicitly configure “Network policies for private endpoints” on the subnet and verify your firewall/NVA supports private endpoint flows (SNAT, routing, and stateful inspection requirements).
With the private endpoint created and DNS validated (resolves to the private IP), your PaaS resource is now accessible privately. Additional DNS and on‑premises integration scenarios exist and should be planned based on your architecture.
With these steps and considerations, you can plan, deploy, and validate Azure Private Link and Private Endpoints to keep PaaS services private and secure.
