Private Link Service: being the door, not the visitor
Every move so far has put you on the consumer side — reaching in to someone else's storage account or database. Now flip the arrow. Campux runs an internal order-status API that a shipping partner needs to call, and neither side will put it on the public internet. The partner is a different company, in a different Azure tenant, with no shared network and no shared identity. What you want is to hand them a private door into your own service, on their terms, without ever peering the two networks. That is Azure Private Link Service, and it is the exact mirror image of the private endpoint you built in Part I.
- Private Link Service
- The provider-side object that publishes your own service — one running behind a Standard Load Balancer — for private consumption. Consumers reach it by creating a private endpoint in their network; you approve each connection. No peering, no shared identity, no public exposure.
The mechanics are specific and worth holding. Your service must sit behind a Standard Load Balancer — Basic will not do — and you create the Private Link Service against one of that balancer's frontend IP configurations. You also nominate a subnet for NAT IP addresses: every consumer's traffic is address-translated to appear to originate from this pool, so two different customers using the same private range can never collide on your side. Microsoft recommends keeping at least eight NAT addresses free, and a single Private Link Service can hold up to eight.1 In return Azure mints a globally unique alias — campux-orders.guid.westeurope.azure.privatelinkservice — which is the only thing you hand the partner. It reveals nothing about your subscription or resource names.
The consumer then creates a private endpoint targeting that alias, and here is the property that makes this safe across a trust boundary: the connection arrives on your Private Link Service in a Pending state, and no traffic flows until you approve it. You control exposure with a visibility setting — role-based access for your own tenants, a named allowlist of trusted subscriptions, or open to anyone holding the alias — and you can pre-approve known subscriptions with an auto-approval list so their endpoints connect without a manual step. Approve the wrong subscription and you have opened a door; the request/approve handshake is the whole security model, and it is entirely in the provider's hands.
Career-wise, this is the half of Private Link that separates people who consume Azure from people who build on it. Every SaaS vendor that offers "connect to us over a private endpoint" is running a Private Link Service behind the scenes; understanding the provider side is how you go from wiring your own storage to shipping a product other companies reach privately.
Play it through
Four minutes, one order to rebuild. Stand up the load balancer, publish the service, let the partner ask, then approve it yourself — get the order wrong and see exactly what it produces instead.
This half carries no lab. Standing up a Private Link Service means a real Standard Load Balancer, a NAT-IP subnet, and — to see the cross-tenant approval for real — a second Azure tenant to request from, which is well past a beginner Cloud Shell exercise. Play the lesson above instead; it rehearses the exact same build-then-approve sequence at zero cost and zero risk.
Across regions, across tenants, and the limits that bite
Private Link crosses boundaries that stop most networking. A private endpoint does not have to share a region with the resource it fronts: the NIC lives in your subnet's region, the target can sit in another, and the private path still holds — the only price is the latency of the distance, which makes cross-region private endpoints a normal shape for disaster-recovery designs where a failover region reaches primary data privately. What does not cross a region is the Private Link Service itself, which must be deployed alongside its virtual network and load balancer; the consumer's endpoint, though, may sit anywhere.
The more surprising reach is across ownership. A private endpoint and its target — or a private endpoint and a Private Link Service — can live in different subscriptions and even different Microsoft Entra tenants, with no peering and no shared RBAC between them. The two sides are joined only by the connection handshake of §1: the consumer requests, the provider approves. This is the security property that makes Private Link the sane answer for exposing a service to a customer. You never grant them a role in your subscription or a route into your network; you approve one connection to one endpoint, and revoke it by rejecting that connection. Contrast VNet peering, which joins two entire address spaces and demands cooperation on both sides — Private Link hands over a single door, not a shared hallway.
The DNS zone group, named at last
Three times already in Part I this class mentioned wiring the endpoint to its zone; here is the object that does it. A private DNS zone group is a small sub-resource of the private endpoint that binds the endpoint to one or more private DNS zones and keeps the A-record in step with the endpoint's IP automatically. It is the difference between a zone you hand-maintain and one Azure keeps correct for you: create the endpoint, attach the zone group, and if the endpoint's private IP ever changes the record follows it without a human touching the zone. This is why the CLI lab ran private-endpoint dns-zone-group create as its own step and the portal's DNS tab offered one toggle — both are creating this object. Resolving that same name from on-premises, where your machines cannot see an Azure private zone at all, is the whole of Class Fifteen; the zone group is the piece that makes the name correct inside Azure, and the on-prem resolver is what carries that answer back to the office.
Finally, the accounting, because "private everything" has a shape and a bill. A private endpoint is not free the way a service endpoint is: it bills per hour it exists, plus a charge for every gigabyte processed inbound and outbound through it. Multiply that by one endpoint per service per network and the number is real at estate scale — a reason to reach for a service endpoint when the requirement genuinely is only "restrict to my subnets." There are also structural limits: one private endpoint fronts one sub-resource, so a storage account exposing blob, file, queue and table needs four; a Private Link Service holds up to eight NAT addresses and is capped per load balancer and per subscription; and endpoints consume real private IPs from your subnets, so a plan that puts hundreds of them in one small subnet runs out of addresses before it runs out of budget.1
| Service endpoint | Private endpoint | Private Link Service | |
|---|---|---|---|
| Whose side you are on | Consumer | Consumer | Provider |
| What it produces | A trusted subnet on a public resource | A NIC + private IP fronting one resource | An alias others connect to privately |
| Crosses tenants? | No | Yes — with connection approval | Yes — you approve each consumer |
| Crosses regions? | No | Yes — endpoint and target may differ | Consumer endpoint may; the service may not |
| Needs a load balancer? | No | No | Yes — Standard, never Basic |
| Cost | Free | Per hour + data processed | No hourly charge to publish; data processed |
Read Table 2 as a decision, not a taxonomy. If the requirement is "keep this on the backbone," a service endpoint. If it is "give this resource a private address and let me close the public door," a private endpoint. If it is "let another company reach a service I run, without joining our networks," a Private Link Service. Three requirements, three tools; the interview question is whether you can name which one the sentence in front of you is actually asking for.
Approving the one connection that matters
"Can partner logistics reach our order-status API without us opening it to the internet?" You publish a Private Link Service behind the API's Standard Load Balancer, hand the partner one alias, and wait. Their connection request lands Pending. You check the subscription ID against the partnership paperwork, approve the one connection, and traffic starts flowing — no peering, no shared role, no route into your network ever granted. Six months later an unrecognised subscription tries the same alias; it sits Pending too, and you reject it without calling a meeting.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
A. The alias is the only thing that crosses the tenant boundary; the consumer's side of the handshake is exactly the same private endpoint you built in Part I, just aimed at your alias instead of a storage account. B is wrong because peering is precisely what this design avoids — no shared address space, no cooperation required on both sides. C is wrong because Private Link never hands out subscription roles; the security model is a connection you approve, not an identity you grant. D is wrong because publishing a Private Link Service does not create a new public IP — the whole point is that nothing new appears on the public internet.
C. Pending means exactly what it says: a request is waiting for a decision, and no traffic moves until you make one. A and B invent behaviour Private Link does not have — there is no low-priority traffic mode and no timeout that promotes a request on its own. D is the trap dressed up as convenience: resolving the alias only finds the door, it does not open it. The request/approve handshake is the entire security model, and it sits entirely in the provider's hands unless you have explicitly pre-approved a subscription.
The Standard-Load-Balancer requirement, the eight-address NAT ceiling, and the region rule. The two false statements are the pair this half exists to correct. The Private Link Service is anchored to its own load balancer and virtual network for its whole life — it does not travel to meet a consumer, only their endpoint does, and the distance is a latency cost, not a redesign. And the alias is not a secret: it identifies nothing about your subscription, but nothing stops anyone who obtains it from trying to connect, which is exactly why "anyone holding the alias" throws away the one control — your approval — that made the design safe in the first place.
PLAN — onboard partner-logistics over Private Link
1. Put the order API behind a Standard Load Balancer.
2. Create the Private Link Service against that balancer;
note the alias it mints.
3. Set visibility to "Anyone with the alias", so future
partners can connect without waiting on us.
4. Hand today's partner the alias; they create a private
endpoint against it in their own subnet.
Line three. "Anyone with the alias" removes the request/approve handshake entirely — every connection auto-completes, known partner or not, because the alias is a working credential for whoever holds it, not a secret only your real partners have. The fix is a visibility scoped to known subscriptions, with an auto-approval list for the ones you already trust, so onboarding stays fast without opening the door to strangers. Line one is correct as written — Standard is mandatory, not optional. Line two is backwards: the alias is exactly what you are meant to hand the consumer; it reveals nothing sensitive on its own. Line four is also correct: a private endpoint on the consumer's side is the whole mechanism — peering is the thing this design exists to avoid.
Concede the latency is real, then correct the request. The Private Link Service cannot be redeployed to sit "closer" to a consumer — it is anchored to the Standard Load Balancer and virtual network it was created against, for as long as it exists. There is no setting that relocates it, because it is not a standalone object; it is a front door bolted to a specific building. Moving the building is not an option.
Name what actually can move: their endpoint, not your service. The partner's private endpoint can already sit in whatever region their own workload runs in — that part of the design is region-agnostic by design. The distance between their endpoint and your Private Link Service is a real latency cost of geography, not a networking mistake to fix; it is priced in the same way any cross-region call would be, private or not.
If the requirement is genuinely "fast, private access from three continents," the honest answer is more infrastructure, not a relocated one. Deploy the order API, its load balancer, and a Private Link Service in each region that needs low latency, and give each regional partner an alias for the stack nearest them. That costs real money and real operational surface — which is exactly why it should be a deliberate decision against a stated latency requirement, not a favour granted because one partner asked.
Concede the real cost before defending the control. Being the manual approver for every new partner genuinely does not scale past a handful of relationships, and a teammate who is tired of being that bottleneck is pointing at a real problem. Dismissing the complaint outright loses the argument before it starts.
Name what "anyone with the alias" actually throws away. The alias is not a secret credential issued per partner — it is one string, and holding it is the only thing "open" visibility checks. Approval, not the alias, is the actual security boundary of this whole design; remove it and an unrecognised subscription connects exactly as easily as the partner you meant to onboard, because nothing distinguishes them anymore.
Offer the setting that actually solves the scaling problem: an auto-approval allow-list. Name the known subscriptions once, and their future connections complete without a manual step, while anything outside that list still lands Pending for a human to see. That gets your teammate the speed they want for partners you have already vetted, and keeps the one check that matters for everyone else — which is the difference between removing a bottleneck and removing a boundary.
What Part II leaves you holding
- A Private Link Service is the provider side of Private Link: it publishes your own service, behind a Standard Load Balancer, for private consumption — the exact mirror of the private endpoint you built to reach in.
- A consumer connects by creating a private endpoint against the alias you hand them; the connection sits Pending until you approve it, and approval is the whole security model.
- Visibility decides who may even try: role-based access, a named allow-list with auto-approval, or open to anyone holding the alias — and the alias is not a secret, so "open" approves everyone at once.
- A private endpoint may cross regions and tenants; the Private Link Service itself may not move — it stays anchored to its own load balancer and virtual network for as long as it exists.
- Private Link hands over one door, not a shared hallway: no peering, no shared RBAC, one connection approved or revoked at a time.
- Treat the specific figures here as current-at-writing, not eternal: the eight-NAT-address ceiling per Private Link Service and the per-load-balancer and per-subscription caps are the ones Microsoft documents today, and the hourly and per-gigabyte prices vary by region and drift over time. The direction is what to carry — private endpoints bill where service endpoints do not, endpoints are per-sub-resource, and a Private Link Service is a Standard-Load-Balancer-only, provider-side object with a NAT pool. Check the live limits and pricing pages before you size or budget anything. ↩ ↩