Azure Private Endpoints let you access Azure PaaS services like Azure SQL Database or Azure Storage over a private IP address within your virtual network, rather than exposing them to the public internet.
Here’s a look at Azure Private Link and Private Endpoints in action, managing traffic for an Azure SQL Database.
Imagine you have an Azure SQL Database and a virtual machine (VM) in Azure. Normally, your VM would connect to the SQL Database via its public endpoint, which means traffic travels over the public internet, even within Azure’s network. This isn’t ideal for security and compliance.
// Azure SQL Database Public Endpoint Configuration
{
"properties": {
"publicNetworkAccess": "Enabled", // This is the default
"minimalTlsVersion": "1.2",
// ... other properties
}
}
Now, let’s secure this. We’ll create a Private Endpoint for the Azure SQL Database. This Private Endpoint will live inside your virtual network, getting a private IP address from your subnet.
When you create a Private Endpoint, Azure automatically creates a Private DNS Zone record for your SQL Database. This record maps the SQL Database’s FQDN (e.g., mydb.database.windows.net) to the private IP address of the Private Endpoint.
# Example of a Private Endpoint resource in Azure CLI
az network private-endpoint create \
--name mySqlPrivateEndpoint \
--resource-group myResourceGroup \
--vnet-name myVNet \
--subnet mySubnet \
--group-ids mySqlResourceId \
--private-connection-resource-id /subscriptions/YOUR_SUB_ID/resourceGroups/myResourceGroup/providers/Microsoft.Sql/servers/mydb \
--location eastus
Your VM, configured to use the Private DNS Zone, will now resolve mydb.database.windows.net to the private IP address of the Private Endpoint. The connection then flows directly from your VM’s subnet, through Azure’s backbone network, to the SQL Database’s private endpoint, never touching the public internet.
// Azure SQL Database Private Endpoint Connection
{
"properties": {
"privateIPAddress": "10.0.1.5", // IP from your VNet subnet
"privateLinkServiceConnectionState": {
"status": "Approved", // You need to approve this connection on the SQL server
"description": "Approved by Contributor",
"actionsRequired": "None"
},
// ... other properties
}
}
The core problem this solves is the security and compliance challenge of exposing PaaS services over the public internet. Private Endpoints allow you to enforce network isolation, ensuring that sensitive data only traverses your private network. It’s a fundamental building block for a zero-trust network architecture in Azure.
The Private Endpoint itself is a network interface (NIC) resource deployed in your VNet. It holds the private IP address. The magic happens with the Private Link Service on the PaaS side, which acts as the gateway for the private endpoint to connect to. When you create a private endpoint, you’re essentially requesting a connection to this Private Link Service.
When you connect from your VM to mydb.database.windows.net, the DNS resolution is key. If your VM’s DNS is configured to use Azure’s DNS (which is common when using Private DNS Zones), it will query the Private DNS Zone associated with the Private Endpoint. This zone contains a record mapping mydb.database.windows.net to the private IP (e.g., 10.0.1.5). This ensures your traffic is directed to the private IP.
If you disable publicNetworkAccess on the Azure SQL Database after setting up the Private Endpoint, the SQL Database will only accept connections from its Private Endpoint. All public access is blocked.
# Example of disabling public network access on Azure SQL Database
az sql server update \
--name mydb \
--resource-group myResourceGroup \
--public-network-access Disabled
The Private Endpoint connection status needs to be approved on the target Azure service. This is a manual step where you go to the SQL Server resource and approve the pending connection request from the Private Endpoint. Until approved, traffic won’t flow.
A common pitfall is forgetting to configure DNS correctly. If your VM’s DNS resolver doesn’t pick up the Private DNS Zone, it will continue to try and resolve the public IP of the SQL Database, and the private endpoint connection will fail. Ensure your VNet is linked to the Private DNS Zone.
The Private Endpoint essentially acts as a network address translator (NAT) for the PaaS service, but in a much more secure and integrated way than traditional NAT. It presents a private IP from your network to the service, and the service’s Private Link Service directs traffic to that private IP.
When you connect from your VM to the SQL Database, your client library (e.g., pyodbc, System.Data.SqlClient) makes a DNS lookup for mydb.database.windows.net. If your VNet’s DNS resolver is configured to use the Azure-provided DNS, and that DNS server has access to the Private DNS Zone linked to your VNet, it will return the private IP address of the Private Endpoint. This private IP address is within the address space of your VNet. The traffic then originates from your VM’s IP address and is routed by Azure’s internal network fabric to the Private Endpoint’s IP. The Private Link Service on the SQL Database side receives this traffic, identifies it as coming from an approved Private Endpoint, and forwards it to the actual SQL Database service. This entire process happens without the traffic ever traversing the public internet.
This mechanism allows you to consolidate network security controls. Instead of managing firewall rules for every PaaS service exposed to the internet, you can manage access at the VNet level, using Network Security Groups (NSGs) applied to the subnet where the Private Endpoint resides.
The next step in securing your Azure environment might involve exploring Private Link Service for custom applications or understanding how to manage multiple Private Endpoints for different services within a hub-spoke topology.