Private Link Service: how you offer your own service privately
You have met the private endpoint — the way you reach Azure Storage or a database over a private IP instead of the public internet. Private Link Service is the mirror image: the way you publish your own service so your customers reach it that way. If you build SaaS on Azure, this is how you give clients private connectivity without ever exposing a public IP.
New to cloud? CAMPUX is a free, build-first course. Start here →
Most people meet Private Link from the consumer side, through a private endpoint: you drop a private IP into your own network that maps to some service, and traffic never touches the public internet. But every private endpoint needs something on the other end to connect to. When that something is your service — not a Microsoft-run one — the thing you create is a Private Link Service. Microsoft's definition names the role precisely: it "is the reference to your own service that is powered by Azure Private Link," and it "explains concepts related to the service provider side." Private endpoint is how you consume; Private Link Service is how you provide.
The one hard requirement: a Standard Load Balancer
A Private Link Service does not point at your VMs directly — it points at a Standard Load Balancer that sits in front of them. You run your application behind that load balancer in your own virtual network, then create a Private Link Service referencing its frontend IP. That is the whole provider setup: app behind a Standard Load Balancer, Private Link Service in front of the load balancer. (Standard is required — the Basic SKU does not qualify.) From there, consumers connect not to your load balancer's public address but through private endpoints they create in their own networks.
The alias: a shareable, opaque name
When you create the service, Azure generates a globally unique alias — a name like myservice.{guid}.region.azure.privatelinkservice. You hand that alias to a customer, and they use it to request a private-endpoint connection to your service. The alias is doing two jobs at once: it is an easy string to share, and it masks the details of your service so customers do not learn your internal resource layout. They get a name to connect to, not a map of your infrastructure.
A private endpoint is how you consume a service privately. Private Link Service is how you offer yours — same private pipe, opposite ends.
You approve who connects
Exposure is under your control, in two layers. Visibility decides who is even allowed to request a connection — from "only subscriptions with the right RBAC" (most restrictive), to a named set of trusted subscriptions, to "anyone with the alias" (most open). Then, when a consumer does request a connection, it lands in a Pending state and you, the provider, approve or reject it — and only approved connections can send traffic. If you would rather not click approve for every trusted customer, an auto-approval list pre-approves specific subscriptions. So a stranger cannot simply attach to your service; they have to be visible to it and then approved by you.
Consumers connect from their networks, and different customers might use overlapping private IP ranges — a recipe for address collisions. Private Link Service solves this with destination-side NAT: you dedicate a pool of NAT IPs from a subnet in your network, and all consumer traffic appears to your service as coming from those NAT IPs. That guarantees no IP conflict between a customer's address space and yours. One consequence: by default your application sees the NAT IP, not the customer's real source IP — if you need the true client IP (and LinkID) you enable the TCP Proxy v2 option and parse the proxy-protocol header. It also means traffic rides the Microsoft backbone, never the public internet.
Who this is for
Private Link Service is a SaaS and platform-team tool. If you sell or operate a service that other Azure customers (or other teams in a big enterprise) consume, and you want them to reach it privately — no public endpoint, no traffic on the internet, connection-by-connection approval — this is the mechanism. A private endpoint on their side, a Private Link Service on yours, and the two meet over Microsoft's backbone. It is the pattern behind a lot of "connect privately to our platform" offerings you see from vendors building on Azure.
The takeaway
Private Link Service is the provider half of Private Link: put your application behind a Standard Load Balancer, front it with a Private Link Service, and share the generated alias so customers connect through private endpoints in their own networks — never over a public IP. You control who can connect through visibility and per-connection approval, and destination NAT keeps everyone's address space from colliding. "Our service sits behind a Standard Load Balancer with a Private Link Service in front, customers connect by alias over private endpoints, and I approve each connection" is the whole architecture in one breath, the shape a SaaS team settles on once it decides customer traffic should never cross a public IP.
Questions people also ask
What is Azure Private Link Service used for?
You use it to expose your own application to other Azure customers over a private connection instead of a public IP. Your app sits behind a Standard Load Balancer, you attach a Private Link Service to that load balancer, and consumers reach it through a private endpoint in their own network, over the Microsoft backbone.
What is the difference between Private Link Service and private endpoint?
They are the two ends of the same connection. A private endpoint is what a consumer creates to reach a service privately. A Private Link Service is what a provider creates to publish a service for consumers to reach. One private endpoint connects to one Private Link Service; a Private Link Service can accept connections from many private endpoints.
Does Private Link Service require a Standard Load Balancer?
Yes. A Private Link Service attaches to the frontend IP configuration of a Standard Load Balancer, not to your VMs directly. The Basic SKU does not qualify. This is the one hard infrastructure requirement on the provider side.
How do consumers connect to a Private Link Service?
You share the generated alias, a unique name like myservice.{guid}.region.azure.privatelinkservice, with your customer. They use that alias to request a private-endpoint connection from their own virtual network. The request lands in a pending state until you approve it, or it matches your auto-approval list.
Why does Private Link Service use NAT for consumer traffic?
Different consumers can use overlapping private IP ranges, which would otherwise collide with your address space. Private Link Service applies destination-side NAT from a dedicated pool of IPs in your network, so all consumer traffic reaches your service through those NAT IPs instead of the consumer's original address.