This chapter covers Private Endpoints and Private Link design in Microsoft Azure, a critical topic for the AZ-305 exam, particularly under objective 4.2: Design a networking solution. You'll learn how these services enable private connectivity to Azure PaaS and your own services, eliminating internet exposure. Expect approximately 10-15% of exam questions to touch on private connectivity, with a strong emphasis on design decisions, security implications, and integration with other networking components like DNS and firewalls.
Jump to a section
Imagine a corporate campus with a public road (the internet) and a private internal road (your virtual network). Normally, to access a service in a secured building (Azure PaaS service like Storage or SQL), you'd have to drive out onto the public road, go through a tollbooth that checks your ID (firewall), then enter the building's public entrance. With Private Link, you build a private bridge directly from your internal road to a private entrance of that building. The bridge is a dedicated connection: your traffic never touches the public road. The building's address on the public road remains inaccessible from the public side—only traffic coming over the bridge can enter. In Azure, the private bridge is a Private Endpoint—a network interface with a private IP from your VNet. The building's service is configured with a Private Link service (for custom services) or a Private Endpoint connection (for PaaS). Traffic from your VNet to the service flows entirely over the Microsoft backbone, never traversing the internet. This eliminates exposure to internet-based threats and ensures traffic stays within your network boundary, similar to how a private bridge ensures only authorized vehicles from your campus can enter the building.
What Are Private Endpoints and Private Link?
Private Endpoint and Private Link are Azure services that provide private, secure connectivity to Azure PaaS services (like Azure Storage, SQL Database, Cosmos DB, etc.) and to your own services hosted in Azure or on-premises, without using public IP addresses or traversing the internet.
Private Endpoint: A network interface (NIC) attached to a subnet in your Azure Virtual Network (VNet). It has a private IP address from the subnet range. When you create a Private Endpoint for a PaaS service, traffic from your VNet to that service is routed through this NIC, staying within the Microsoft Azure backbone.
Private Link: The underlying technology that enables private connectivity. For PaaS services, you create a Private Endpoint in your VNet and connect it to the service. For your own services, you create a Private Link Service behind a Standard Load Balancer, and consumers create Private Endpoints in their VNets to connect.
Why Use Private Endpoints?
Security: Traffic never leaves the Microsoft network. No public IP exposure reduces the attack surface.
Compliance: Many regulations require data to stay within a private network. Private Endpoints help meet those requirements.
Performance: Traffic stays on the Azure backbone, which is faster and more reliable than the internet.
Simplified network architecture: No need for service endpoints, firewall rules, or NAT for PaaS access.
How Private Endpoints Work: The Mechanism
When you create a Private Endpoint for an Azure Storage account, the following happens:
A NIC is created in the specified subnet with a private IP from that subnet.
The Private Endpoint is associated with the storage account via a connection request. The storage account owner must approve the connection (auto-approval can be configured).
After approval, a Private DNS zone (privatelink.blob.core.windows.net) is automatically created and linked to the VNet (if you enable integration).
DNS resolution for the storage account FQDN (e.g., mystorageaccount.blob.core.windows.net) now resolves to the private IP of the Private Endpoint instead of the public IP.
Traffic from resources in the VNet (or connected networks) to the storage account flows via the Private Endpoint NIC.
Key Components and Defaults
Private Endpoint: Requires a subnet with no other resources (delegation not required). The subnet must have available IP addresses. The Private Endpoint NIC gets an IP from the subnet.
Private DNS Zone: Automatically created when you enable 'Integrate with private DNS zone' during creation. The zone name depends on the service:
- Storage Blob: privatelink.blob.core.windows.net - SQL Database: privatelink.database.windows.net - Cosmos DB: privatelink.documents.azure.com - Key Vault: privatelink.vaultcore.azure.net - AKS: privatelink.<region>.azmk8s.io - etc. - Connection Approval: Manual or automatic. For PaaS services, you can set auto-approval via Azure Policy or service-specific settings. - Network Policies: By default, Private Endpoints do not support Network Security Groups (NSGs) or User-Defined Routes (UDRs) on the subnet. However, you can enable network policies for Private Endpoints (private endpoint network policies) to allow NSG and UDR support (preview). - Limits: You can have up to 1000 Private Endpoints per VNet (soft limit). Each Private Endpoint can connect to one resource, but multiple Private Endpoints can connect to the same resource.
Configuration Steps (Azure CLI Example)
# Create a VNet and subnet
az network vnet create -g MyRG -n MyVNet --address-prefix 10.0.0.0/16 --subnet-name MySubnet --subnet-prefix 10.0.1.0/24
# Create a Private Endpoint for a storage account (existing storage account)
az network private-endpoint create -g MyRG -n MyPE --vnet-name MyVNet --subnet MySubnet --private-connection-resource-id /subscriptions/.../storageAccounts/mystorageaccount --group-id blob --connection-name MyConnection
# Create a Private DNS zone and link to VNet
az network private-dns zone create -g MyRG -n privatelink.blob.core.windows.net
az network private-dns link vnet create -g MyRG -n MyLink -z privatelink.blob.core.windows.net -v MyVNet -e false
# Create DNS A record
az network private-dns record-set a create -g MyRG -z privatelink.blob.core.windows.net -n mystorageaccount
az network private-dns record-set a add-record -g MyRG -z privatelink.blob.core.windows.net -n mystorageaccount -a <private-ip>Integration with Other Services
VPN Gateway / ExpressRoute: Traffic from on-premises to PaaS services via Private Endpoint flows over the private connection (VPN/ER) to the VNet, then via the Private Endpoint to the PaaS service. No internet egress.
Azure Firewall / NVA: You can route traffic through a firewall by using UDRs (if network policies are enabled) or by placing the Private Endpoint in a subnet that routes through the firewall.
Service Endpoints vs Private Endpoints: Service Endpoints provide private IP source but still use the public endpoint of the service. Private Endpoints provide a fully private IP for the service. Service Endpoints are simpler but less secure.
Azure DNS Private Resolver: Can resolve private DNS zones across VNets and on-premises.
Private Link Service (for Custom Services)
For your own services behind a Standard Load Balancer, you can expose them via Private Link Service. Consumers create Private Endpoints in their VNets and connect to your service. The traffic flows through the Microsoft backbone.
Create VNet and Subnet
First, you need a Virtual Network (VNet) with at least one subnet where the Private Endpoint will be placed. The subnet must have available IP addresses and cannot have any other resources like VMs or other Private Endpoints. The subnet size should be at least /28 to allow for multiple Private Endpoints. For high availability, consider at least two IPs per Private Endpoint (one for the NIC and one for future replacement).
Create the Private Endpoint
In the Azure portal, CLI, or PowerShell, create a Private Endpoint resource. Specify the resource group, name, and location (must match the VNet location). Choose the target sub-resource (e.g., blob for Storage, sqlServer for SQL). The connection request is sent to the target resource owner. If auto-approval is configured, the connection is approved automatically; otherwise, the owner must approve within a configurable timeout (default 7 days).
Configure Private DNS Zone
To ensure seamless name resolution, integrate with a Private DNS Zone. Azure can auto-create and link the zone to your VNet during creation. The zone name follows the pattern privatelink.<service>.azure.com. DNS records are automatically created for the FQDN. If you don't use auto-integration, you must manually create the zone, link it, and add A records. Without proper DNS, clients must use the private IP directly or custom DNS.
Approve the Connection (if manual)
If the target resource owner has not set auto-approval, they must approve the Private Endpoint connection. In the Azure portal, go to the target resource (e.g., Storage account), under 'Private endpoint connections', find the pending request and approve. The connection state changes from 'Pending' to 'Approved'. Once approved, traffic can flow. Rejected connections cannot be re-approved; you must create a new Private Endpoint.
Verify Connectivity
After approval and DNS configuration, test connectivity from a VM in the same VNet (or peered/connected VNet). Use tools like nslookup or Resolve-DnsName to confirm the FQDN resolves to the private IP. Then test actual connectivity (e.g., ping is blocked by default; use telnet for port 443 or HTTP requests). For Storage, use Azure Storage Explorer or PowerShell to list blobs. For SQL, connect via SSMS. If connectivity fails, check NSGs, route tables, and DNS resolution.
Scenario 1: Securing Azure SQL Database
A financial services company needs to connect their application VMs to an Azure SQL Database without exposing the database to the internet. They create a Private Endpoint for the SQL server in the same VNet as the application tier. After approval, DNS resolves the SQL FQDN to the private IP. The application connection strings remain unchanged. To meet compliance, they also enable 'Deny public network access' on the SQL server, ensuring no internet traffic can reach the database. They monitor the Private Endpoint connections for any unauthorized attempts. Performance is excellent as traffic stays on the Azure backbone. A common mistake is forgetting to update DNS on on-premises clients; they use Azure DNS Private Resolver to resolve the private zone.
Scenario 2: Exposing a Custom Microservice via Private Link Service
A SaaS provider hosts a microservice behind a Standard Load Balancer. They want to allow enterprise customers to connect privately. They create a Private Link Service associated with the load balancer. Customers create Private Endpoints in their own VNets and connect to the service. The provider approves connections. Traffic flows from the customer's VNet through the Microsoft backbone to the provider's VNet. The provider can see the source private IP in the request. They implement network policies to restrict which customers can connect. Scale considerations: each Private Link Service can have up to 1000 connections. They use Azure Monitor to track connection states and traffic.
Scenario 3: Hybrid Connectivity for Storage
A company with an ExpressRoute connection to Azure wants to migrate file shares to Azure Files. They create a Private Endpoint for the storage account in a hub VNet. On-premises servers resolve the storage FQDN to the private IP via DNS forwarding to Azure DNS Private Resolver. Traffic flows over ExpressRoute to the hub VNet, then via the Private Endpoint to the storage account. This eliminates the need for a public IP on the storage account. Misconfiguration: if the DNS zone is not linked to the hub VNet, on-premises clients resolve to the public IP and traffic attempts to go over the internet, potentially blocked by firewall rules. They ensure the private DNS zone is linked to all VNets that need access, and configure conditional forwarding in on-premises DNS.
The AZ-305 exam tests Private Endpoints and Private Link primarily under objective 4.2: Design a networking solution. Expect scenario-based questions where you must choose between Private Endpoint, Service Endpoint, or VPN/ExpressRoute for a given requirement. Key areas:
When to use Private Endpoint vs Service Endpoint: Service Endpoints are simpler but less secure because the service still has a public IP. Private Endpoints provide a fully private IP and can be used with on-premises via VPN/ER. The exam loves to ask: 'Which solution provides the most secure connectivity to Azure Storage?' – Answer: Private Endpoint.
DNS resolution: Questions often test understanding of private DNS zones. Common wrong answer: 'Clients use the public DNS name and it resolves to the private IP automatically.' Reality: You must configure private DNS zones. Without them, clients resolve to the public IP. Another trap: 'Private DNS zones are automatically linked to all VNets in the subscription.' Reality: Only the VNet you specify during creation is linked; you must link others manually.
Connection approval: The exam tests manual vs auto-approval. A scenario: 'You need to allow a specific VNet to connect to your storage account without manual intervention.' Answer: Configure auto-approval for that VNet's Private Endpoint. Wrong answer: 'Set the storage account to allow all connections.' That's not secure.
Network policies: A common trap: 'You can apply NSGs to the subnet of a Private Endpoint.' By default, NSGs are not supported. The exam may ask: 'How do you restrict traffic to a Private Endpoint?' Answer: Use NSGs on the subnet if you enable 'private endpoint network policies' (preview). Without that, you cannot filter traffic at the subnet level. Another method: Use Azure Firewall or NVA with UDRs.
Limits and quotas: The exam may test limits like 'Maximum Private Endpoints per VNet' (1000) or 'Maximum connections per Private Link Service' (1000). Know these numbers.
Edge cases:
Private Endpoints do not support Azure Table or Queue storage via the storage account's table/queue endpoint; you must use blob endpoint or other methods.
Private Endpoints are not supported for all PaaS services; check service-specific documentation.
When using Private Endpoint with Azure Key Vault, you must also configure firewall rules to allow access.
To eliminate wrong answers, always check if the solution keeps traffic on the Microsoft backbone (Private Endpoint/Private Link) vs using public internet (Service Endpoint still uses public endpoint). Also check DNS requirements: if the question mentions 'name resolution', think private DNS zones.
Private Endpoints provide a private IP to Azure PaaS services, eliminating internet exposure.
Private Link is the underlying technology enabling private connectivity for both PaaS and custom services.
You must configure Private DNS zones for seamless name resolution; otherwise, clients resolve to public IPs.
By default, NSGs and UDRs are not supported on subnets with Private Endpoints (enable network policies preview if needed).
Private Endpoints require approval from the target resource owner (auto-approval can be configured).
Maximum 1000 Private Endpoints per VNet, 1000 connections per Private Link Service.
Private Endpoints do not disable the public endpoint; you must explicitly deny public network access.
On-premises connectivity requires VPN/ExpressRoute plus DNS forwarding to resolve private zones.
Private Endpoints are not supported for all PaaS services; always verify service-specific support.
Use Private Endpoints over Service Endpoints when you need full private IP and no internet exposure.
These come up on the exam all the time. Here's how to tell them apart.
Private Endpoint
Provides a private IP address for the PaaS service in your VNet.
Traffic stays entirely on the Microsoft backbone.
Can be used with on-premises via VPN/ExpressRoute.
Requires Private DNS zone for name resolution.
Supports custom services via Private Link Service.
Service Endpoint
Does not assign a private IP; traffic uses the public endpoint of the service.
Traffic still traverses the Microsoft backbone but uses the service's public IP.
Cannot be used with on-premises without additional NAT/firewall.
No DNS changes needed; public DNS resolves normally.
Only supports Azure PaaS services, not custom services.
Mistake
Private Endpoints replace the need for VPN or ExpressRoute for on-premises connectivity.
Correct
Private Endpoints only provide private connectivity within Azure and to on-premises via VPN/ExpressRoute. They do not create a connection to on-premises; they require an existing private connection (VPN/ER) to route traffic from on-premises to the VNet where the Private Endpoint is located.
Mistake
Once a Private Endpoint is created, the public endpoint of the PaaS service is automatically disabled.
Correct
The public endpoint remains active by default. You must explicitly disable public network access on the resource (e.g., set 'Deny public network access' to 'Yes' on Storage or SQL) to ensure only private traffic is allowed.
Mistake
Private Endpoints support all Azure PaaS services equally.
Correct
Not all services support Private Endpoints. For example, Azure App Service (Web Apps) supports Private Endpoints, but some features like VNet integration may conflict. Always check the service's documentation for supported sub-resources.
Mistake
Private Endpoints automatically resolve DNS for all clients in the same subscription.
Correct
DNS resolution via Private DNS zones only works for clients in VNets that are linked to the zone. Other VNets or on-premises networks require additional DNS configuration (e.g., DNS forwarding or Azure DNS Private Resolver).
Mistake
You can use NSGs and UDRs on the subnet hosting a Private Endpoint without any additional configuration.
Correct
By default, network policies (NSGs and UDRs) are not supported on subnets with Private Endpoints. You must enable 'private endpoint network policies' (preview) to apply them. Even then, NSG rules only apply to traffic from the subnet to the Private Endpoint, not to the Private Endpoint itself.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but you need a VPN or ExpressRoute connection from on-premises to Azure. The traffic from on-premises routes to the VNet where the Private Endpoint is located, then via the Private Endpoint to the storage account. You also need DNS resolution to resolve the storage FQDN to the private IP. This can be done by using Azure DNS Private Resolver or by configuring conditional forwarding in your on-premises DNS to the Azure private DNS zone.
Private Link is the overall service that enables private connectivity to Azure services. A Private Endpoint is a specific resource that creates a network interface with a private IP in your VNet, connecting to a PaaS service or a Private Link Service. In short, Private Link is the technology, Private Endpoint is the implementation. On the exam, you'll see both terms; know that Private Endpoint is the component you deploy.
No, but it's recommended for security. By default, the public endpoint remains active. To ensure only private traffic reaches your service, you should disable public network access on the resource (e.g., set 'Deny public network access' to 'Yes' on Storage or SQL). This prevents any traffic from the internet, even if someone has the public endpoint URL.
By default, no. Network Security Groups (NSGs) are not supported on subnets with Private Endpoints. However, you can enable a preview feature called 'private endpoint network policies' that allows NSG and UDR support. Even then, NSG rules only apply to traffic from the subnet to the Private Endpoint, not to traffic from the Private Endpoint to the service. For inbound traffic filtering, consider using Azure Firewall or an NVA.
When you create a Private Endpoint and enable 'Integrate with private DNS zone', Azure automatically creates a Private DNS zone (e.g., privatelink.blob.core.windows.net) and links it to the VNet. It also creates an A record mapping the FQDN to the private IP. For clients in that VNet, DNS resolution for the storage account FQDN returns the private IP. For other VNets, you must link the private DNS zone to those VNets. For on-premises, you need DNS forwarding or Azure DNS Private Resolver.
Key limits: Up to 1000 Private Endpoints per VNet (soft limit, can be increased). Each Private Endpoint can connect to one resource. For Private Link Service, up to 1000 connections per service. Also, the subnet used for Private Endpoints must have at least a /28 address space to allow for growth. These limits are important for the exam.
Yes, Azure App Service supports Private Endpoints. However, there are considerations: you must use a Premium V2 or Premium V3 plan. Also, if you use VNet integration for your app, you may need additional configuration. Private Endpoints for App Service are typically used to secure inbound traffic to the app.
You've just covered Private Endpoints and Private Link Design — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?