This part assumes Class 14 Part A, where you built a private endpoint as the consumer, and Class 13 Part A, where a standard load balancer appeared. If either is new, do the guided practice at the bottom of this page first: it needs neither.
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 application behind a Standard Load Balancer. Consumers create private endpoints to it. The provider controls visibility and manual or automatic approval; application authentication and any existing public route are separate controls.
Your application must sit behind a Standard Load Balancer, and the Private Link Service references one of its frontend IP configurations. The service also needs NAT IP configuration so consumer connections can reach your backend without overlapping consumer address spaces. A service can have up to eight NAT IP addresses; how many you need depends on concurrent connections and port use, not a universal instruction to reserve eight.1 Azure gives the service an alias that consumers can use instead of your resource ID. The alias is an identifier, not a password.
The consumer creates a private endpoint targeting that alias. Visibility controls which subscriptions may request a connection. Approval controls which requests can carry traffic: visible subscriptions outside the auto-approval list arrive Pending and need a provider decision; subscriptions on that list can be approved automatically. “Anyone with your alias” widens who may ask; it does not auto-approve them. After approval, the consumer still needs DNS pointing its application name to its private endpoint and valid API credentials. Verify any old public listener is closed if the service must be private-only.2
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
Put the provider stack and consumer request in order. Then see why open visibility invites requests without approving them, and why DNS and API credentials still matter.
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
A consumer's private endpoint can be in a different region from the Private Link Service. The service itself is deployed in the same region as its provider VNet and Standard Load Balancer. The connection can work across regions, but measure latency and data-transfer costs; a private path does not make a distant API fast. If the provider needs a closer service, it must deploy the API and its load balancer in that region and publish another Private Link Service there.
The consumer and provider can also be in different subscriptions and Microsoft Entra tenants without peering their VNets. Connection approval may be manual or based on a provider-managed auto-approval list. Approval permits a network path to this service, not unrestricted access to the provider VNet or authorization inside the API. Use application credentials and revoke an unwanted connection at the provider service; test that the consumer can no longer connect.
The DNS zone group, named at last
Part I kept returning to 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.
Private endpoints incur hourly and data-processing charges; Standard Load Balancer, Private Link Service traffic and cross-region transfer can add costs. Check current prices for the regions and expected traffic. A storage account may need separate endpoints for Blob, File, Queue and Table when those services are used privately. Private endpoints consume subnet IPs, and Private Link Service has NAT and resource quotas; size them against measured connection and address needs.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? | Not a cross-tenant private path | Yes, where supported, subject to connection approval | Yes; manual or scoped automatic approval |
| 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 charge to publish — data processed bills on the consumer's private endpoint |
Use the table to identify candidates. A service endpoint keeps a public-IP DNS answer and needs a resource firewall rule. A private endpoint adds a private IP; public network access is disabled separately where required. Private Link Service publishes an application for consumers' private endpoints. In each design, test DNS, route and authorization from the real client.
Approving the one connection that matters
Campux publishes the order API behind a Standard Load Balancer and Private Link Service. The shipping partner requests a private endpoint connection using the alias. Campux checks the subscription against its partner record and approves the Pending request. The partner then configures its API name to resolve privately and authenticates to the API. Campux verifies that no earlier public ingress still reaches it. An unknown subscription that can see the service may request too, but stays Pending unless someone approves it or adds it to auto-approval.
Approve one partner without skipping authentication
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Provider: shipping API behind supported internal load balancer Consumer: partner VNet and private endpoint Connection: pending approval API login: still required
Draw provider and consumer separately.
List approval, private DNS, route and application-authentication checks in order.
Predict the result after approval if the partner has no valid API credential.
Check your reasoning after you finish
Approval enables the private connection path; it does not grant API permission. The consumer must resolve the intended private endpoint and reach it. A request with no valid API credential should still be refused by the application.
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 partner creates a private endpoint targeting Campux's alias. Campux controls visibility and approval; the partner configures DNS and API authentication. Peering and a role in Campux's subscription are not required. Private Link Service does not add a new public route, but it also does not close an old one automatically.
C. This request is Pending, so it needs a provider approval before it can carry traffic. It does not become active by waiting or resolving the alias. A vetted subscription on an auto-approval list can skip Pending for a new request, but that is not what happened here. Approval permits a network path, not automatic API access.
Standard Load Balancer, up to eight NAT IPs, and a cross-region consumer endpoint. The existing provider API does not move through a Private Link setting; a closer deployment requires a second provider stack. An alias is not a secret, so open visibility can invite requests from unknown subscriptions. Those requests still need approval unless the subscription is on the provider's auto-approval list.
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" and add all
requesting subscriptions to auto-approval without review.
4. Hand today's partner the alias; they create a private
endpoint against it in their own subnet.
Line three. Open visibility alone only allows more subscriptions to request connections; it does not approve them. The dangerous addition is putting unverified subscriptions on the auto-approval list, which lets their connections become Approved without a review. Restrict visibility to known partner subscriptions when possible, and auto-approve only ones the provider has already vetted. The partner still needs DNS and API credentials after connection approval.
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.
Correct the two settings. Visibility decides who may request. “Anyone with the alias” widens that group but does not make their requests Approved. The alias is an identifier, not an API credential. Keep visibility restricted when the partner list is known and review Pending requests from outside any trusted auto-approval list.
Automate carefully. Put only vetted subscription IDs on a scoped auto-approval list. Their future connections can be approved automatically; other visible subscriptions still need manual approval. Keep API authentication and monitor connection changes, because Approved means a network path exists, not that every caller should see order data.
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 targets your alias with a private endpoint. Visible subscriptions outside the auto-approval list wait Pending for a provider decision.
- Visibility controls who can ask; approval controls which connections work. Neither replaces DNS or API authentication.
- 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. ↩ ↩
- Microsoft's Private Link Service overview states that visibility controls who can request, while auto-approval controls which vetted subscriptions connect without a manual provider decision. ↩
Distinguish Private Link Service visibility, approval, consumer DNS and API authentication, and explain regional and NAT limits.
Play the lesson above to stamp this class.