This chapter covers Azure Private Endpoints for Azure Storage, a critical networking feature that enables secure, private connectivity from virtual networks to storage accounts over the Microsoft backbone. For the AZ-104 exam, approximately 10-15% of questions in the Storage domain (Objective 2.3) test your understanding of private endpoints, their configuration, and how they differ from service endpoints. You must know the exact mechanics, DNS resolution behavior, and integration with related services like Private Link and Network Security Groups to pass scenario-based questions.
Jump to a section
Imagine a large office building (Azure Storage) that receives mail through a central mailroom (public endpoint). Anyone on the street can send letters to the building's public address, but the mailroom staff must inspect, log, and forward each letter inside—this adds delay and security risk. Now, the company decides to install a private mail slot directly into each department's secure corridor (virtual network). Each slot is a private endpoint: a network interface with a private IP from the department's internal subnet. When the accounting department (a VM) wants to send a document to the storage room (Blob Storage), they drop it through their private slot. The slot is physically connected to a dedicated chute that bypasses the public mailroom entirely—no inspection, no logging by external staff, and no exposure to the street. The slot itself is not a room or a server; it's just a passageway (a network interface) that links the department's corridor to the storage room's internal loading dock (the storage service's private link). From the department's perspective, the storage room appears to be right next door (same IP space). From the outside, the storage room's public address still exists, but the mailroom will refuse any letters that try to use the public slot if you configure it to block all public access. The key mechanism: the private slot is created by Azure's Private Link service, which sets up a one-to-one mapping between the department's chosen IP and the storage resource's backend. Traffic flows over the Microsoft backbone, never touching the public internet, and the department sees the storage as if it were a resource inside its own network.
What is a Private Endpoint and Why Does It Exist?
A Private Endpoint is a network interface that connects privately and securely to a service powered by Azure Private Link. For Azure Storage, it assigns a private IP address from your virtual network (VNet) to the storage account, making the storage service accessible over the Microsoft backbone network instead of the public internet. The primary reasons for using private endpoints are:
Security: Eliminate data exfiltration risks by ensuring traffic never traverses the public internet.
Compliance: Meet regulatory requirements that mandate private connectivity.
Performance: Reduce latency by keeping traffic within Azure's network.
Simplified network architecture: Access storage using private IPs, integrating seamlessly with existing VNet-based security policies.
How Private Endpoints Work Internally
When you create a private endpoint for a storage account, Azure Private Link establishes a connection between the VNet and the storage service. The private endpoint is essentially a NIC (Network Interface Card) with a private IP from your subnet. This NIC is attached to a special resource called a Private Link Service that runs on the Azure backbone.
Here's the step-by-step mechanism:
Resource Creation: You create a Private Endpoint resource in the same region as the storage account. You specify the VNet, subnet, and the storage account resource. Azure then provisions a NIC in that subnet with a private IP from the subnet's range.
Private Link Connection: The private endpoint initiates a connection to the storage account's Private Link service. The storage account must approve this connection (or auto-approve if you have permissions). Once approved, the connection is established.
DNS Resolution: This is the most critical part. By default, Azure creates a Private DNS Zone (privatelink.blob.core.windows.net for Blob Storage) and links it to your VNet. DNS resolution for the storage account's FQDN (e.g., mystorageaccount.blob.core.windows.net) now resolves to the private IP of the endpoint instead of the public IP. This ensures that traffic from the VNet goes through the private endpoint.
Traffic Flow: When a VM in the VNet makes a request to the storage account's FQDN, the DNS returns the private IP. The packet is sent to that IP, which is the private endpoint NIC. The NIC forwards the traffic over the Microsoft backbone directly to the storage service. The storage service sees the source IP as the private IP of the VM (or the NAT IP if using a firewall).
Public Access Control: You can (and should) disable public network access on the storage account to force all traffic through private endpoints. This is done via the "Public network access" setting set to "Disabled".
Key Components, Values, Defaults, and Timers
- Private Endpoint: A resource with a NIC. The NIC gets an IP from the subnet. You can use a static or dynamic private IP. Default is dynamic.
- Private DNS Zone: Azure automatically creates and links a Private DNS Zone for each storage sub-resource (blob, file, table, queue, dfs). Zone names:
- privatelink.blob.core.windows.net
- privatelink.file.core.windows.net
- privatelink.table.core.windows.net
- privatelink.queue.core.windows.net
- privatelink.dfs.core.windows.net
- Connection Approval: The storage account owner must approve the private endpoint connection. Auto-approval is available if the user creating the endpoint has Microsoft.Storage/storageAccounts/privateEndpointConnectionsApproval/action permission.
- Network Policies: To use private endpoints, the subnet must have privateEndpointNetworkPolicies set to "Disabled" for Network Security Groups (NSGs) and Route Tables. This is because private endpoints are not directly subject to NSGs or UDRs—they are managed by Azure.
- Limits: Up to 200 private endpoints per storage account, and up to 50 per VNet per region.
- Pricing: Private endpoints have an hourly charge and a per-GB data processing charge. Check Azure pricing for current rates.
Configuration and Verification Commands
Using Azure CLI:
# Create a private endpoint for blob storage
az network private-endpoint create \
--name myPrivateEndpoint \
--resource-group myRG \
--vnet-name myVNet \
--subnet mySubnet \
--private-connection-resource-id /subscriptions/{subscription-id}/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount \
--group-id blob \
--connection-name myConnectionVerification:
# List private endpoints
az network private-endpoint list --resource-group myRG -o table
# Show details including private IP
az network private-endpoint show --name myPrivateEndpoint --resource-group myRG --query 'customDnsConfigs'
# Check DNS resolution from a VM
nslookup mystorageaccount.blob.core.windows.netFrom the Azure Portal, you can see the private endpoint under the storage account's "Networking" > "Private endpoint connections" blade.
Interaction with Related Technologies
Service Endpoints: Service endpoints provide access to Azure services over the Microsoft backbone but still use public IPs. Private endpoints use private IPs and are more secure. They can coexist, but exam questions often ask which to choose based on requirements.
Network Security Groups (NSGs): Private endpoints bypass NSGs on the subnet. You cannot filter traffic to/from a private endpoint using NSGs. Instead, use NSGs on the source/destination VMs or use Azure Firewall.
Azure Firewall: Can inspect traffic to private endpoints if you route traffic through the firewall (using forced tunneling). However, private endpoint traffic is not routable through a firewall unless you configure a specific route.
VPN Gateway / ExpressRoute: Private endpoints work seamlessly with on-premises connectivity. On-premises clients can access storage via private endpoints if DNS resolution is properly configured (e.g., using custom DNS servers that forward to Azure DNS).
Private Link: The underlying service that enables private endpoints. Private Link is a capability that exposes Azure PaaS services (and your own services) over a private connection.
Defaults and Timers
DNS Propagation: Changes to DNS zones take effect immediately within the VNet.
Connection State: Private endpoint connections have states: Pending, Approved, Rejected, Disconnected. You can manually approve or reject.
Deletion: Deleting a private endpoint does not delete the storage account; it only removes the private connection.
Exam-First Structure
The AZ-104 exam tests the following: - Objective 2.3: Configure Azure Files and Azure Blob Storage. This includes private endpoints. - Specific skills: Create and configure private endpoints, manage private DNS zones, and control public network access. - Scenario-based questions: Given a requirement for secure access from a VNet, choose between service endpoints and private endpoints. Or, troubleshoot DNS resolution issues.
Key trap: Candidates often confuse private endpoints with service endpoints. Remember: service endpoints use public IPs and require a route to Microsoft services; private endpoints use private IPs and require Private DNS Zones.
Another trap: Candidates think NSGs can filter private endpoint traffic. They cannot. The correct answer is to use NSGs on the VM's subnet.
Edge case: When using a custom DNS server on-premises, you must configure conditional forwarding to Azure's DNS (168.63.129.16) for the privatelink zones.
Conclusion
Private endpoints are a fundamental component of Azure's security architecture. They provide a secure, private connection to Azure Storage, eliminating exposure to the public internet. Understanding their mechanics—especially DNS resolution and the limitations with NSGs—is crucial for the AZ-104 exam and real-world deployments.
Create a Virtual Network and Subnet
First, ensure you have a VNet and subnet in the same region as your storage account. The subnet must have `privateEndpointNetworkPolicies` set to "Disabled" for NSGs and Route Tables. This is because private endpoints are not subject to subnet-level NSGs or UDRs—they are managed by Azure. You can set this using the Azure CLI: `az network vnet subnet update --name mySubnet --resource-group myRG --vnet-name myVNet --disable-private-endpoint-network-policies true`. Without this setting, the private endpoint creation will fail.
Create the Private Endpoint Resource
In the Azure Portal, navigate to "Private endpoints" and click "Create". Fill in the basics: name, region (same as storage account), resource group. On the "Resource" tab, select "Connect to an Azure resource" and choose your storage account. For "Target sub-resource", select the appropriate type: blob, file, table, queue, or dfs. This determines which FQDN the private endpoint will map to. On the "Configuration" tab, select your VNet and subnet. For "Private DNS integration", choose "Yes" to automatically create a Private DNS Zone and link it to your VNet. This is recommended for seamless DNS resolution.
Approve the Private Endpoint Connection
After creation, the private endpoint connection will be in "Pending" state. You must approve it from the storage account's side. Go to the storage account, under "Networking" > "Private endpoint connections", select the pending connection and click "Approve". If you have the necessary RBAC permissions, auto-approval can occur. Once approved, the connection state changes to "Approved". Traffic can now flow through the private endpoint. Verify by checking the private IP assigned to the endpoint from the private endpoint resource's overview page.
Configure Private DNS Zone
Azure automatically creates a Private DNS Zone named `privatelink.blob.core.windows.net` (for blob) and links it to your VNet. This zone contains an A record that maps the storage account's FQDN (e.g., `mystorageaccount.blob.core.windows.net`) to the private IP of the endpoint. If you chose not to integrate automatically, you must manually create the zone, add the A record, and link the zone to the VNet. Without proper DNS configuration, clients will resolve the public IP and bypass the private endpoint. Verify DNS resolution from a VM in the VNet using `nslookup`.
Disable Public Network Access
To force all traffic through the private endpoint, disable public network access on the storage account. In the storage account's "Networking" blade, set "Public network access" to "Disabled". This blocks all access from the public internet, including access via storage account keys over the internet. Only traffic from private endpoints or trusted Azure services (if you allow) will succeed. Note: If you disable public access, you must have at least one private endpoint approved; otherwise, you'll lose all connectivity. Test connectivity from a VM in the VNet using tools like `az storage blob list` or `Invoke-RestMethod`.
Enterprise Scenario 1: Financial Services Compliance
A bank must store customer transaction logs in Azure Blob Storage. Regulatory requirements (e.g., PCI DSS) mandate that data never traverses the public internet. The bank deploys a private endpoint for each storage account, connecting from a dedicated subnet in their hub VNet. They disable public network access and use Azure Policy to enforce private endpoints on all storage accounts. On-premises applications access the logs via ExpressRoute and a custom DNS server that forwards privatelink.blob.core.windows.net to Azure DNS. Misconfiguration: Initially, the DNS team forgot to add the conditional forwarder, causing on-premises clients to resolve the public IP and fail. They fixed it by adding a forwarder to 168.63.129.16.
Enterprise Scenario 2: Multi-Tier Application Isolation
A SaaS company runs a multi-tier application: web tier in a public subnet, application tier in a private subnet, and data tier using Azure Storage (blob and queue). They use private endpoints for blob and queue storage, each in separate subnets with NSGs restricting traffic between tiers. The web tier cannot directly access storage; only the app tier can. They use service endpoints for the web tier to access a public endpoint? No—they use private endpoints for all storage, and the app tier's NSG allows outbound to the private IPs. Performance is excellent because traffic stays within Azure's backbone. They monitor via Azure Monitor and set alerts for private endpoint connection drops.
Enterprise Scenario 3: Hybrid Cloud Backup
A company uses Azure Backup to back up on-premises file servers to Azure Files. They create a private endpoint for the storage account that hosts the file shares. The backup server on-premises connects via Site-to-Site VPN. They configure DNS on-premises to resolve the storage account's FQDN to the private IP. They also use a private endpoint for the Recovery Services vault? Not directly—but they use private endpoints for the storage account to ensure backup data never goes over the internet. Common issue: When the VPN tunnel drops, backups fail because the private IP is unreachable. They implement redundant VPN connections and use Azure Front Door? No—they use a second private endpoint in a different region for disaster recovery.
What Goes Wrong When Misconfigured
No Private DNS Zone: Clients resolve public IP, traffic goes over internet, security is lost.
Public Access Not Disabled: Storage account is still accessible over internet, defeating the purpose.
NSG Applied to Subnet with Private Endpoint: NSG rules are ignored for private endpoint traffic, causing confusion.
Custom DNS Server Without Forwarding: On-premises clients cannot resolve the private IP.
Private Endpoint in Wrong Region: Private endpoints must be in the same region as the storage account.
Scale and Performance
Private endpoints can handle high throughput—up to 100 Gbps per endpoint (theoretical). In practice, performance is limited by the VM's NIC and the storage account's limits. For high-volume scenarios, use multiple private endpoints (up to 200 per storage account). Each endpoint has its own NIC and private IP, distributing traffic. Latency is typically 1-2 ms within the same region. Cross-region private endpoints are not supported; you must use a different method (e.g., Azure File Sync).
What AZ-104 Tests on This Topic
The exam covers Private Endpoints for Azure Storage under Objective 2.3 (Configure Azure Files and Azure Blob Storage). Specific skills include:
Create and configure private endpoints for storage accounts.
Manage private DNS zones and DNS resolution.
Control public network access settings.
Differentiate between private endpoints and service endpoints.
Troubleshoot connectivity issues.
Common Wrong Answers and Why Candidates Choose Them
"Use a service endpoint instead of a private endpoint": Candidates choose this when the question asks for "private IP address" or "no public internet exposure". Service endpoints use public IPs, so they don't meet the requirement. The correct answer is private endpoint.
"Apply an NSG to the subnet containing the private endpoint to restrict traffic": Candidates think they can filter traffic to the private endpoint using NSGs. Reality: Private endpoints ignore subnet NSGs. You must apply NSGs to the source VMs or use Azure Firewall.
"Private endpoints require a VPN or ExpressRoute to work": Wrong. Private endpoints work within Azure without any VPN. They are for VNet-to-PaaS connectivity. On-premises access requires VPN/ExpressRoute, but VNet access does not.
"You must disable public network access before creating a private endpoint": Incorrect. You can create a private endpoint while public access is still enabled. In fact, if you disable public access first, you lose all connectivity until the private endpoint is approved. The correct order: create private endpoint, approve, then disable public access.
Specific Numbers, Values, and Terms That Appear Verbatim
Default DNS zone name: privatelink.blob.core.windows.net
Target sub-resource IDs: blob, file, table, queue, dfs
Connection states: Pending, Approved, Rejected, Disconnected
Limit: 200 private endpoints per storage account
Subnet policy: privateEndpointNetworkPolicies must be disabled
Azure DNS IP: 168.63.129.16
Edge Cases and Exceptions
Multiple sub-resources: You can create separate private endpoints for blob, file, table, queue, and dfs on the same storage account. Each has its own private IP.
Cross-region: Private endpoints must be in the same region as the storage account. You cannot create a private endpoint that connects to a storage account in another region.
Storage account with hierarchical namespace (Azure Data Lake Storage Gen2): Use dfs as the sub-resource.
Azure Files with AD authentication: Private endpoints work with identity-based authentication; no special configuration needed.
How to Eliminate Wrong Answers
If the question mentions "private IP address" or "no public internet", eliminate service endpoint options.
If the question asks about filtering traffic to storage, eliminate answers that suggest NSGs on the subnet with the private endpoint.
If the question involves on-premises connectivity, look for DNS forwarding or conditional forwarder configuration.
If the question says "all traffic must go through a firewall", consider Azure Firewall and forced tunneling, but remember that private endpoint traffic cannot be forced through a firewall by default.
Private endpoints assign a private IP from your VNet to Azure Storage, enabling secure access over the Microsoft backbone.
You must disable subnet network policies for private endpoints (privateEndpointNetworkPolicies).
Private DNS Zones (e.g., privatelink.blob.core.windows.net) are required for proper DNS resolution to the private IP.
NSGs on the subnet containing the private endpoint do not affect traffic to the private endpoint.
Public network access on the storage account should be disabled after the private endpoint is approved to enforce private connectivity.
Private endpoints must be in the same region as the storage account; cross-region is not supported.
Up to 200 private endpoints can be created per storage account, and up to 50 per VNet per region.
These come up on the exam all the time. Here's how to tell them apart.
Private Endpoint
Assigns a private IP from your VNet to the storage account.
Traffic never leaves the Microsoft backbone and uses private IPs.
Requires Private DNS Zone for DNS resolution.
Provides granular control over which specific storage account is accessed.
Supports on-premises access via VPN/ExpressRoute with proper DNS.
Service Endpoint
Uses public IPs of the Azure service; no private IP assigned.
Traffic stays on the Microsoft backbone but still uses public IPs.
No DNS changes needed; uses Azure's public DNS.
Allows access to all storage accounts of the same type in the region from the subnet.
On-premises access still goes over public internet unless VPN/ExpressRoute is used.
Mistake
Private endpoints are the same as service endpoints.
Correct
Private endpoints assign a private IP from your VNet to the storage account, while service endpoints use public IPs but route traffic over the Microsoft backbone. Private endpoints are more secure and provide private IP connectivity.
Mistake
You can control traffic to a private endpoint using Network Security Groups (NSGs) on the subnet.
Correct
Private endpoints ignore NSGs applied to the subnet. To restrict traffic, use NSGs on the source VMs or use Azure Firewall.
Mistake
Private endpoints require a VPN or ExpressRoute to function.
Correct
Private endpoints work within Azure VNets without any VPN. On-premises access requires VPN/ExpressRoute, but VNet-to-storage connectivity does not.
Mistake
You must disable public network access on the storage account before creating a private endpoint.
Correct
You can create a private endpoint while public access is still enabled. Disable public access only after the private endpoint is approved to avoid losing connectivity.
Mistake
Private endpoints can be used across Azure regions.
Correct
Private endpoints must be created in the same region as the storage account. Cross-region private endpoints are not supported.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Private endpoints must be created in the same region as the storage account. Cross-region private endpoints are not supported. If you need cross-region access, consider using service endpoints or other methods.
Yes, DNS resolution is critical. By default, Azure creates a Private DNS Zone linked to your VNet. If you use custom DNS servers, you must configure conditional forwarding to Azure DNS (168.63.129.16) for the privatelink zones. Without proper DNS, clients will resolve the public IP and bypass the private endpoint.
NSG rules applied to the subnet are ignored for traffic to/from private endpoints. Private endpoints are not subject to subnet NSGs. To restrict traffic, apply NSGs to the source VMs or use Azure Firewall.
A private endpoint assigns a private IP from your VNet to the storage account, making it accessible via private IP. A service endpoint uses public IPs but routes traffic over the Microsoft backbone. Private endpoints are more secure and provide private connectivity, while service endpoints are simpler but less secure.
After creating and approving the private endpoint, disable public network access on the storage account. This blocks all traffic from the public internet. Ensure you have at least one private endpoint approved before disabling public access to avoid losing connectivity.
Yes, you can create up to 200 private endpoints per storage account. This is useful for isolating access from different VNets or subnets, or for different sub-resources (blob, file, table, queue, dfs).
Yes. For Azure Files, use the 'file' sub-resource. For Azure Data Lake Storage Gen2 (hierarchical namespace), use the 'dfs' sub-resource. The configuration is similar to blob storage.
You've just covered Private Endpoints for Azure Storage — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?