6.1 Private Connectivity with Private Endpoints & Private Link

Key Takeaways

  • Private Endpoints project a network interface (NIC) with a private IP from a VNet subnet to establish dedicated, private connectivity to Azure PaaS services or custom Private Link Services.
  • Unlike Service Endpoints (which maintain public IP addressing and route over Azure backbone), Private Endpoints completely eliminate public IP exposure and secure traffic against data exfiltration.
  • Private DNS Zones auto-register and resolve FQDNs (e.g., privatelink.blob.core.windows.net) to private IPs, requiring central DNS forwarders or Azure Private DNS Resolvers in hub-spoke topologies.
  • Disabling public network access on Azure Storage, Azure SQL, and Azure Key Vault blocks all internet access, forcing all client traffic through Private Endpoints.
  • Private Link Service enables service providers to securely publish custom services hosted behind an Azure Standard Load Balancer to consumers in other tenants via Private Endpoints.
Last updated: August 2026

5.1 Private Connectivity with Private Endpoints & Private Link

Traditional cloud architecture connected Virtual Networks (VNets) to Azure Platform as a Service (PaaS) resources using public IP endpoints over the Microsoft backbone network. However, enterprise security standards and regulatory compliance frameworks demand that PaaS resources—such as databases, key vaults, and storage accounts—be isolated from the public internet entirely. Azure Private Link and Azure Private Endpoints deliver private, dedicated connectivity by anchoring PaaS services directly inside your private Virtual Network IP address space.


Azure Private Endpoints Architecture & Mechanics

An Azure Private Endpoint is a special Network Interface (NIC) deployed within a specific Virtual Network subnet. It is assigned a private IP address from your subnet's CIDR block. When a client initiates a connection to a PaaS service bound to a Private Endpoint, traffic travels exclusively over the Microsoft private backbone network directly to the targeted PaaS resource instance.

+---------------------------------------------------------------------------------------------------------+
|                                 AZURE PRIVATE ENDPOINT ARCHITECTURE                                     |
|                                                                                                         |
|  +-------------------------------------+                      +---------------------------------------+  |
|  |      Virtual Network (10.1.0.0/16)  |                      |      Azure PaaS / Custom Service      |  |
|  |                                     |                      |                                       |  |
|  |  +-------------------------------+  |   Private Backbone   |  +---------------------------------+  |  |
|  |  | Subnet (10.1.1.0/24)        |  |======================|  | Storage / Key Vault / Azure SQL |  |  |
|  |  |                               |  |    Traffic Vector    |  |                                 |  |  |
|  |  |  Client VM (10.1.1.4)        |  |                      |  | Target Resource Instance        |  |  |
|  |  |             |                 |  |                      |  | (Public Access Disabled)        |  |  |
|  |  |             v                 |  |                      |  +---------------------------------+  |  |
|  |  | Private Endpoint NIC          |  |                      |                                       |  |
|  |  | (10.1.1.10 - privatelink)   |--|--------------------->|  Subresource: blob, vault, sqlServer  |  |
|  |  +-------------------------------+  |                      +---------------------------------------+  |  |
|  +-------------------------------------+                                                                |
+---------------------------------------------------------------------------------------------------------+

Core Structural Components of Private Endpoints

  • Target Resource & Subresource: A single Azure PaaS service exposes multiple distinct subresources. For instance, Azure Storage offers separate subresources for blob, file, table, queue, and web. Each subresource requires its own distinct Private Endpoint connection.
  • Private IP Allocation: The Private Endpoint consumes one private IP address from the assigned subnet for each connected subresource.
  • Subnet Policy Settings: Historically, Network Security Groups (NSGs) and User Defined Routes (UDRs) were bypassed by Private Endpoints. In modern Azure networking, you can enable network policies on the subnet (PrivateEndpointNetworkPolicies = Enabled) to enforce NSG security rules and route traffic through central firewalls.
  • Approval Workflow: Private Endpoints support explicit access control workflows. If a consumer creates a Private Endpoint targeting a PaaS resource in a different subscription or tenant, the resource owner must manually approve the connection request before traffic flows.

Private Link Service: Publishing Custom Services

While Private Endpoints connect consumers to Azure PaaS offerings, Azure Private Link Service allows service providers (or internal enterprise IT platform teams) to publish custom services hosted behind an Azure Standard Load Balancer privately to external consumers.

Publishing Architecture for Custom Services

  1. Standard Load Balancer (SLB): The provider hosts their application workload on virtual machines or Virtual Machine Scale Sets behind an internal Azure Standard Load Balancer.
  2. NAT IP Configuration: The Private Link Service attaches to the SLB frontend IP and is configured with a NAT IP pool allocated from a dedicated subnet in the provider's VNet.
  3. Consumer Private Endpoint Connection: The consumer creates a Private Endpoint in their own VNet using the provider's Private Link Service Alias or Resource ID.
  4. Unidirectional Access & TCP Proxy Protocol: Traffic flows unidirectionally from consumer to provider. The provider can enable Proxy Protocol v2 to preserve the source consumer IP address header across the NAT translation boundary.

Private Endpoints vs. Service Endpoints

A central topic on the AZ-500 exam is distinguishing between Azure Service Endpoints and Azure Private Endpoints. Both mechanisms secure PaaS connectivity, but their underlying network topologies, routing behaviors, and security scopes differ fundamentally.

Comprehensive Architectural Comparison

Architectural FeatureAzure Service EndpointsAzure Private Endpoints (Private Link)
IP Address ModelRetains the PaaS resource's public IP address.Replaces public IP access with a private IP address from your VNet.
Traffic Routing VectorRoutes traffic over Microsoft backbone; optimizes virtual network route table.Encapsulates traffic into private network interface (NIC) inside your subnet.
Public Network AccessRequires the PaaS service to maintain a public endpoint with firewall restrictions.Allows public network access to be completely disabled (Disabled).
Data Exfiltration ProtectionWeak by default. An attacker with compromised credentials inside the VNet can send data to any public account of that service type unless Service Endpoint Policies are applied.Strong by design. The Private Endpoint binds exclusively to a specific resource instance (e.g., mystorageaccount1), preventing exfiltration to unauthorized accounts.
On-Premises ConnectivityRequires complex Public Peering or ExpressRoute NAT to reach PaaS services from on-premises networks.Fully accessible over Site-to-Site VPN and ExpressRoute Private Peering directly via private IP address.
Cross-Tenant & Cross-RegionBound to the VNet and Azure region.Supports cross-region and cross-tenant private connections via Private Link approval workflows.
Network Security Group (NSG) SupportSupported on the source subnet.Supported when PrivateEndpointNetworkPolicies is set to Enabled on the subnet.
Cost StructureFree of charge (no hourly endpoint cost or data processing charges).Charged an hourly endpoint fee plus per-gigabyte inbound and outbound data processing fees.

Private DNS Zone Integration & Canonical Resolution

For Private Endpoints to function seamlessly, client applications must resolve the fully qualified domain name (FQDN) of the target PaaS resource to its assigned private IP address rather than its default public IP address. Microsoft achieves this using standard DNS Canonical Name (CNAME) redirection paired with Azure Private DNS Zones.

Default Public DNS Resolution Flow:
  mystorage.blob.core.windows.net  ==>  [Public IP: 20.60.100.45]

Private Link Redirection DNS Flow:
  mystorage.blob.core.windows.net  
     ==> CNAME: mystorage.privatelink.blob.core.windows.net
     ==> Private DNS Zone Lookup  ==>  [Private IP: 10.1.1.10]

Standard Private DNS Zone Names for Azure Services

Every Azure service that supports Private Link utilizes a standardized Private DNS Zone naming schema. AZ-500 candidates must recognize these key zone zones:

  • Azure Blob Storage: privatelink.blob.core.windows.net
  • Azure SQL Database: privatelink.database.windows.net
  • Azure Key Vault: privatelink.vaultcore.azure.net
  • Azure Cosmos DB (SQL API): privatelink.documents.azure.com
  • Azure Container Registry: privatelink.azurecr.io
  • Azure App Service (Inbound): privatelink.azurewebsites.net
  • Azure Service Bus: privatelink.servicebus.windows.net

Central Hub DNS Resolution Patterns

In enterprise hub-and-spoke virtual network topologies, managing DNS resolution across hundreds of spoke VNets and on-premises datacenters requires a centralized DNS resolution pattern.

+---------------------------------------------------------------------------------------------------+
|                                 CENTRAL HUB DNS RESOLUTION PATTERN                                |
|                                                                                                   |
|  +---------------------------------------------------------------------------------------------+  |
|  |                                  Hub Virtual Network (10.0.0.0/16)                         |  |
|  |                                                                                             |  |
|  |   +---------------------------------------+     +----------------------------------------+  |  |
|  |   | Azure Private DNS Resolver            |     | Azure Private DNS Zone                 |  |  |
|  |   | - Inbound Endpoint: 10.0.1.4 (Inbound) |====>| - privatelink.blob.core.windows.net   |  |  |
|  |   | - Outbound Endpoint: 10.0.2.4         |     | - Link: Hub VNet & Spoke VNets         |  |  |
|  |   +---------------------------------------+     +----------------------------------------+  |  |
|  +---------------------------------------------------------------------------------------------+  |
|                                          ^                                                        |
|                     DNS Queries (53)     | Forwarding Rule                                        |
|         +--------------------------------+--------------------------------+                       |
|         |                                                                 |                       |
|  +---------------------------------------+     +---------------------------------------+          |
|  | Spoke VNet A (10.1.0.0/16)           |     | On-Premises Datacenter (192.168.0.0)  |          |
|  | Custom DNS: 10.0.1.4                 |     | On-Prem DNS Server Forwarder          |          |
|  | Client VM -> Query PaaS FQDN         |     | Conditional Forwarder -> 10.0.1.4     |          |
|  +---------------------------------------+     +---------------------------------------+          |
+---------------------------------------------------------------------------------------------------+

Implementing Azure Private DNS Resolver

  1. Central Private DNS Zones: Create Private DNS Zones (e.g., privatelink.blob.core.windows.net) in the central Hub subscription and link them to the Hub VNet.
  2. Deploy Azure Private DNS Resolver: Replace legacy IaaS DNS virtual machines with the fully managed Azure Private DNS Resolver deployed in the Hub VNet.
  3. Inbound Endpoint Setup: Assign an Inbound Endpoint private IP (e.g., 10.0.1.4) to receive DNS queries over UDP/TCP port 53 from on-premises DNS servers and spoke VNets.
  4. On-Premises Conditional Forwarders: Configure on-premises Active Directory DNS servers with conditional forwarders targeting the Azure service domains (*.blob.core.windows.net, *.database.windows.net) pointing to the Inbound Endpoint IP (10.0.1.4).
  5. Spoke VNet DNS Configuration: Set the VNet DNS server settings on spoke VNets to point directly to the Hub Inbound Endpoint IP or rely on Hub VNet Peering links with Auto-Registration enabled.

Disabling Public Network Access on PaaS Resources

Deploying a Private Endpoint does not automatically block public internet access to a PaaS resource. To enforce Zero Trust security, administrators must explicitly disable public network access in the resource firewall configuration.

Enforcing Complete Public Access Restriction

To lock down resources, set publicNetworkAccess = Disabled via Azure Portal, ARM/Bicep template, Azure CLI, or Azure Policy:

# Disable public network access on an Azure Storage Account via Azure CLI
az storage account update \
  --name mystorageaccount123 \
  --resource-group rg-secure-networking \
  --public-network-access Disabled

# Disable public network access on an Azure SQL Logical Server
az sql server update \
  --name mysqlserver123 \
  --resource-group rg-secure-networking \
  --public-network-access Disabled

# Disable public network access on an Azure Key Vault
az keyvault update \
  --name mykeyvault123 \
  --resource-group rg-secure-networking \
  --public-network-access Disabled

Once publicNetworkAccess is set to Disabled, all connection requests attempting to reach the resource via its public IP address are rejected with HTTP 403 Forbidden errors, ensuring that only authenticated, private traffic arriving through approved Private Endpoints can access sensitive enterprise data.

Loading diagram...
Hub-and-Spoke Private Endpoint & DNS Resolution Topology
Test Your Knowledge

An enterprise requires all traffic between Virtual Networks and Azure SQL Database to be protected against data exfiltration. If an attacker compromises VM credentials in the VNet, they must not be able to exfiltrate data to an unauthorized external Azure SQL database of their own. Which networking mechanism satisfies this requirement?

A
B
C
D
Test Your Knowledge

When configuring an Azure Private Endpoint for an Azure Storage Account blob subresource, what is the correct Private DNS Zone name required for auto-registration and canonical name redirection?

A
B
C
D
Test Your Knowledge

A network security engineer needs to enable on-premises corporate workstations to resolve Azure Private Endpoint FQDNs across an ExpressRoute connection. What is the recommended architectural solution?

A
B
C
D