8.2 Private Endpoints and Private Link
Key Takeaways
- A private endpoint is a NIC with a private IP in your VNet that maps to a Private Link–enabled resource, keeping traffic on the Microsoft backbone instead of the public internet.
- Azure Private Link service lets you publish your own apps (behind a Standard Load Balancer) so consumers attach private endpoints—one service can accept many endpoints.
- Creating a private endpoint does not automatically disable public access; set public network access to Disabled (or equivalent) for true private-only PaaS exposure.
- Correct private DNS (privatelink.* zones linked to consuming VNets) is mandatory so service FQDNs resolve to private endpoint IPs rather than public VIPs.
- Service endpoints restrict source subnets to a still-public service endpoint path; private endpoints provide private IPs and stronger isolation for hybrid and zero-public designs.
Private Connectivity for Azure PaaS on SC-500
Blueprint skills: Configure Azure private endpoints to secure access to Azure platform as a service (PaaS) resources and Configure Azure Private Link services to secure access to network resources. This is the primary pattern for keeping sensitive PaaS (Storage, SQL, Key Vault, Cosmos DB, ACR, and many more) off the public internet while clients in virtual networks—and connected on-premises networks—still use private IPs on the Microsoft backbone.
Understand three related terms:
| Term | What it is |
|---|---|
| Azure Private Link | The platform capability that delivers private connectivity to Azure PaaS (and customer/partner services) over the Microsoft backbone without traversing the public internet |
| Private endpoint | A network interface in your virtual network with a private IP that maps to a specific private-link resource (for example, a storage blob sub-resource or a SQL server) |
| Private Link service | A provider-side construct you create so consumers can attach private endpoints to your service (typically fronted by a Standard Load Balancer) |
Private Link does not store customer data; it privately routes traffic. Creating a private endpoint does not by itself disable public access—you still configure the PaaS resource’s public network access / firewall settings for defense in depth.
Private Endpoints: NIC in Your VNet
A private endpoint places a read-only NIC in a subnet you choose. Azure assigns a private IP from that subnet for the life of the endpoint. That IP is the private “front door” clients use instead of the service’s public VIP.
Deployment constraints (exam-ready)
- Deploy the private endpoint in the same region and subscription as the virtual network.
- The private-link resource (PaaS) may live in a different region than the endpoint/VNet.
- Multiple private endpoints can target the same resource (for multi-region clients or isolation). For a shared DNS environment, prefer one endpoint per resource to avoid DNS conflicts.
- Private endpoints can sit in different subnets of the same VNet; subscription limits apply.
- Many PaaS services expose sub-resources (Storage:
blob,file,queue,table,dfs,web; Key Vault; SQL; etc.). You often need an endpoint per sub-resource your apps use.
Approval model
When you create a private endpoint to a resource you do not own (or cross-subscription designs), the connection may require manual approval by the resource owner unless the consumer subscription is allow-listed for auto-approval. SC-500 scenarios may mention “pending private endpoint connection” as an access blocker.
Hardening pattern
- Create private endpoints for required sub-resources.
- Integrate private DNS so service FQDNs resolve to private IPs.
- Set PaaS public network access to Disabled (or equivalent deny).
- Keep authorization (Entra RBAC, keys if still enabled, firewall exceptions for trusted services when still needed).
- Test from spoke VNets, on-premises via ExpressRoute/VPN, and negative tests from the internet.
Exam trap: Private endpoint ≠ automatic public lock-down. Disabling public access is a separate configuration on most services.
Private Link Service for Custom Services
Azure Private Link service lets you expose your own application privately to consumers (other VNets, other tenants, partners) without putting the app on a public IP.
Core model
- Deploy your app behind a Standard Load Balancer (Basic LB is not supported for Private Link service).
- Create a Private Link service attached to the LB frontend in the same region as the VNet/LB.
- Consumers create private endpoints that connect to your Private Link service.
- Traffic stays on Microsoft backbone; consumers never need your VNet peering for simple private consumption patterns (subject to design).
| Relationship | Cardinality |
|---|---|
| Private Link service ← private endpoints | One-to-many: one service can accept many private endpoints |
| Private endpoint → Private Link service | One: each private endpoint targets one service/resource |
Use Private Link service when the exam describes ISV multi-tenant private connectivity, partner access to an internal API without VPN mesh sprawl, or publishing a custom service with the same private consumption model as Azure PaaS.
Disabling Public Access to PaaS
After private endpoints work, lock the public surface:
| Setting theme | Effect |
|---|---|
| Public network access = Disabled | Clients must use private endpoints (or documented exceptions) |
| Selected networks (firewalls + VNet rules) | Intermediate posture; still a public endpoint with ACL |
| All networks | Least secure; public endpoint open if credentials exist |
Combine with identity hardening (disable shared keys where possible, least-privilege RBAC). Network isolation without identity still fails open if a key leaks on an allowed path.
DNS: The Make-or-Break Detail
Clients almost always connect with the public FQDN of the service (mystorage.blob.core.windows.net, myvault.vault.azure.net). For private endpoints to work, that name must resolve to the private endpoint IP, not the public IP.
Private DNS zones (privatelink.*)
Azure documents per-service private DNS zone names. Examples you should recognize:
| Service | Example private DNS zone |
|---|---|
| Blob Storage | privatelink.blob.core.windows.net |
| File Storage | privatelink.file.core.windows.net |
| Azure SQL Database | privatelink.database.windows.net |
| Key Vault | privatelink.vaultcore.azure.net |
| Cosmos DB | privatelink.documents.azure.com (API-specific variants exist) |
| Azure Container Registry | privatelink.azurecr.io |
Typical integration:
- Create the matching private DNS zone.
- Create a virtual network link from the zone to every VNet that must resolve the name (hub + spokes).
- On private endpoint creation, register an A record (often automated when “integrate with private DNS zone” is selected in simpler designs).
- In enterprise hubs, use a central DNS architecture: private zones in a connectivity subscription, spokes use DNS forwarders/Private Resolver—application teams should not invent conflicting
privatelinkzones.
Exam trap: “We created a private endpoint but clients still hit the public IP” → almost always DNS. Fix resolution first, then retest.
On-premises clients
On-premises machines need conditional forwarders or equivalent so *.blob.core.windows.net (or the privatelink CNAME chain) resolves via Azure private DNS. ExpressRoute/VPN only carry packets; DNS is separate.
Service Endpoints vs Private Endpoints
Both limit who can reach PaaS, but they are not equivalent.
| Aspect | Service endpoints | Private endpoints (Private Link) |
|---|---|---|
| Client IP seen by service | Subnet identity via service endpoint; still targets public service VIP | Client uses private IP of endpoint in your address space |
| Data path | Optimized to Azure service over backbone; service remains publicly addressed | Private IP to private-link resource; can remove public exposure |
| Disable public access? | Public endpoint typically remains; firewall allows listed VNets | Preferred when requirement is no public endpoint |
| DNS | Usually unchanged public FQDN → public VIP | Must map FQDN → private IP (privatelink zones) |
| On-premises access | Not designed as private IP access from on-prem without additional patterns | Works with hybrid connectivity to the VNet hosting the endpoint |
| Complexity | Lower | Higher (DNS, approval, sub-resources) |
| SC-500 “strongest isolation” | Intermediate | Usually the correct “most secure network isolation” answer |
Can they coexist? Yes—private endpoints can be created in subnets that also use service endpoints—but Microsoft guidance for high-security designs prefers private endpoints and disabled public access rather than relying on service endpoints alone.
Scenario comparison
| Requirement | Prefer |
|---|---|
| Quickly restrict storage to a few Azure subnets; public endpoint OK if firewalled | Service endpoint + storage firewall |
| No public network path; on-prem SQL tools via ExpressRoute private path | Private endpoint + public access disabled + hybrid DNS |
| Partner consumes your custom API privately without VNet peering mesh | Private Link service + consumer private endpoints |
| Key Vault only from App Service in same region with minimal DNS work | Service endpoint may appear in older designs; modern secure baseline still pushes private endpoint |
Private DNS Integration Checklist
- Identify every PaaS sub-resource needing private access.
- Create matching privatelink zones (or use platform central zones).
- Link zones to all consuming VNets (and hub DNS path for on-prem).
- Create private endpoints; verify A records point to endpoint IPs.
- From a test VM,
nslookup/Resolve-DnsNamethe public FQDN—expect private address. - Disable public network access; confirm internet clients fail and private clients succeed.
- Document approval workflows for cross-subscription private endpoints.
- Watch for split-brain DNS if some clients still resolve public IPs.
SC-500 Exam Traps (Private Link)
- Service endpoint traffic still uses the public service address plane; private endpoint uses a private IP in your VNet.
- Private endpoint without DNS fix = intermittent public fallback or connection failures.
- One blob private endpoint does not private-ize file/queue/table automatically.
- Private Link service needs Standard Load Balancer, same region.
- Public access disabled is separate from creating the endpoint.
- NSGs on the private endpoint subnet can still block client→endpoint traffic—diagnose with Network Watcher (section 8.4).
End-to-End Scenario
Regulated app: App Service (VNet integrated) → Azure SQL + Storage.
Design: Private endpoints for SQL and storage blob/dfs in spoke or hub shared services subnet; private DNS zones linked; public access disabled on SQL/storage; outbound from App Service via VNet integration/private DNS; Azure Firewall optional for egress inspection. This is the layered pattern SC-500 expects you to assemble.
An engineer creates a private endpoint for an Azure Storage account blob sub-resource but clients still connect to the storage public IP. What is the most likely missing configuration?
Which statement correctly contrasts virtual network service endpoints with private endpoints?
A software vendor must let customer VNets reach a multi-tenant API privately without exposing a public IP. The API sits behind a Standard Load Balancer in the vendor subscription. What should the vendor configure?
After private endpoints are validated for Azure SQL, compliance requires that the logical server no longer accept connections via the public endpoint. What additional action is required?