Azure Private Link: Secure PaaS Access from Your VNet

In the last lesson, we built a layered defense model for your virtual network, securing it from external threats and controlling internal traffic flow. We concluded by noting a significant architectural challenge: many Azure PaaS services, like storage accounts and databases, exist outside your VNet with public endpoints. This lesson directly tackles that challenge.

Your goal here is to understand how Azure Private Link and private endpoints provide a modern, secure way to consume PaaS services as if they were part of your own virtual network. We will dissect how this works, why it's superior for security, and the operational trade-offs involved, particularly concerning DNS. To provide a complete architectural picture, we will also contrast this with the older Service Endpoint technology. This comparative analysis is vital for making informed design decisions, a key responsibility in a Principal Engineer role.

The Problem: Securing Access to Multi-Tenant PaaS Services

By default, Azure PaaS services are designed for accessibility and are exposed via public IP addresses. While traffic between your Azure VMs and these services stays on the high-speed Microsoft global backbone, the endpoint itself is public.

This diagram shows three ways a VM can access a storage account. The "Default" method illustrates traffic leaving the VNet to a public IP, which is the scenario we aim to improve.

Initial security relied on service-level firewalls, allowing you to whitelist specific public IP addresses. However, in a dynamic cloud environment where VMs can be ephemeral, managing IP-based allow-lists is brittle and doesn't scale. This led to the first evolution in securing PaaS access: Service Endpoints.

A First Step: Virtual Network Service Endpoints

Service Endpoints work by extending your virtual network's identity to a specific Azure service. When you enable a service endpoint on a subnet, traffic from that subnet to the designated Azure service (e.g., Azure Storage) is re-routed to use the VM's private IP address as the source. The PaaS service can then be configured to only allow traffic originating from that specific subnet.

As shown in the diagram above, the connection path for "Service Endpoints" is different from the default. The source IP is now the private IP of the VM, even though the destination is still the public endpoint of the storage account.

While this is an improvement, Service Endpoints have a critical limitation: they grant access to all instances of a service type within a region, not just your specific resource. For example, if you enable a service endpoint for Azure Storage, a compromised VM in that subnet could potentially send data to any storage account in that region, including one controlled by an attacker. This is a significant data exfiltration risk.

The Modern Solution: Azure Private Link and Private Endpoints

Azure Private Link is the premier solution for securing PaaS connectivity, designed to address the shortcomings of Service Endpoints and align with Zero Trust security principles. Instead of just identifying traffic, it brings the PaaS service directly into your virtual network.

This is achieved through a Private Endpoint, which is essentially a network interface (NIC) that Azure places in a subnet of your choice. This NIC gets a private IP address from your VNet's address space and represents a single, specific instance of a PaaS resource (e.g., one storage account or one SQL database).

Key architectural benefits of this approach include:

True Network Isolation: The PaaS resource effectively becomes part of your private network. You can completely disable its public endpoint, eliminating exposure to the public internet.
Data Exfiltration Prevention: This is the most significant security advantage. Since the private endpoint maps 1-to-1 to a specific resource, it is impossible for a compromised resource to use that connection to access any other PaaS instance.
On-Premises Connectivity: Because the private endpoint is just another IP address in your VNet, any on-premises systems connected via VPN or ExpressRoute can access the PaaS service privately without any complex routing or NAT.
Simplified Network Rules: You can use standard Network Security Groups (NSGs) to control traffic to the private endpoint's NIC, just as you would for any other resource in your VNet.

For a clear summary of the differences, study this table.

This table provides a concise comparison of Service Endpoints and Private Endpoints across key architectural dimensions like cost, traffic path, and security capabilities.

The article below provides an excellent enterprise-level perspective on why Private Link is a foundational component of modern Azure security architecture.

Azure Private Link & Private Endpoints: Enterprise Guide 2026

This guide explains the strategic value of Private Endpoints in achieving Zero-Trust networking and preventing data exfiltration. It also provides a clear decision framework for when to use them.

Read the introduction to understand the core value proposition. Then, review the section on Security Posture and Compliance Acceleration to see how Private Endpoints support compliance standards and prevent data exfiltration. Finally, read the Decision Framework to understand the technical and regulatory drivers for choosing Private Endpoints over alternatives.

The DNS Challenge: The Key to Making Private Link Work

The power of Private Endpoints introduces a new challenge: DNS. You cannot simply connect to the private IP address of the endpoint, because the SSL/TLS certificate on the PaaS service is issued for its public FQDN (e.g., myaccount.blob.core.windows.net), not an IP address. Any attempt to connect directly to the IP would result in a certificate mismatch error. Therefore, your applications must continue to use the public FQDN, but that name must resolve to the private IP address when accessed from your VNet.

Azure solves this with a clever, multi-step DNS resolution process. John Savill provides the definitive deep-dive on this topic. Watching this segment is crucial for a complete understanding of the underlying mechanics.

Microsoft Azure Private Link Deep Dive

This video provides an expert-level walkthrough of how DNS resolution works with Private Endpoints.

Please watch the section covering the entire DNS mechanism, starting from the explanation of the DNS problem and how Azure uses CNAMEs and private DNS zones to solve it. Pay close attention to his explanation of why the privatelink.* sub-zone is used.

To summarize the process explained in the video:

When you create a Private Endpoint for a resource, Azure's public DNS is updated. The original record (e.g., myaccount.blob.core.windows.net) is changed from an 'A' record pointing to the public IP to a CNAME (alias) record pointing to a new name in a privatelink zone (e.g., myaccount.privatelink.blob.core.windows.net).
To resolve this new name, you create an Azure Private DNS Zone named privatelink.blob.core.windows.net and link it to your virtual network.
Inside this private zone, you (or Azure, automatically) create an 'A' record for myaccount that points to the private IP address of your private endpoint.

Now, when a VM in your VNet queries for myaccount.blob.core.windows.net:

It gets the CNAME pointing to the privatelink FQDN.
It then queries for the privatelink FQDN. Because the VNet is linked to the private DNS zone, this query is resolved internally to the private endpoint's IP address.
A client outside your VNet would also get the CNAME, but its query for the privatelink FQDN would hit public DNS, which can still resolve it to the original public IP (unless you've disabled public access).

This architecture elegantly allows you to override DNS resolution only for specific resources and only within your private network, without breaking public resolution for other services.

Completing the Picture: Private Link Service

So far, we've discussed using Private Endpoints to consume Azure PaaS services. The Azure Private Link platform also allows you to provide your own services privately. This is done using a Private Link Service.

A Private Link Service allows you to expose an application running in your own VNet (behind a Standard Load Balancer) to other service consumers. These consumers can then create a private endpoint in their own VNets to connect to your service. This is immensely powerful for multi-tenant SaaS providers or for connecting services across networks with overlapping IP address spaces, as it avoids the need for VNet peering and uses network address translation (NAT) to handle the traffic.

Conclusion

In this lesson, we explored how to securely integrate Azure PaaS services into your virtual network, moving beyond basic IP whitelisting to true network isolation.

Your key architectural takeaways are:

Service Endpoints are a basic mechanism that keeps traffic on the Azure backbone but suffers from a significant data exfiltration risk because they grant access to an entire service, not a specific resource.
Private Endpoints are the modern, recommended solution. They provide a dedicated network interface for a specific PaaS resource inside your VNet, offering superior security, true network isolation, and robust data exfiltration prevention.
DNS is Critical: The functionality of Private Endpoints is entirely dependent on a correct private DNS configuration that resolves the public service FQDN to the private endpoint's IP address.
Trade-offs: The enhanced security of Private Endpoints comes with the cost of increased operational complexity (managing DNS) and a direct monetary cost, whereas Service Endpoints are free.

You now have a solid framework for deciding how to connect your virtual networks to Azure's rich ecosystem of PaaS services. We've established that on-premises networks can also leverage Private Endpoints. In our next lesson, we will dive deeper into establishing that on-premises connection, comparing the primary hybrid connectivity options: VPN Gateway vs. ExpressRoute.