Begin with the problem of services that live on public addresses, then see how a private address changes the story.

The problem

Most Azure platform services, such as a storage account or a SQL database, are reached through a name that resolves to a public internet address. Even when your own server sits inside a private network, its request to the storage account usually leaves through the network edge and enters the service’s public front door. That front door is open to the world, protected only by passwords, keys and firewall lists. If a key leaks, anyone anywhere can try to use it. Security teams dislike this, and many rules for regulated industries ask for private paths.

What the service is

Azure Private Link lets you access Azure platform services, and also services owned by partners or by your own teams, over a private endpoint: a network interface with a private address from your own virtual network. When your application connects to that address, the traffic stays on the Microsoft private backbone network. You can then switch off public access on the service entirely, so the only way in is through your private corridor.

What you gain

Private Link did not appear from nowhere. It answers weaknesses in earlier ways of connecting to platform services.

The public endpoint

Every platform service started with a public endpoint, a name and address reachable from anywhere. This is simple and works with every device and every country, which is why it is the default. The cost is exposure. Anything reachable from anywhere will be scanned, probed and tested by attackers within hours of existing.

Firewall rules on the service

The first improvement was a firewall built into the service. You could say “accept connections only from these public addresses.” That helps, but your own servers in the cloud may not have stable public addresses, and addresses can be shared or spoofed by mistakes in other layers. You were still talking across the public internet.

Service endpoints

Next came service endpoints. These let a subnet in your virtual network be listed as allowed on the service’s firewall, so traffic from that subnet to the service travels the Azure backbone and the service sees which subnet it came from. This was a real step forward and is easy to enable. But the service still has a public address. Your traffic is just given a better road to it. Also, service endpoints do not work from on-premises networks, and they apply to the whole service type in a region, not to one chosen resource.

Network injection

Some services, such as certain managed databases, can be deployed directly into your virtual network, taking addresses in a dedicated subnet. This gives full privacy but only for services built to be injected, and it needs larger address ranges and special subnets.

Private Link

Private Link takes a different path. Instead of giving the service a better route to a public address, it brings a private doorway for one specific resource into your network. The service resource gets an address in your own range. It works for a wide list of services with a common approach and also reaches from on-premises.

Each term below says what it is, why it exists, a picture from daily life and an example.

How the words fit together

Read it as a chain: a private endpoint in a subnet points to a Private Link resource through a group ID. A private DNS zone linked to the network makes the service name resolve to the endpoint’s private address. The application keeps using the same name it always used, but now it lands on the private corridor. When the owner has switched off the public network access, no other way remains.

Here is the full picture of how a private endpoint connects your network to a platform service.

flowchart LR
  subgraph VNET["Your virtual network"]
    APP["Application server"]
    subgraph PESUB["Private endpoint subnet"]
      PE["Private endpoint network interface"]
    end
    DNSR["DNS resolver"]
  end
  PDZ["Private DNS zone"] -.-> DNSR
  APP -->|"asks for service name"| DNSR
  DNSR -->|"returns private address"| APP
  APP -->|"connects to private address"| PE
  PE ==>|"Microsoft backbone"| SVC["Storage account or database"]
  PUB["Public endpoint of service"] -. "disabled by owner" .-> SVC

The private endpoint

It is a network interface that lives in a subnet you choose. It takes one private address, and it is linked to exactly one resource and one sub-resource. Think of it as a small receptionist’s desk in your building that forwards every call to one specific office elsewhere.

The platform side

On the service side, the resource keeps a list of private endpoint connections, each with a state such as pending, approved or rejected. Traffic from an approved endpoint is accepted. The service can also be told to refuse all public traffic, leaving the private endpoint as the only entrance.

The DNS part

A private DNS zone holds the record that maps the service name to the private address. The zone is linked to the virtual networks that need it. Without this link, name lookups return the public address and the private endpoint goes unused.

Supporting pieces

Three similar names cause endless confusion. Separating them makes every later chapter easier.

Private endpoint: the consumer side

A private endpoint is what you create in your network to reach a service. You are the consumer. It brings a remote service to a local private address. This is the most commonly used part of Private Link.

Private Link service: the provider side

A Private Link service is what you create when you want to offer something of yours to others. You put your application behind a standard load balancer, attach a Private Link service to it, and share its identifier. Consumers in other networks, even in other companies, create private endpoints that point to it. Their traffic reaches your load balancer without your service having a public address. You are the provider.

Service endpoint: the older neighbor

A service endpoint, as described earlier, is a routing and firewall feature. It uses the service’s public address but tells Azure to send traffic over the backbone. It is not part of Private Link, although people often compare them.

A simple rule to remember

If you want to use something privately, make a private endpoint. If you want to offer something privately, make a Private Link service. If you only want a simple, free improvement and you do not need to close the public door, a service endpoint may do.

Follow one request from an application to a storage account through a private endpoint.

sequenceDiagram
  participant APP as Application
  participant DNS as Private DNS
  participant PE as Private endpoint
  participant BB as Microsoft backbone
  participant SVC as Storage service
  APP->>DNS: Where is mystorage.blob.core.windows.net?
  DNS-->>APP: Private address 10.1.4.5
  APP->>PE: Open secure connection to 10.1.4.5
  PE->>BB: Forward over private path
  BB->>SVC: Deliver to approved resource
  SVC-->>BB: Response
  BB-->>PE: Return
  PE-->>APP: Response with service identity

Step by step

The name stays the same

A beautiful detail is that applications keep using the public service name. The magic is in DNS, which returns different answers to different askers. Inside the linked network, the answer is private. Outside, the answer is public (or nothing, if public access is off). This avoids changing certificates, since the secure connection is still made to the original name.

Source address seen by the service

The service sees the connection as arriving from the private endpoint’s resource, not from your server’s address. You cannot rely on the service’s log of the client address to identify the specific caller inside your network. Use your own network logs for that.

Encryption still applies

Private Link makes the path private, not the data automatically encrypted by itself. Services still use encrypted connections, and you should keep requiring them. Private path plus encryption plus authentication is the full set.

More Private Link problems come from DNS than from anything else. Learn this chapter well and most faults become easy to find.

What DNS does

DNS is the phone book of the internet. You give it a name and it returns an address. Without DNS, you would need to remember numbers for every service. In a Private Link design, the whole trick is that the same name returns a different address depending on who asks.

The chain of names

When you look up a storage name, the answer is a chain. The name you typed points to another name, which in turn leads to the final address. With Private Link, Azure adds a special middle step: the public name points to a name inside a special private-link zone. If your network has a private DNS zone for that area, the lookup finds the private address. If it does not, the lookup falls through to the public address.

flowchart TD
  Q["App asks for mystorage.blob.core.windows.net"] --> R{"Resolver linked to private DNS zone?"}
  R -->|"Yes"| P["Private zone returns 10.1.4.5"]
  R -->|"No"| U["Public DNS returns public address"]
  P --> OK["Traffic uses private endpoint"]
  U --> X{"Public access allowed on service?"}
  X -->|"Yes"| PUBP["Traffic uses public internet path"]
  X -->|"No"| FAIL["Connection refused"]

Private DNS zones

Azure suggests standard zone names for each service type, such as one zone for blob storage, another for SQL databases and another for key vaults. You create the zone, link it to every virtual network that must resolve the private name, and the endpoint adds a record. Using the standard names matters, since they match what the service expects in the chain.

Zone groups

With a zone group on the endpoint, the platform creates and updates the record in the chosen zone automatically. This removes human error when endpoints are created, replaced or have an address change. It is the preferred approach.

Where the lookup comes from

A virtual machine in a virtual network asks the DNS server configured for that network. If it is the default Azure resolver, and the network is linked to the zone, it gets the private answer. If it is a custom DNS server, that server must itself be able to ask Azure’s resolver, or it will return public answers. This is the most common cause of “it worked in the portal, but my server uses the public address.”

Test with a lookup

From the machine that has the problem, look up the service name using a standard lookup tool. If the answer is a private address from your range, DNS is right. If it is a public address, fix DNS before you touch anything else.

A private endpoint connection moves through states, and knowing them explains many surprises.

stateDiagram-v2
  [*] --> Pending: request created
  Pending --> Approved: owner approves
  Pending --> Rejected: owner rejects
  Approved --> Disconnected: owner removes or resource deleted
  Rejected --> Pending: request again
  Disconnected --> [*]
  Approved --> Approved: traffic flows

Automatic and manual approval

When you own both the endpoint and the service, or have the right permissions, the connection is approved automatically at creation. When the service belongs to someone else, or you lack that right, the connection starts as pending until the owner approves. This is a deliberate safety step: the owner of the service decides who may connect.

Creating an endpoint

Changing and replacing endpoints

An endpoint cannot be moved to another subnet. To change subnets, you create a new endpoint, switch, and delete the old one. Plan the cutover so DNS is updated cleanly and old records do not linger. Using a zone group helps keep records matched to the live endpoint.

What deletion does

If the endpoint is deleted, its address is released and the DNS record should be removed. If the service resource is deleted, the connection becomes disconnected. Clients will then fail until you rebuild the pieces. Keep deletion under change control.

Private Link works with a long and growing list of Azure services. The list changes often, so treat the tables here as examples and verify the current list.

Why sub-resources matter

Many services have several parts that are reached through different names. A storage account has blob, file, queue, table and other parts. Each needs its own private endpoint with its own group ID and DNS zone. If you create one for blob only, file access still uses the public path or fails when public access is off.

These are examples only. Names of zones and group IDs are published in the official documentation, and they should be copied from there rather than guessed.

Services with extra considerations

Checking support before designing

Before promising a private design to a team, confirm in the documentation that the service supports private endpoints, in your region, at your chosen pricing tier. Some tiers of some services do not. Discovering this late can force a service upgrade or a redesign.

The provider side lets you offer your application to other networks without a public address.

The pieces

You run your application on servers behind a standard internal load balancer. You create a Private Link service attached to the load balancer’s frontend. The service uses one or more addresses from a subnet, called NAT addresses, to represent incoming consumer traffic. Consumers create private endpoints that point to your service’s identifier, called its alias, and you approve them.

flowchart LR
  subgraph CONS["Consumer network"]
    CAPP["Consumer application"] --> CPE["Private endpoint"]
  end
  subgraph PROV["Provider network"]
    PLS["Private Link service with NAT addresses"] --> ILB["Standard load balancer"]
    ILB --> S1["App server 1"]
    ILB --> S2["App server 2"]
  end
  CPE ==>|"private backbone"| PLS

Why use it

Software companies use it to offer private connections to customers without sharing network ranges. Large organizations use it between departments that have overlapping address ranges, because the NAT step hides the consumer’s real addresses. Platform teams use it to share a central service, such as a license server or an internal API, with many spokes.

Overlapping address ranges

Two networks with the same address range normally cannot be connected. With Private Link service, the consumer only sees an address from its own range, and the provider sees addresses from its NAT range. Neither needs to know the other’s ranges, which is a big help when joining networks built independently.

Controlling access

You decide who may connect by subscription visibility lists and by manual approval. Auto-approval can be given to trusted subscriptions, and everyone else must wait for approval. Review the list of connections regularly.

Seeing the consumer

Because of the NAT step, your servers see the NAT addresses, not the consumer’s real addresses. If you need to know the original address, there is an option to pass it along using a header protocol, which your application must be able to read. Check the documentation for the details and limits.

Limits and sizing

Private endpoints are network citizens. They need space, sensible filtering and correct routes.

A subnet for endpoints

You can place endpoints in any subnet, but many teams create a dedicated subnet for them. Each endpoint uses one address, and some services need several addresses for one logical endpoint. Size the subnet with room to grow. A separate subnet lets you apply a clear set of network rules to all endpoints in one place.

Network policies for endpoints

Historically, network security groups and user-defined routes did not apply to private endpoint traffic. A subnet setting now lets you enable network policies so that security groups and routes affect the endpoints. With it on, you can filter who may reach each endpoint and send the traffic through a firewall. Check the current behavior and the exact setting for your case.

Hub-and-spoke designs

flowchart TD
  subgraph HUB["Hub network"]
    FW["Firewall"]
    DNSH["DNS resolver"]
    PEH["Shared private endpoints"]
  end
  subgraph SP1["Spoke 1"]
    A1["Applications"]
  end
  subgraph SP2["Spoke 2"]
    A2["Applications"]
  end
  A1 --> FW
  A2 --> FW
  FW --> PEH
  A1 -.-> DNSH
  A2 -.-> DNSH
  PDZ["Private DNS zones linked to hub and spokes"] -.-> DNSH
  PEH ==> SVC["Platform services"]

Central or local endpoints

Routing through a firewall

If you want a firewall to inspect traffic to endpoints, add routes that send the endpoint addresses to the firewall. Return traffic must come back the same way, or the firewall will drop it. With network policies enabled, a more specific route to the endpoint address is respected. Test carefully because asymmetric paths cause confusing faults.

Peering and reach

Machines in peered networks can reach an endpoint if routes and rules allow it. The endpoint does not need to be in the same network as the client. DNS, however, must be linked or forwarded for each network that needs the private name.

Offices and data centers can use the same private corridors, if the path and the names are arranged correctly.

The path

Your on-premises network connects to Azure through a site-to-site VPN or a dedicated private circuit. Once connected, on-premises machines can send traffic to the private address of an endpoint just as they would to any Azure server, provided that routes are advertised both ways and firewalls allow it.

The name

The path is the easy part. The names are harder. On-premises DNS servers know nothing about your private DNS zones in Azure. If an office machine asks for the storage name, its normal DNS returns the public address. To fix this, create a conditional forwarder on the on-premises DNS server that sends questions for the service’s name area to a resolver inside Azure. That resolver, linked to the private zones, returns the private address.

sequenceDiagram
  participant PC as Office computer
  participant ODNS as On-premises DNS
  participant ARES as Azure DNS resolver
  participant PDZ as Private DNS zone
  participant PE as Private endpoint
  PC->>ODNS: Lookup service name
  ODNS->>ARES: Conditional forward for service area
  ARES->>PDZ: Query linked private zone
  PDZ-->>ARES: Private address
  ARES-->>ODNS: Private address
  ODNS-->>PC: Private address
  PC->>PE: Connect over VPN or private circuit

Which forwarding zone

The recommended forwarding name is the special private-link name of the service, rather than the plain public name. Forwarding the plain public name can break access to other, non-private resources in the same area. Read the current guidance in the documentation to select the right zone name for each service.

The Azure resolver

You need something in Azure that can answer forwarded questions. Options include a managed private DNS resolver service with an inbound address, or a DNS server running on a virtual machine that forwards to the Azure resolver. A managed resolver reduces upkeep.

Common hybrid problems

Private Link improves security in several ways. The biggest is controlling where data may flow.

Closing the public door

The simplest benefit is turning off public network access on the service. After that, an attacker with a stolen key still cannot connect from the internet, because there is no public path to try. The attacker would need to be inside your network or one connected to it.

Data exfiltration

Data exfiltration means data being copied out of your control, whether by an attacker or by a careless insider. With public access and service endpoints, a compromised server inside your network might copy files to any storage account in the same service, including one owned by the attacker, because the route allows the whole service type. A private endpoint points to one specific resource. The only storage account reachable over that private path is the one you chose. This shrinks the places data can be sent.

Combined with other controls

What Private Link does not do

It does not authenticate users, scan content, or stop a trusted insider from misusing allowed access. It does not replace encryption, role-based access or monitoring. It narrows the paths and removes the public one. A weak password on an application still lets an inside attacker in.

Control of who can create endpoints

Creating a private endpoint is a powerful act, since it opens a path to a service. Restrict the permission to create endpoints, review them in audits and alert on new ones. An attacker with enough rights might create an endpoint to their own resource to move data out, so watch for unexpected connections to unknown resources.

A private network path is only one lock. Good governance makes sure the doors, keys and visitors are all managed.

Role-based access

Azure role-based access control decides who can create, change and approve endpoints. Give network engineers the right to create endpoints in network resource groups, give service owners the right to approve connections on their resources, and give auditors read access. Splitting these duties prevents one person from both creating a path and approving it.

Approvals across teams

When one team wants a connection to another team’s service, the request arrives as a pending connection. The service owner reviews: who is asking, which subscription, which network and why. Approve, reject, and record the reason. A shared list of approved consumers is useful for audits.

Azure Policy

Policies are rules that Azure itself enforces. Useful examples include: deny creation of storage accounts with public access, require that selected services have private endpoint connections, audit endpoints that are not linked to the standard private DNS zones, and require that endpoints exist in approved subnets. Policies can also deploy missing DNS records automatically. They turn good intentions into automatic checks.

Naming and tags

Name endpoints in a consistent way that shows the service, the sub-resource, the environment and the region. Tag them with owner, cost center and application. A good name lets anyone read the purpose from the list.

Change control

Deleting a DNS zone link or an endpoint can take down an application instantly. Use resource locks on shared DNS zones and endpoints that production relies on. Apply changes through infrastructure code with review. Keep the earlier version available for quick rollback.

Documentation

Write down the standard design: where DNS zones live, who owns them, which networks are linked, how on-premises forwarding works and who may approve what. A short document with a diagram saves hours during incidents and onboarding.

Private endpoints are simple, but they have limits worth knowing before you plan a large estate.

Bandwidth and latency

A private endpoint is not a separate machine with its own throughput cap that you must size. It is a path through the platform. Practical speed depends on the service, on the client, and on any firewall or gateway in the path. Latency is normally very close to the public path because both ride the same backbone, and sometimes better because there are fewer hops at the edge. If you send traffic through a firewall in a hub, that firewall adds its own delay and capacity limit.

Connection counts and ports

For the Private Link service side, NAT addresses limit the number of simultaneous connections per consumer. For heavy use, add more NAT addresses so the pool of ports is larger. Watch connection counts on the load balancer.

Number of endpoints

Each network, each subscription and each service resource has maximum counts of endpoints and connections. Large estates with thousands of resources can reach them. The documentation lists the numbers, and they change over time, so check them while planning, not after the first failure.

Address space

Every endpoint takes at least one address from its subnet, and some take more. A subnet that seemed generous can fill up as teams add endpoints for each storage part, each database and each vault. Reserve ranges and keep a record of use.

A worked sizing example

The numbers below are illustrative, not limits. Suppose a company has 30 applications, and each needs private access to a storage account with three parts (blob, file and queue), a database server and a key vault. That is 5 endpoints per application, or 150 endpoints. If each uses one address and you add a growth margin of 40 percent, you need about 210 addresses. A subnet with 256 addresses has some reserved by Azure, which leaves slightly fewer usable, so choose a larger range, such as one holding 512, or use a few subnets. Compare this plan with the real current limits per network.

Shared endpoints reduce counts

If many applications use the same storage account or vault, one shared endpoint in a hub serves all. This cuts counts but raises the shared-fate risk, as discussed before.

Private paths must keep working when parts fail. Consider where each piece can break.

The endpoint itself

A private endpoint is a platform-managed construct and is built to be resilient inside its region. It does not need you to run two of them for redundancy against ordinary hardware faults. Its availability follows that of the underlying platform and the service it connects to.

The service behind it

If the service is zone-redundant or geo-replicated, the endpoint reaches the primary location. For cross-region recovery, you need an endpoint for the secondary resource in the secondary region too, plus DNS arrangements that make clients switch. Many services offer a failover that changes which resource a name points to; check how that interacts with private DNS records, because the private record must follow the failover.

DNS is part of availability

If the resolver or the private zone is unavailable, names do not resolve and applications fail even though the endpoint is healthy. Use redundant resolvers, keep DNS zones in resilient configurations, and monitor lookups. Many large outages in private designs were DNS outages.

Regional design

flowchart LR
  subgraph RA["Region A"]
    APPA["Applications"] --> PEA["Private endpoint to primary storage"]
  end
  subgraph RB["Region B"]
    APPB["Standby applications"] --> PEB["Private endpoint to secondary storage"]
  end
  PEA ==> PRIM["Primary storage account"]
  PEB ==> SEC["Secondary storage account"]
  PRIM -. "replication" .-> SEC
  PDZ["Private DNS zones linked to both regions"] -.-> APPA
  PDZ -.-> APPB

Failure modes to expect

When a private connection fails, a calm routine finds the cause quickly. Almost always it is DNS, routing or a rule.

What to watch

A troubleshooting walk

Common error pictures

Private Link adds charges to the bill. Knowing the parts lets you predict and manage them. Prices change, so use the official calculator for real numbers.

A worked monthly example

The numbers below are invented to show the method. Suppose an endpoint costs 0.01 dollars per hour. A month of 730 hours is 7.30 dollars per endpoint. With 150 endpoints, that is 150 times 7.30, or 1,095 dollars. If total traffic through all endpoints is 10 terabytes, which is 10,000 gigabytes, at an illustrative 0.01 dollars per gigabyte, data charges are 100 dollars. DNS zones and queries might add 20 dollars. The total is about 1,215 dollars per month. If you consolidate to 60 shared endpoints in a hub, the hourly part falls to 60 times 7.30, or 438 dollars, though you might add a firewall’s cost and peering transfer.

Ways to reduce cost

Share endpoints where isolation does not demand separate ones. Avoid creating endpoints for unused sub-resources. Delete endpoints for retired services. Keep test endpoints out of long-running test environments. Review traffic: very chatty workloads send a lot of data through endpoints, and moving components closer together may cut both cost and delay.

Compare against the risk

A private endpoint costs a few dollars a month. Compared with the cost of a data breach, the price is small. The aim is not to avoid private endpoints, but to avoid waste, such as forgotten test endpoints and duplicated copies.

Private Link is powerful, but it is not always the right tool. Choose by what you need to achieve.

flowchart TD
  S["Need private access to a platform service"] --> A{"Must close the public door?"}
  A -->|"Yes"| PL["Use Private Link"]
  A -->|"No"| B{"Need access from on-premises?"}
  B -->|"Yes"| PL
  B -->|"No"| C{"Only need a better path from Azure subnets?"}
  C -->|"Yes"| SE["Service endpoint is simple and free"]
  C -->|"No"| D{"Service can be deployed into your network?"}
  D -->|"Yes"| INJ["Consider network injection"]
  D -->|"No"| PL

Private Link and a firewall

They work well together. Private Link brings the service inside your network, and a firewall decides which servers may use which endpoint. Without a firewall or security rules, any machine in the network that can route to the endpoint address can use it.

Private Link and web gateways

A web gateway can use a private endpoint to reach a back-end web app, so the web app has no public door and the gateway is the only entrance. This pattern is common for public sites whose back ends must stay private.

An honest look at what the service does well and where it brings complications.

Key trade-offs

Finding the balance

Choose private access first for sensitive data: databases, vaults, storage holding personal or financial records. For low-risk public content, the extra complexity may not pay off. A risk-based list of which services must be private keeps the design focused.

Successful teams repeat a few designs. Struggling teams repeat a few mistakes. Naming both makes them easy to copy or avoid.

Patterns that work

Anti-patterns to avoid

A checklist to apply before any private design goes live.

Best practices

Common mistakes

Walk through the failures in advance, and recovery becomes routine.

Scenario one: everything fails after closing public access

A team disables public access on a storage account and several jobs stop. Cause: some clients, like a build server in another network, still resolve to the public address. Recovery: temporarily re-enable public access with a narrow network rule, link the zone to that network, then close again. Prevention: a client inventory and a staged rollout starting with logging only.

Scenario two: the zone link was deleted

Someone cleans up unused links and removes one that was in use. Applications in that network begin to see public addresses and fail. Recovery: restore the link. Prevention: resource locks, policy and alerts on changes to DNS links.

Scenario three: on-premises users get the public address

Office machines cannot reach the private service. Cause: a missing conditional forwarder on one office DNS server. Recovery: add the forwarder and flush caches. Prevention: configure all offices from one template and test from each site.

Scenario four: a pending connection stays pending

A new team’s endpoint to another team’s database never works. Cause: the connection waits for approval and no one noticed. Recovery: the owner reviews and approves. Prevention: an approval process with notifications and a response time target.

Scenario five: failover moves the service but not the clients

A database fails over to a secondary region, but applications keep connecting to the primary’s private address. Cause: the private record still points to the old endpoint. Recovery: update the record or use a failover-aware name arrangement. Prevention: design and rehearse DNS changes as part of failover tests.

Scenario six: a rogue endpoint

Audit logs show a new endpoint to an unknown storage account in an unusual subscription. Action: investigate who created it and why, remove it if unauthorized, review the account used, and check firewall logs for data sent through it. Prevention: restrict who may create endpoints and alert on every creation.

flowchart TD
  A["Client cannot reach service"] --> B{"Lookup returns private address?"}
  B -->|"No"| C["Fix zone link, custom DNS forwarding or on-premises forwarder"]
  B -->|"Yes"| D{"Connection approved?"}
  D -->|"No"| E["Ask service owner to approve"]
  D -->|"Yes"| F{"Port reachable?"}
  F -->|"No"| G["Check routes, security groups and firewall"]
  F -->|"Yes"| H["Check identity, keys and roles"]
  C --> I["Retest and confirm in logs"]
  E --> I
  G --> I
  H --> I

Most real projects add Private Link to a system that already runs. A careful sequence avoids outages.

Use logs to find clients

Before closing, service logs show the source of each request. Requests that come from public addresses reveal clients that are not yet private. Fix these first. This evidence-based approach is far safer than guessing.

Pilot first

Start with one low-risk service and one application. The pilot reveals the DNS and approval problems unique to your organization, so later waves go faster.

Communicate

Tell developers, support teams and partners about the date and about the new way to connect. Provide a short guide: how to reach the service from a laptop, whom to ask for access, and where to find the status page.

These are typical, invented scenarios that show the ideas at work. They are not reports about any named company.

What they share

Each example treats DNS as a first-class part of the design, closes the public door only after checking every client, uses policy to keep the result in place, and watches the logs. The corridor works because it is planned and checked.

Three services account for most private endpoint projects. Each has small habits worth knowing in advance.

Storage accounts

Storage is the service with the most parts, so it creates the most endpoints. List which parts your applications really use. A data lake needs the blob part and the data lake part. A file share needs the file part. Static websites use the web part. Create only the endpoints you need, and give each its own zone link. Also remember that tools which copy data between accounts, such as migration utilities, run from a machine that must itself resolve and reach the private addresses of both accounts.

Databases

A database server usually needs one endpoint. Clients connect using the server name and their normal sign-in. One surprise is the connection mode: some database services redirect clients to a different address after the first handshake, and in a private design that redirect must also stay on the private path. Read the documentation for the connection policy that suits private endpoints, and test with the real application driver, not only with a test tool.

Key vaults

A vault holds the keys to everything else, so it is the first candidate for private access. Many services read secrets at start-up, and if a vault is private but the application subnet cannot resolve its name, the application fails to start. This can look like a deployment failure when it is really DNS. When you protect a vault, make sure the services that need it at start-up, such as build pipelines and scaling systems, are covered by the private path.

Common companions

A simple order of work

Start with monitoring and the vault, since they support everything else. Then do storage, then databases, then the rest. At each step, verify with a lookup and a real connection, and keep public access on until the logs show no public clients.

Short answers to common questions. Where a detail may have changed, confirm in the current Microsoft documentation.

Private Link brings cloud services into your network by giving them private addresses, so that traffic stays on the Microsoft backbone and the public door can be closed.