Private Endpoints + Private Link: Locking Down PaaS
Taking Azure PaaS services off the public internet and into your VNets — Azure Private Endpoints for inbound access via private IP, Private Link Services for publishing your own services privately, and the DNS choreography that makes it all work.
Private Endpoints, in one module
Most Azure PaaS services — Storage, Key Vault, SQL, Cosmos, App Service, ACR — have public endpoints by default. An Azure Private Endpoint puts an instance of that service on a private IP inside your VNet. Combined with disabling the public endpoint, you make the service reachable only from your private networks.
Two SC-500 concepts:
- Private Endpoint (PE) — the consumer side. A NIC with a private IP in your VNet, connected to a specific PaaS resource (a specific storage account, a specific Key Vault). DNS resolves the public hostname to the private IP via a private DNS zone.
- Private Link Service (PLS) — the publisher side. Lets YOU expose your own service (an Azure Load Balancer fronting your VMs / your custom app) to consumers via Private Endpoints — without internet exposure.
Private Endpoint is the buyer; Private Link Service is the seller; both ride the Microsoft backbone.
Private Endpoint anatomy
A Private Endpoint object has:
- A target resource — the specific Azure resource (storage account, Key Vault, etc.) being privately exposed
- A sub-resource — for services that have multiple data planes (storage: blob/file/queue/table/web/dfs; SQL: sqlServer for DB, managedInstance for MI)
- A NIC with a private IP in a customer subnet
- An approval state — Pending, Approved, Rejected — controlling whether the PE is live
The PE is functionally a NIC-level reverse-NAT to the Azure backbone target.
DNS — the half-step that breaks deployments
For Private Endpoints to work, DNS resolution of the public hostname must return the private IP. Standard pattern:
- Create the private DNS zone matching the service (e.g.
privatelink.blob.core.windows.net). - Link the zone to the consumer VNet (and any peered VNets that need to resolve).
- The PE deployment auto-creates an A record in the zone for the resource’s hostname pointing to the PE’s private IP.
When this is missing, the consumer VNet resolves the hostname to the public IP and bypasses the PE — defeating the purpose. The SC-500 trap question pattern: “PE is created but traffic still goes to the public endpoint” → answer: missing or incorrect private DNS zone link.
Private Link Service (publisher side)
If your app is behind an internal Standard Load Balancer in YOUR VNet, you can publish it via a Private Link Service. Consumers (other Azure tenants, other VNets in your tenant) create Private Endpoints targeting your PLS, and connect privately over the backbone.
Approval workflow
When a consumer creates a PE targeting a PLS, the connection is Pending by default. The PLS owner:
- Manually Approves or Rejects the connection
- Or configures auto-approval by consumer subscription ID
Disconnection is bidirectional — either side can disconnect.
Service endpoints — the older sibling (briefly)
VNet Service endpoints (Microsoft.Storage, Microsoft.Sql, etc.) are the older mechanism — they route traffic from the subnet to the service over Microsoft’s network and let the service firewall allowlist the subnet. They’re simpler to set up but don’t give a private IP to the PaaS resource and don’t fully take the resource off the internet (the service’s public endpoint remains addressable from elsewhere). For SC-500, Private Endpoints are preferred over Service Endpoints for new deployments.
When Private Endpoint vs Service Endpoint
Private Endpoint is the modern default — service is given a private IP in your VNet, public access can be disabled, traffic stays on the backbone, full network isolation possible.
Service Endpoint is older — service stays on its public endpoint; traffic from your VNet routes over the backbone via the service endpoint; the service firewall can allowlist your subnet. Service still publicly addressable, but your VNet’s egress is on the backbone.
SC-500 prefers Private Endpoint in nearly every modern scenario. Service Endpoint shows up in ‘legacy compatibility’ or ‘cost-sensitive simple lockdown’ answers.
Scenario: Ravi locks down Maple Genomics’ data services
Ravi’s data plane uses Storage (blob, file), Key Vault, Cosmos DB, and Azure SQL. He wants all of it off the internet.
- Storage account — disable public network access; create PE for
blobandfilesub-resources in the data VNet; private DNS zoneprivatelink.blob.core.windows.net+privatelink.file.core.windows.netlinked to the VNet. - Key Vault — disable public access; PE in the same VNet;
privatelink.vaultcore.azure.netlinked. - Cosmos DB — disable public access; PE for
SqlAPI;privatelink.documents.azure.comlinked. - Azure SQL Managed Instance — disable public access; PE for
managedInstancesub-resource;privatelink.<dnssuffix>.database.windows.netlinked. - VNet peering — peer the data VNet with the app VNet so App Services (which have VNet integration) can reach the PEs.
- NSG outbound rules — restrict App Service outbound to the data VNet CIDR; deny
Internetoutbound by default for the application tier.
Result: every PaaS data service has zero public exposure; app talks to data over private IPs via private DNS; backbone-only traffic.
Key terms
Knowledge check
Esme at Northwind Bank disables public network access on the bank's Azure SQL Managed Instance and creates a Private Endpoint in the banking VNet. Applications in the VNet now report 'cannot connect — DNS resolution failure'. What's the most likely cause?
Ravi at Maple Genomics is building a SaaS product that needs to be reachable by customer Azure tenants privately — no public internet exposure to those customers. Which capability fits?
What’s next
Next module: Azure Firewall + Network Watcher — L4-L7 traffic inspection at the network boundary and effective security rule diagnostics.