This chapter covers Azure Private Link and Private Endpoints, two critical services for securely connecting to Azure PaaS services and your own services over the Microsoft backbone network. For the AZ-900 exam, understanding these concepts is essential for the 'Azure Architecture and Services' domain (objective 2.3), which typically accounts for 15-20% of the exam questions. Private Link is a key security feature that distinguishes Azure's networking capabilities and frequently appears in scenario-based questions about secure data access.
Jump to a section
Imagine your company's headquarters has a secure internal network, and you need to access a specialized service in a shared office building across town—like a printing press that prints your confidential documents. Normally, to use that service, you'd have to send your documents over the public postal service, where anyone could potentially intercept them. With Azure Private Link, it's like digging a private, unmarked tunnel from your building directly to the printing press's loading dock. Your documents travel through this tunnel, never touching the public streets. The printing press is still in the shared building, but for you, it feels like it's in your own basement. You have a dedicated entrance (the private endpoint) that only your traffic uses. The tunnel is invisible to others, and no one else can use your entrance. This is exactly how Private Link works: it creates a private connection between your virtual network and a service (like Azure SQL Database or a third-party service) over the Microsoft backbone network, bypassing the public internet entirely. The private endpoint is like your dedicated door—it's a network interface with a private IP from your VNet, making the service appear as if it's part of your own network.
What Azure Private Link Is and the Business Problem It Solves
Azure Private Link enables you to access Azure PaaS Services (like Azure Storage, SQL Database, and Cosmos DB) and Azure-hosted customer/partner services over a private endpoint in your virtual network. The core business problem it solves is the need to eliminate exposure to the public internet while still consuming cloud services. Traditionally, when you connect to Azure SQL Database from a virtual machine, traffic traverses the internet even if both are in Azure (unless you use service endpoints, which still route over the Microsoft backbone but with some limitations). Private Link goes further: it creates a private endpoint—a network interface with a private IP from your VNet—that maps to a specific service instance. All traffic to that service stays within the Microsoft network, never touching the public internet. This is crucial for regulated industries like healthcare (HIPAA), finance (PCI DSS), and government where data must not traverse public networks.
How It Works — Step by Step
Create a Private Endpoint: You create a private endpoint resource in your VNet. This endpoint is a network interface (NIC) that gets a private IP from your subnet. You associate it with a specific Azure service (e.g., a storage account).
Configure the Service: On the service side (e.g., the storage account), you enable the Private Endpoint connection. The service then accepts or rejects the connection request.
DNS Resolution: Azure Private Link integrates with Azure Private DNS Zones. When you create a private endpoint, you can set up a private DNS zone (e.g., privatelink.blob.core.windows.net) that resolves the service's public FQDN to the private IP of the endpoint. Without this, clients would still resolve to the public IP.
Traffic Flow: When a VM in your VNet accesses the storage account via its public FQDN, DNS resolves to the private IP. Traffic flows through the private endpoint directly to the service over the Microsoft backbone. The service sees the traffic as coming from the private IP, not a public one.
Security: You can disable public internet access on the service side entirely, forcing all traffic through the private endpoint. This creates a complete private connection.
Key Components, Tiers, and Pricing
Private Endpoint: A network interface with a private IP from your VNet. It's the entry point for traffic to the service.
Private Link Service: Your own service (e.g., a web app running behind a Standard Load Balancer) that you can expose via Private Link to other VNets. This allows you to offer a service privately to customers.
Private DNS Zone: A DNS zone that maps the service's FQDN to the private IP. Azure recommends using private DNS zones for automatic resolution.
Pricing: Private Link charges for both inbound and outbound data processed through the private endpoint. There is no charge for the endpoint itself, but data transfer costs apply. For Private Link Service (your own service), there is an hourly charge plus data processing fees.
Comparison to On-Premises Equivalent
In an on-premises environment, connecting to a database server securely typically requires a dedicated leased line or VPN to a data center. Azure Private Link is analogous to having a direct, private circuit to a specific service. Unlike a VPN which tunnels all traffic, Private Link is service-specific—only traffic destined for that particular service uses the private link. This is more secure and simpler to manage than setting up site-to-site VPNs for every service.
Azure Portal and CLI Touchpoints
In the Azure portal, you can create a private endpoint under 'Create a resource' > 'Networking' > 'Private Endpoint'. You specify the name, subscription, resource group, location, VNet, subnet, and the target resource (e.g., a storage account). The portal also walks you through DNS integration. Using Azure CLI, you can create a private endpoint with:
az network private-endpoint create \
--name myPrivateEndpoint \
--resource-group myResourceGroup \
--vnet-name myVNet \
--subnet mySubnet \
--private-connection-resource-id /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/mystorageaccount \
--group-id blob \
--connection-name myConnectionTo create a Private DNS Zone and link it:
az network private-dns zone create \
--resource-group myResourceGroup \
--name privatelink.blob.core.windows.net
az network private-dns link vnet create \
--resource-group myResourceGroup \
--zone-name privatelink.blob.core.windows.net \
--name myLink \
--virtual-network myVNet \
--registration-enabled false
az network private-endpoint dns-zone-group create \
--resource-group myResourceGroup \
--endpoint-name myPrivateEndpoint \
--name myZoneGroup \
--private-dns-zone /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net \
--zone-name privatelink.blob.core.windows.netConcrete Business Scenarios
Scenario 1: Secure Data Lake Analytics A financial services company uses Azure Data Lake Storage Gen2 for sensitive transaction data. They have a Spark cluster in a VNet that processes this data. Without Private Link, the Spark cluster would access the storage over the internet (even within Azure, traffic goes through Microsoft backbone but with public endpoint). By creating a private endpoint for the storage account, all traffic stays within their VNet and the Microsoft network. They also disable public access on the storage account, ensuring no data leaks.
Scenario 2: Third-Party SaaS Integration A healthcare startup uses a third-party SaaS application hosted on Azure (e.g., an EHR system). The startup has patient data that must not traverse the internet per HIPAA. The SaaS provider exposes their service via Private Link Service. The startup creates a private endpoint in their VNet that connects to the SaaS service. Now, all data flows privately.
Scenario 3: Multi-Tier Application An e-commerce company has a web tier in a VNet and a backend SQL Database. They want to ensure that traffic between the web servers and the database never leaves the Azure network. They create a private endpoint for the SQL Database and configure the web servers to use the private IP. They also set firewall rules on the SQL Database to deny all public traffic.
What Goes Wrong When Set Up Incorrectly
DNS resolution fails: If you don't configure private DNS zones, clients will resolve the service's FQDN to its public IP. Traffic will either fail (if public access is disabled) or go over the internet (if public access is still enabled).
Connection rejected: The service owner must approve the private endpoint connection. If not approved, the endpoint remains in a 'Pending' state and traffic is blocked.
Network Security Groups (NSGs) not updated: Private endpoints do not support NSGs. Traffic to the private endpoint is governed by NSGs on the subnet, but the endpoint itself cannot have an NSG. Misunderstanding this can lead to security gaps.
Overlapping IP addresses: If your VNet uses IP ranges that conflict with the service's network, traffic may not route correctly. Azure Private Link requires non-overlapping IP spaces between the VNet and the service's backend.
Azure Portal and CLI Touchpoints (Continued)
In the Azure portal, you can also configure private endpoint connections on the service side (e.g., under 'Networking' > 'Private endpoint connections' for a storage account). You can approve or reject pending connections. The portal provides a status indicator: Approved, Pending, Rejected, or Disconnected.
For Azure CLI, to approve a private endpoint connection:
az network private-endpoint-connection approve \
--id /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/mystorageaccount/privateEndpointConnections/{connectionId} \
--description "Approved"To list all private endpoints in a subscription:
az network private-endpoint list --output tableUnderstanding these commands is not required for AZ-900, but knowing the portal experience is important for scenario questions.
Integration with Other Azure Services
Private Link works with many Azure services including:
Azure Storage (Blob, Queue, Table, File)
Azure SQL Database & SQL Managed Instance
Azure Cosmos DB
Azure Key Vault
Azure Kubernetes Service (AKS) API server
Azure App Service (Web Apps, Functions)
Azure Data Factory
Azure Cognitive Services
Azure AI Search
Azure Synapse Analytics
Azure Databricks
Third-party services via Private Link Service
Each service has specific configuration steps, but the core concept is the same: create a private endpoint in your VNet and connect it to the service.
Limits and Quotas
Maximum number of private endpoints per VNet: 1000 (default, can be increased by request)
Maximum number of private endpoints per subscription: 10000
Maximum number of private endpoints per resource: 50 (e.g., a storage account can have up to 50 private endpoints)
Private endpoint NICs are not assignable with NSGs; traffic is filtered at the subnet level.
Summary of Benefits
Security: Eliminates data exposure to the public internet.
Simplified network architecture: No need for VPNs or ExpressRoute to access PaaS services.
Compliance: Meets regulatory requirements for data privacy.
Global reach: Traffic stays on the Microsoft backbone, reducing latency and improving reliability.
Exam Tips
Remember that Private Link is about accessing services privately, not about publishing your own services (though Private Link Service does that too).
The key differentiator from Service Endpoints is that Private Endpoints give the service a private IP in your VNet, making it part of your network.
Private Link works across regions (but not across tenants without additional configuration).
For AZ-900, focus on the concept and benefits, not the detailed configuration steps.
Plan the Private Endpoint
Before creating a private endpoint, you need to identify the Azure service you want to connect to privately (e.g., a storage account, SQL database, or a third-party service via Private Link Service). Determine the target resource ID and the group ID (e.g., 'blob' for Azure Blob Storage, 'sqlServer' for Azure SQL Database). Also, choose the VNet and subnet where the private endpoint will be placed. The subnet must be in the same region as the private endpoint, but the target service can be in a different region. Ensure that the subnet does not have any service endpoints enabled for the same service (though it's possible, it's not recommended). Also, plan for DNS: you will need a private DNS zone to resolve the service's FQDN to the private IP. Azure provides built-in private DNS zones for each service (e.g., `privatelink.blob.core.windows.net`). You can use Azure-provided zones or create custom ones.
Create the Private Endpoint
In the Azure portal, navigate to 'Create a resource' > 'Networking' > 'Private Endpoint'. Fill in the basics: subscription, resource group, name, and region. Then, in the 'Resource' tab, select 'Connect to an Azure resource in my directory' and choose the target resource type and resource (e.g., storage account). The 'Resource type' dropdown filters to services that support Private Link. For the 'Target sub-resource', select the appropriate sub-resource (e.g., 'blob' for Blob Storage). In the 'Virtual Network' tab, select your VNet and subnet. Optionally, you can integrate with a private DNS zone. Azure can automatically create and link a private DNS zone for you. Review and create. Behind the scenes, Azure provisions a network interface in the subnet with a private IP and sends a connection request to the target resource.
Approve the Private Endpoint Connection
After creating the private endpoint, the connection to the target resource is in a 'Pending' state until the resource owner approves it. For Azure PaaS services you own, you can approve the connection through the Azure portal: go to the target resource (e.g., storage account), under 'Networking' > 'Private endpoint connections', find the pending connection and approve it. You can also auto-approve during creation if you have permissions. For third-party services, the service provider must approve. Once approved, the private endpoint becomes active and traffic can flow. The connection state changes to 'Approved'. If rejected, the private endpoint remains but cannot be used. You can also reject or remove connections.
Configure DNS Resolution
To ensure that clients in your VNet resolve the service's FQDN (e.g., `mystorageaccount.blob.core.windows.net`) to the private endpoint's IP, you need a private DNS zone. Azure can automatically create and link a private DNS zone during private endpoint creation if you select 'Yes' for 'Integrate with private DNS zone'. This creates a zone like `privatelink.blob.core.windows.net` and adds an A record mapping the storage account name to the private IP. If you choose not to integrate automatically, you must manually create the private DNS zone, link it to your VNet, and add the A record. Without proper DNS, clients will resolve to the public IP, which may fail if public access is disabled. Optionally, you can use custom DNS servers, but that adds complexity.
Restrict Public Access (Optional)
To fully secure the service, you can disable public network access on the target resource. For example, on the storage account, under 'Networking' > 'Firewalls and virtual networks', set 'Public network access' to 'Disabled'. This ensures that only traffic from private endpoints can reach the service. If you have multiple private endpoints, all approved connections can still access the service. However, be careful: if you disable public access before approving the private endpoint, you may lose access to the service from the portal or from other non-private endpoint sources. It's best to approve the private endpoint first, test connectivity, then disable public access. Also, note that some Azure services (like Azure SQL Database) have a 'Deny public network access' flag that can be set.
Business Scenario 1: Healthcare Compliance with HIPAA
A large hospital network migrates patient records to Azure SQL Database. They must ensure that no data traverses the public internet to comply with HIPAA. They deploy a VNet with a SQL Database private endpoint. All applications (web apps, APIs) are also in the same VNet or connected via VNet peering. They disable public access on the SQL Database. Now, all database traffic stays within the Microsoft network. They also use Azure Policy to enforce that all SQL Databases have private endpoints configured. The cost is manageable—data processing charges apply for the private endpoint, but they avoid the risk of data breaches. A common mistake: they initially forgot to configure the private DNS zone, causing the web app to resolve the database's public IP and fail to connect. After adding the DNS zone, connectivity worked.
Business Scenario 2: Secure Third-Party API Integration
A fintech startup uses a credit scoring API from a third-party provider that is hosted on Azure and exposed via Private Link Service. The startup has strict security requirements from their bank partners. They create a private endpoint in their VNet that connects to the third-party's Private Link Service. The third-party approves the connection. Now, all API calls go through the Microsoft backbone, never the internet. The startup also logs all traffic via NSG flow logs on the subnet. The cost includes the third-party's Private Link Service charges plus data processing. If the third-party accidentally rejects the connection, the startup sees a 'Pending' or 'Rejected' state and must contact support. The startup also learned that they cannot use a VPN gateway to route traffic to the private endpoint from on-premises unless they have proper DNS resolution set up.
Business Scenario 3: Multi-Region Data Replication
A global e-commerce company uses Azure Cosmos DB for its product catalog. They have VNets in multiple regions. They want to replicate data across regions securely. They create private endpoints for the Cosmos DB account in each VNet. However, they discover that private endpoints are regional—each endpoint connects to the same global Cosmos DB account, but traffic from each region goes to the nearest regional endpoint of the account. They also need to enable 'Allow access from Azure services' for the Cosmos DB account to allow replication traffic from other regions? Actually, with private endpoints, replication is handled internally by Azure; they just need to ensure that the private endpoints are approved. They also set up private DNS zones in each region with the same zone name, which is tricky because Azure Private DNS zones are global resources. They use a single private DNS zone for the entire enterprise and link all VNets to it. This works but can cause DNS resolution conflicts if the same FQDN resolves to different IPs in different regions. They solve this by using Azure Private Resolver or custom DNS servers. This scenario highlights the complexity of multi-region deployments.
Exam Objective: AZ-900 Objective 2.3 – Describe Azure architecture and services
Specifically, this falls under 'Describe core Azure services' and 'Describe Azure networking services'. The exam tests your understanding of what Private Link is, its benefits, and how it differs from similar services like Service Endpoints and VPN Gateway.
Common Wrong Answers and Why Candidates Choose Them
'Private Link is the same as a VPN Gateway.' Candidates confuse private connectivity with VPN. VPN Gateway connects entire networks (on-premises to Azure), while Private Link connects to specific services. The key distinction: VPN is site-to-site, Private Link is service-specific.
'Private Link requires ExpressRoute.' No, Private Link works over the internet (Microsoft backbone) and does not require ExpressRoute. ExpressRoute is a dedicated private connection to Azure, but Private Link can ride over that connection or over the internet. Candidates see 'private' and assume it needs ExpressRoute.
'Private Endpoints provide a public IP address.' Actually, a private endpoint is assigned a private IP from your VNet. It does not have a public IP. Candidates may think it's like a public endpoint but with restrictions.
'Private Link encrypts data at rest.' Private Link is about network connectivity, not encryption. Data in transit is encrypted by the underlying protocol (e.g., TLS for HTTPS), but Private Link itself does not add encryption. Candidates mix up network security with data encryption.
Specific Terms and Values That Appear Verbatim
'Private Endpoint' – a network interface with a private IP from your VNet.
'Private Link Service' – your own service exposed via Private Link.
'Microsoft backbone network' – the network traffic traverses.
'privatelink.blob.core.windows.net' – example private DNS zone.
'Approved', 'Pending', 'Rejected', 'Disconnected' – connection states.
Edge Cases and Tricky Distinctions
Service Endpoints vs Private Endpoints: Service Endpoints provide a direct route to Azure services over the Microsoft backbone but the service still has a public IP. Private Endpoints give the service a private IP in your VNet. The exam may ask which one makes the service part of your VNet (Private Endpoint).
Cross-region Private Link: Private endpoints can connect to services in different regions, but there may be additional latency and data transfer costs. The exam might ask if Private Link works across regions (yes).
Private Link and On-Premises: To access a private endpoint from on-premises, you need a VPN or ExpressRoute connection to Azure. The private endpoint is only reachable from within the VNet or connected networks.
Memory Trick or Decision Tree
Decision Tree for Connectivity Questions: - Need to connect entire networks (on-prem to Azure)? → VPN Gateway or ExpressRoute. - Need to connect specific Azure services privately? → Private Link. - Need to connect specific Azure services but okay with public IP? → Service Endpoints (older, less secure). - Need to connect your own service to customers privately? → Private Link Service.
Memory Trick: 'Private Link = Private IP for Azure services.' Think of the 'P' in Private Link and 'P' in Private IP. If a question mentions 'private IP in your VNet', it's Private Link.
Exam Tips
Know that Private Link is not a global service; it's regional. The private endpoint is in a region, but the target service can be in another region.
Understand that Private Link is not a replacement for VPN/ExpressRoute; it complements them.
Be aware that Private Link supports both inbound and outbound connections? Actually, Private Endpoint is for inbound connections to a service from your VNet. Private Link Service is for outbound from your service to consumers. The exam may ask about direction.
Remember that Azure Private Link is the overall capability, and Private Endpoint is the resource you create.
Sample Question Style
'Which Azure feature allows you to access Azure SQL Database using a private IP address from your virtual network?' Answer: Private Link (or Private Endpoint). 'Which of the following is a benefit of Azure Private Link?' Options may include: reduced latency, elimination of public internet exposure, lower cost, etc. The correct answer is elimination of public internet exposure. 'True or False: Azure Private Link requires an ExpressRoute circuit.' False.
Azure Private Link enables private connectivity to Azure PaaS services via private endpoints, which are assigned private IPs from your VNet.
Private Link eliminates exposure to the public internet, enhancing security and compliance.
Private Endpoints are network interfaces in your VNet that map to a specific service instance.
Private Link supports Azure services (Storage, SQL, Cosmos DB, etc.) and third-party services via Private Link Service.
You must configure private DNS zones to resolve the service's FQDN to the private IP.
Private Endpoint connections go through states: Pending, Approved, Rejected, Disconnected.
Private Link does not require ExpressRoute or VPN; it works over the Microsoft backbone.
Private Link is not a global service; endpoints are regional but can connect to services in other regions.
These come up on the exam all the time. Here's how to tell them apart.
Azure Private Link (Private Endpoint)
Assigns a private IP from your VNet to the service, making it part of your network.
Traffic to the service stays on the Microsoft backbone and never goes to the public internet.
Supports access from on-premises via VPN/ExpressRoute.
Can be used across regions (endpoint in one region, service in another).
More granular control: you can disable public access entirely.
Azure Service Endpoints
Provides a direct route to the service over Microsoft backbone but the service still uses a public IP.
Traffic still uses the service's public endpoint; the service is not assigned a private IP.
Access from on-premises is not supported (only from VNet).
Works only within the same region (service in same region as VNet).
Less secure: public endpoint is still exposed; you can restrict via firewall rules.
Mistake
Private Link is the same as a VPN Gateway.
Correct
Private Link provides private connectivity to a specific Azure service via a private endpoint in your VNet. A VPN Gateway connects your entire on-premises network to an Azure VNet. They serve different purposes: Private Link is service-specific, VPN is network-wide.
Mistake
Private Link requires ExpressRoute to work.
Correct
Private Link works over the Microsoft backbone network and does not require ExpressRoute. It can be used with or without ExpressRoute. ExpressRoute is a dedicated private connection, but Private Link can also use the internet (still within Microsoft network) to route traffic.
Mistake
Private Endpoints have a public IP address.
Correct
A private endpoint is assigned a private IP address from your VNet subnet. It does not have a public IP. The service's public endpoint still exists (unless disabled), but the private endpoint uses a private IP.
Mistake
Private Link encrypts data at rest.
Correct
Private Link is a networking service that provides private connectivity. It does not encrypt data at rest. Data at rest is encrypted by the storage or database service itself (e.g., Azure Storage encryption). Data in transit may be encrypted by the application protocol (e.g., TLS), but Private Link does not add encryption.
Mistake
Private Link can only be used with Microsoft services.
Correct
Private Link can also be used with third-party services that are deployed on Azure and exposed via Private Link Service. You can also use Private Link to connect to your own services hosted on Azure.
Azure Private Link provides private connectivity to specific Azure services (like SQL Database or Storage) by creating a private endpoint in your VNet. It is service-specific. A VPN Gateway connects your entire on-premises network to an Azure VNet, allowing all traffic between the two networks. Private Link is not a replacement for VPN; they serve different purposes. For example, if you need to access Azure SQL Database privately from a VM in your VNet, you use Private Link. If you need to connect your entire office network to Azure, you use VPN Gateway.
Yes, you can create a private endpoint in one region and connect it to a service in another region. However, data transfer charges will apply for cross-region traffic. The private endpoint is regional, but the target service can be in any region. Also, DNS resolution must be configured appropriately. This is useful for multi-region architectures where you want to centralize services but access them from various VNets.
Yes, but you need a VPN Gateway or ExpressRoute connection between your on-premises network and Azure. Once connected, traffic from on-premises can reach the private endpoint through the VPN/ExpressRoute, provided DNS resolves the service's FQDN to the private IP. Without such a connection, on-premises clients cannot access private endpoints because private endpoints are only reachable from within the VNet or peered networks.
If you disable public network access before the private endpoint connection is approved, you may lose all access to the service, including from the Azure portal. The private endpoint connection will still be in a 'Pending' state and cannot be used until approved. To avoid this, always approve the private endpoint connection first, test connectivity, and then disable public access. Some services allow you to enable 'Allow trusted Microsoft services' to maintain portal access.
Yes, Azure App Service (Web Apps, Functions, etc.) supports Private Link. You create a private endpoint in your VNet and connect it to the App Service. This makes the App Service accessible via a private IP. You can also disable public access to the App Service, forcing all traffic through the private endpoint. This is common for internal applications that should not be exposed to the internet.
There is no charge for the private endpoint resource itself. You pay for data processed through the private endpoint: inbound and outbound data transfer. For Private Link Service (your own service), there is an hourly charge plus data processing fees. Pricing varies by region. You can find detailed pricing on the Azure Pricing Calculator. For AZ-900, you don't need to memorize costs, but understand that data processing incurs charges.
Azure recommends using Azure Private DNS Zones. When you create a private endpoint, you can integrate with a private DNS zone (e.g., `privatelink.blob.core.windows.net`). Azure automatically creates an A record mapping the service's FQDN to the private IP. You must also link the private DNS zone to your VNet. Alternatively, you can use custom DNS servers, but that requires manual configuration. Without proper DNS, clients will resolve to the public IP and connectivity may fail.
You've just covered Azure Private Link and Private Endpoints — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?