How to Use Azure Private Endpoints for Blob Storage (Private Link + Private DNS)
Understanding Azure Private Endpoints (Azure Private Link) for Storage
Sometimes “restrict access to a VNet” is not enough. You might need a way for an Azure service (like Storage) to be reachable using a private IP address inside your VNet, so traffic never relies on a public endpoint and can also work from on-prem networks over VPN/ExpressRoute.
That’s what Private Endpoints (Azure Private Link) are for.
Private Endpoint vs Service Endpoint (the real difference)
Service Endpoints
- Storage still uses its public endpoint (public DNS name).
- The Storage firewall can allow traffic only from specific VNet/subnets.
- Great for Azure-to-Azure scenarios.
- Not designed for on-prem to PaaS access in the same way (service endpoints don’t extend to your on-prem network).
Private Endpoints (Private Link)
- The service gets a private IP from your VNet (via a network interface).
- DNS is updated so the same service name resolves to a 10.x/172.16/192.168 address inside your network.
- Enables full private connectivity, including from on-prem (VPN/ExpressRoute) when DNS is configured correctly.
- Best for high-security or complete network isolation requirements.
What a Private Endpoint is (plain English)
A private endpoint is a NIC (network interface) placed in your subnet. That NIC gets a private IP. Azure maps that NIC to a specific service target like:
- Storage blob
- Storage file
- Storage queue
- Storage table
Important: each sub-resource typically needs its own private endpoint (for example, one for blob, another for file).
Walkthrough: Private Endpoint for Blob Storage
Starting point
- Storage account has a container like
Imageswith a blob inside. - Networking is set to All networks, so the blob URL works from:
- Your laptop (public internet)
- A VM in Azure (still using the public endpoint unless locked down)
Step 1: Disable public access to the Storage account
- Open Storage account in Azure portal
- Go to Networking
- Set Public network access to:
- Disabled (or restrict to Selected networks depending on your design)
- Save changes
Expected result:
- Accessing the blob URL directly will eventually fail with Authorization failure (403).
- Even your Azure VM will fail at this point, because it was still using the public endpoint.
Azure will often hint: “Public access disabled, create a private endpoint.”
Step 2: Create the Private Endpoint (Blob)
- Storage account → Networking → Private endpoint connections
- Click + Private endpoint
- Name it (example:
pe-blob)
Resource target
- Choose the sub-resource: blob
Network
- Select your VNet (example:
VNET-One) - Select the subnet (example:
defaultor a dedicated subnet)
DNS
- Enable Integrate with private DNS zone
- Accept defaults (commonly creates/uses):
privatelink.blob.core.windows.net
- Click Review + create → Create
What gets created:
- The Private Endpoint resource
- A network interface with a private IP (example:
10.0.0.5) - A Private DNS zone with an A record pointing your storage account name to
10.0.0.5
Step 3: Validate with DNS (this is the key)
From your laptop (outside Azure VNet)
Run nslookup <storageaccount>.blob.core.windows.net
- You will usually still see a public IP returned.
- Result: access fails (expected), because you’re not inside the private network and DNS is not resolving to private IP.
From a VM inside the same VNet
Run the same nslookup from the VM:
- You should see the private IP (example:
10.0.0.5) - Result: the VM can access the blob successfully again
This proves the private endpoint is working and DNS is resolving correctly inside the VNet.
Why Private DNS matters so much
Without Private DNS integration (or an equivalent DNS design), your systems will keep resolving the service to its public IP, even if a private endpoint exists.
Inside Azure, linking the private DNS zone to the VNet ensures that:
<storageaccount>.blob.core.windows.netresolves to10.x.x.x
For on-prem, you must extend this DNS behavior to your internal DNS (more below).
Using Private Endpoints from on-prem (VPN / ExpressRoute)
This is where Private Endpoints shine.
To make on-prem clients resolve the Storage account to the private IP, you typically need one of these DNS approaches:
- Conditional forwarder on-prem for
privatelink.blob.core.windows.netpointing to an Azure DNS resolver path - Azure DNS Private Resolver (common modern approach)
- Custom DNS servers in Azure that can resolve the private zone, then forward from on-prem
If on-prem DNS still returns the public IP, traffic will fail or go public, which defeats the purpose.
When you should choose Private Endpoints
Use Private Endpoints when you need:
- “No public internet path” access to PaaS
- Strict compliance or isolation requirements
- On-prem to Azure PaaS access over VPN/ExpressRoute
- Predictable private routing and DNS behavior
Use Service Endpoints when:
- You mainly need Azure-to-Azure restriction by subnet
- You want simpler setup and do not need private IP-based connectivity
Key takeaways
- Private Endpoint = private IP inside your subnet via a NIC.
- DNS is mandatory for a clean experience.
- Great for hybrid connectivity (on-prem + Azure) where service endpoints do not meet the requirement.
- For Storage, remember: blob/file/queue/table often require separate private endpoints.
