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.
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 answer of someone building SaaS on Azure the private way.