To appreciate the solution, we first look at what the default looks like.

Platform services have public addresses

Many Azure services, such as storage accounts, SQL databases, key vaults and message queues, are called platform services or PaaS services, short for platform as a service. You do not manage their servers; you simply use them. By default, each one is reachable through a public endpoint: a name and an address on the public internet. Authentication and firewall rules protect them, but the front door still faces the street.

For many organizations that is not acceptable. Security policies, regulations and risk reviews often require that sensitive traffic never travels over public addresses at all. Teams want the database to feel like it is sitting inside their own private network, with a private address, reachable only by their own systems.

What organizations really want

Four wishes appear again and again. First, reach platform services using private addresses from inside the virtual network. Second, reach them from on-premises networks over private connections without going through the internet. Third, ensure that private access leads to one specific resource, not to the whole service where an insider could copy data to another customer’s account. Fourth, let teams publish their own services to customers or other business units without exposing them publicly. Private Link addresses all four.

Private Link is a family of pieces that work together, not a single switch.

Azure Private Link lets you access Azure platform services, and services hosted by other organizations on Azure, over a private connection inside your virtual network. A virtual network, often shortened to VNet, is your own isolated network in Azure with its own address range. Private Link places a private address from that range in front of the target service, so traffic stays on the Microsoft backbone network and never needs the public internet.

flowchart LR
  A["Client VM in your VNet"] --> B["Private endpoint with private IP"]
  B --> C["Microsoft backbone network"]
  C --> D["Azure service resource, for example a storage account"]
        

Where to find it

The Azure portal offers a Private Link Center that gathers private endpoints, private link services and pending connection requests in one place. This is useful for security teams who want one view across subscriptions.

A private endpoint is simple to describe and full of detail underneath.

A private endpoint is a network interface, the virtual equivalent of a network card, that is created in a subnet of your virtual network. It receives a private IP address from that subnet’s range. The interface is linked to one specific resource through a connection managed by the platform. Any machine that can reach the private address, whether in the same network, a peered network or on-premises through a private link, can send requests to the target service through it.

One endpoint, one sub-resource

A common beginner surprise is that a single private endpoint does not cover every feature of a service. If an application uses both the blob and the file features of one storage account, it needs two private endpoints, one for each sub-resource, and two matching DNS entries. Missing one leaves that feature still trying to use the public path.

Endpoints are regional but flexible

The endpoint lives in a virtual network in one region, but it can point to a resource in a different region, which supports designs where a service in another region is reached privately. Plan latency and data-transfer cost accordingly. Also remember that the subnet holding the endpoint must exist in the same region as the virtual network, naturally, and the endpoint lives in the same subscription as the network it sits in, which may differ from the subscription of the target.

The same technology works in reverse, for providers.

Until now we described the consumer side: someone who wants to reach a service privately. The provider side is for organizations that run a service of their own and want customers, partners or other teams to reach it privately. This is called Private Link Service. You place your application behind a standard load balancer, a component that spreads incoming connections across several servers, and then attach a Private Link Service to the load balancer’s front end. Consumers then create private endpoints in their own networks that connect to your service.

flowchart LR
  subgraph Consumer["Consumer network"]
    C1["Client application"] --> PE["Private endpoint"]
  end
  subgraph Provider["Provider network"]
    PLS["Private Link Service"] --> LB["Standard load balancer"]
    LB --> S1["Server 1"]
    LB --> S2["Server 2"]
  end
  PE ==>|Private connection| PLS
        

Why address overlap is not a problem

Different customers often use the same private address ranges, such as the common ranges that begin with ten. Normally two networks with overlapping ranges cannot be connected. Private Link avoids this: the consumer sees an address from its own range, the provider sees translated addresses from its NAT subnet, and no routes are exchanged between the two networks. This makes it ideal for software as a service providers with many customers.

Azure offers more than one way to restrict access, and they are not the same.

Service endpoints are an older feature that extends your virtual network’s identity to a service, so that the service can be told “accept traffic only from this subnet”. The service still uses its public address, but the platform tags the traffic as coming from your subnet. Public firewall rules simply allow certain internet addresses. Private Link gives the service a true private address inside your network. Each approach has a place.

flowchart TD
  A["Need to restrict access to a platform service"] --> B{"Must clients use private IPs or connect from on-premises?"}
  B -->|Yes| C["Use Private Link"]
  B -->|No| D{"Need strong exfiltration control or disabled public access?"}
  D -->|Yes| C
  D -->|No| E{"Only Azure subnets need access and low risk?"}
  E -->|Yes| F["Service endpoints may be enough"]
  E -->|No| G["Public endpoint with strict firewall rules"]
        

The path of a request tells you where to look when something breaks.

When a client in your virtual network sends a request to a service through a private endpoint, the packet leaves the client with the private address as its destination. The virtual network routes it to the endpoint’s network interface. From there, the Azure platform carries it across the Microsoft backbone network, a private global network owned and operated by Microsoft, directly to the target resource. It does not pass through the public internet, even though the service is a public cloud service.

The endpoint does not use your service’s public address at all

The traffic does not leave toward the service’s public address and get redirected. It is addressed to the private one from the start. This is why a correct DNS answer is critical: if the client resolves the public address, the packets go out the public way and ignore your private endpoint entirely.

Special behavior of some services

Certain services have connection modes that affect how private endpoints work. Azure SQL, for example, offers redirect and proxy connection policies. With private endpoints, connections use the proxy approach, so the client talks to the gateway at the private address instead of being redirected to a separate node address. Always read the service-specific guidance before designing firewalls and routes.

If Private Link has one secret, it is that the network piece is easy and the naming piece is hard.

DNS, the Domain Name System, is the internet’s phone book. It translates names that humans use, such as the address of a storage account, into the numeric addresses that machines use. When you create a private endpoint, the service’s name must resolve to the private address when asked from inside your network, but still resolve to the public address when asked from anywhere else. Making that split work is the trickiest part of any Private Link design.

The trick: a special alias name

Azure solves this with a chain of names. When someone asks for the normal service name, the public DNS answers with an alias that points to a special name in a “privatelink” zone. For example, the storage blob name is redirected to a name containing the word privatelink. Outside your network, that special name has no private answer, so it falls through to the public address. Inside your network, you create a private DNS zone with the matching privatelink name and put an entry for the private endpoint in it. Your clients then get the private address.

sequenceDiagram
  participant C as Client VM
  participant R as DNS resolver
  participant PZ as Private DNS zone
  participant PD as Public DNS
  C->>R: Ask for service name
  R->>PD: Ask public DNS
  PD-->>R: Alias to privatelink name
  R->>PZ: Ask private zone for privatelink name
  PZ-->>R: Private IP of endpoint
  R-->>C: Private IP
  Note over C: Client connects to the private IP
        

Private DNS zones you will meet

The three most common DNS failures

The right DNS design depends on how many networks and how much on-premises integration you have.

flowchart LR
  OP["On-premises DNS server"] -->|Conditional forward of privatelink zones| IN["Azure DNS Private Resolver inbound endpoint"]
  IN --> Z["Private DNS zones linked to hub VNet"]
  SP["Spoke VNet workloads"] -->|Custom DNS setting| IN
  Z --> A["Answer: private IP of endpoint"]
        

The role of the private resolver

Azure offers a managed DNS Private Resolver. It has an inbound endpoint that accepts questions from on-premises or other networks and answers them using the private zones, and an outbound endpoint with rules that forward chosen names to other DNS servers. Before it existed, teams had to run their own forwarder virtual machines, which needed patching, scaling and high availability. The managed resolver removes that work and is generally the preferred design today.

Records that update themselves

When you attach a DNS zone group to a private endpoint, Azure automatically creates and removes the matching records in the private zone. If you delete the endpoint, the record disappears with it. Doing this by hand is a common source of stale entries pointing to addresses that no longer belong to the endpoint.

Who decides whether a private door may be opened?

A private endpoint is a request to connect to a resource. The owner of the resource must be able to control which requests are accepted. Each connection has a state that you will see in the portal.

Automatic versus manual approval

If the person creating the endpoint also has sufficient permission over the target resource, as is usual inside one team, the connection is approved automatically. When the target belongs to another team or another organization, or when the creator lacks the permission, the connection waits in a pending state, and the resource owner must approve it. Providers of private link services can pre-approve specific subscriptions to speed this up.

Permissions that matter

Creating a private endpoint requires rights on the network side to create the interface and on the resource side to request the connection. Approving requires rights on the target. Separating these roles supports good governance: network teams manage endpoints and DNS, while data owners decide who may connect to their data.

A private address is still a network address, and network controls can apply to it.

Network security groups

A network security group, or NSG, is a set of allow and deny rules attached to a subnet or interface. Historically, private endpoints ignored NSG rules by default, and a subnet setting called the network policy had to be enabled before NSG rules and custom routes would apply to them. Platform behavior has evolved, so check the current option for private endpoint network policies on your subnet. Where it is enabled, you can write rules that restrict which clients may talk to the endpoint, which is a valuable second layer of defense.

User-defined routes and inspection

Many organizations send traffic through a central firewall for inspection. Private endpoints add a wrinkle: the platform creates a very specific route for each endpoint address, which normally wins over your custom route and sends traffic straight to the endpoint, skipping the firewall. To inspect that traffic, you use the subnet network policy setting that lets your own routes apply to private endpoints, and you handle address translation so that return traffic comes back through the same firewall. Without that, you can get asymmetric routing: requests go through the firewall but replies take a shortcut, and the connection breaks.

flowchart LR
  A["Client in spoke"] --> B["Central firewall in hub"]
  B --> C["Private endpoint"]
  C --> D["Target resource"]
  D -.->|Reply must return the same way| B
  B -.-> A
        

Application-level filtering

Some firewalls can filter traffic aimed at private endpoint addresses by name or by application rule. Whether you inspect or not depends on your security requirements. Inspecting everything adds cost and latency; not inspecting trusts the endpoint’s inherent resource scoping and the service’s own authentication.

Private Link is a security feature, so let us be precise about what it protects.

What it does not protect against

Private Link does not stop a stolen password or key. It does not stop an authorized user from misusing their rights. It does not protect against vulnerabilities inside the service. It does not inspect content. You still need strong identity, least privilege, encryption, monitoring and patching. Private Link narrows the doors; it does not replace the locks.

Governance at scale

Large organizations manage private endpoints through policy and automation rather than by hand. Azure Policy can audit or deny services whose public access is enabled, and can automatically deploy private endpoints or DNS zone groups for resources that lack them. Naming conventions, tags for ownership and cost center, and central visibility in the Private Link Center help keep order when hundreds of endpoints exist.

A long and growing list, grouped here by purpose.

Service-specific notes worth knowing

The private address works for any client that can route to it.

One of the biggest reasons to adopt Private Link is that on-premises systems can use platform services privately. Connect the data center to Azure with a site-to-site virtual private network, which builds an encrypted tunnel across the internet, or ExpressRoute, a dedicated private circuit. Once the on-premises network can route to the subnet holding the private endpoint, the on-premises client simply connects to the private address.

flowchart LR
  A["On-premises application"] --> B["VPN or ExpressRoute"]
  B --> C["Hub virtual network"]
  C --> D["Private endpoint subnet"]
  D --> E["Storage account or database"]
  A -.->|DNS query forwarded| F["Azure DNS resolver"]
        

Where you place endpoints and zones shapes cost, security and simplicity.

Many enterprises use a hub-and-spoke network layout. A central hub network holds shared components such as the firewall, gateways and DNS resolvers. Separate spoke networks hold individual workloads and are peered to the hub. Private endpoints can be placed in the hub, in a dedicated shared-services network, or in each workload’s spoke.

flowchart TD
  H["Hub: firewall, gateway, DNS resolver, shared private endpoints"]
  S1["Spoke 1: Workload A"] --- H
  S2["Spoke 2: Workload B"] --- H
  S3["Spoke 3: Data platform with own private endpoints"] --- H
  OP["On-premises"] --- H
        

Reuse an endpoint across peered networks

A private endpoint in one virtual network can be used by clients in other networks that are peered to it, as long as routing and DNS allow it. This is often more economical than creating one endpoint per spoke for the same service, but be aware that traffic crossing peering incurs data charges, and shared endpoints centralize risk.

Standardize with policy and modules

In a landing zone, teams should not hand-build endpoints. Provide approved templates, infrastructure-as-code modules and Azure Policy that deploys the endpoint and its DNS zone group automatically when a team creates a supported service. This produces consistent naming, correct DNS and measurable compliance.

The order matters; doing DNS last is the classic mistake.

Recipes that appear in nearly every enterprise design.

Pairing inbound and outbound controls

A subtle point: a private endpoint on a service controls how others reach it. To let that service reach other private resources, it may need its own outbound network integration. Treat inbound and outbound as separate decisions for each component, and draw both on your architecture diagram.

For software vendors and internal platform teams, Private Link Service opens a clean delivery model.

When something cannot connect, work through the layers in order.

What you can observe

flowchart TD
  A["Cannot connect"] --> B{"Connection state Approved?"}
  B -->|No| C["Approve or recreate the connection"]
  B -->|Yes| D{"Name resolves to private IP from the client?"}
  D -->|No| E["Fix DNS: zone link, forwarders, custom DNS settings"]
  D -->|Yes| F{"Route and NSG allow the path?"}
  F -->|No| G["Fix routes, network policy, NSG, firewall"]
  F -->|Yes| H{"Public access disabled and client using private path?"}
  H -->|Unsure| I["Check service logs and client network"]
  H -->|Yes| J["Check authentication, permissions and service-specific settings"]
        

Private Link is not free, and design choices change the bill.

Private endpoints are typically billed per hour that they exist, plus a charge for the data processed through them in each direction. Private Link Service has its own pricing structure. Data transfer between virtual networks over peering, between regions, or through gateways adds to the total. Prices and billing details change, so confirm current figures on the official pricing page before you build a budget.

Limits and capacity planning

Subscriptions and virtual networks have limits on the number of private endpoints, and a private link service has limits on NAT addresses and connections. These limits are documented and can change. In large estates, track endpoint counts per network and per subscription so that you do not discover a ceiling in the middle of a project.

Habits that work, and habits that cause incidents.

Patterns worth adopting

Anti-patterns to avoid

A review list before going to production.

How organizations apply these ideas.

Quick answers to questions that come up constantly.

It is a feature that gives a platform service or your own service a private address inside your virtual network, so that traffic stays on the Microsoft backbone and does not need to use the public internet.

A private endpoint is the consumer side: an interface in your network that connects to a service. Private Link Service is the provider side: a way to publish your own service, behind a standard load balancer, so that others can connect to it through their private endpoints.

No. You must disable public network access on the resource, or restrict it with firewall rules, to remove the public path. The endpoint only adds a private path.

Usually because the private DNS zone is not linked to the client’s network, the client uses a different DNS server that does not know the zone, or on-premises DNS lacks a conditional forwarder.

You need one for each sub-resource you use. For example, a storage account needs separate endpoints for blob and for file if you use both.

Yes, through VPN or ExpressRoute, provided that routing reaches the endpoint subnet and on-premises DNS resolves the private address through forwarding to an Azure resolver.

Service endpoints keep the service’s public address and add a subnet-based rule, while Private Link gives the service a private address in your network, works from on-premises, and maps to a single resource, which gives stronger protection against data exfiltration.

Yes. The connection may require approval from the resource owner, and providers can share an alias and pre-approve selected subscriptions.

Behavior has changed over time and depends on the subnet’s network policy setting. Check the current documentation and enable the policy that lets NSG rules and custom routes apply if you need them.

Yes. Private endpoints are generally billed per hour plus data processed, so check current pricing and design to avoid unnecessary endpoints.

Yes. Because the provider sees translated addresses and no routes are exchanged, overlapping ranges are not a problem, which is a major advantage for providers.

Check that the connection is approved, then resolve the service name from the failing client and confirm it returns the private address. Only then investigate routes and firewalls.

The concepts are stable, but supported services, limits, network policy behavior, zone names and prices change. Always confirm details in the current official Azure documentation before finalizing a design.

Azure Private Link brings cloud services inside your own network. A private endpoint gives a platform service a private address in your subnet, tied to one specific resource. A Private Link Service lets providers publish their own services without exposing them or exchanging routes. The network side is straightforward; the naming side, DNS, decides success or failure. Good designs centralize DNS, link zones correctly, forward on-premises queries to a private resolver, place endpoints thoughtfully in a hub-and-spoke layout, and apply policy to keep things consistent. They disable public access last, after every client is confirmed on the private path, and they keep strong identity and monitoring in place because private networking narrows the doors but does not replace the locks. Treat the details of services, prices and limits as things to verify, and the ideas in this guide will serve you across any Azure environment.