Let’s cut to what matters. Azure Private Endpoint takes a PaaS service — something that normally lives on the public internet with a public IP — and gives it a private IP address inside your Virtual Network. Once that’s in place, the service behaves like any other resource on your network. No public routing. No internet exposure.
If you’re building toward a Zero Trust architecture, or studying for the AZ-104 or AZ-305 exams, this is one of those topics you can’t afford to skim. It touches multiple layers of Azure Networking, including DNS, security design, and hybrid connectivity.
What Is Azure Private Endpoint? #
Azure Private Endpoint is a network interface that sits in your VNet and connects privately to an Azure PaaS service through Azure Private Link. It’s essentially a NIC with a private IP that acts as a secure doorway into a resource that would otherwise only be reachable over the internet.
Why it exists: #
Public endpoints work, but they come with baggage. Even behind firewall rules, the public surface area is still there. Private Endpoint removes that surface entirely. It’s how you enforce zero-trust networking at the resource level, and it’s what makes secure hybrid access from on-premises networks actually practical.
The relationship with Azure Private Link: #
These two get confused a lot. Private Link is the platform capability — the infrastructure that makes private connectivity possible. Private Endpoint is the thing you actually deploy: a NIC in your subnet, mapped to a specific service. One is the engine, the other is the steering wheel.
How Azure Private Endpoint Works #
When you create a Private Endpoint, Azure provisions a NIC inside your subnet and wires it to a specific PaaS resource instance. Not the service broadly — one particular storage account, one particular database.
The connection flow: #
- You deploy the Private Endpoint into a subnet
- It claims a private IP from that subnet’s address range
- A dedicated link is established to the target PaaS instance through Private Link
- DNS resolves the service’s FQDN to that private IP instead of the public one
- Traffic flows over the Microsoft backbone. No internet hop.
Here’s the part that trips people up: if DNS isn’t configured correctly, your client resolves to the public IP and bypasses the Private Endpoint entirely. No error. No warning. Just traffic going out over the internet while you think it’s private.
Key Features #
- Genuine private access — the PaaS resource gets a real IP on your network, not just a firewall exception
- Data exfiltration protection — the endpoint maps to one specific resource instance, so a compromised workload can’t redirect data to an attacker-controlled account on the same service
- Network isolation without public IPs — the resource doesn’t need to be internet-facing at all
- Hybrid connectivity — on-premises systems reach the private IP over ExpressRoute or VPN, same as any other internal resource
Supported Azure Services #
The list keeps growing, but these are the ones you’ll work with most:
- Azure Storage — Blob, File, Queue, Table
- Azure SQL Database
- Azure Cosmos DB
- Azure Key Vault
- Azure App Service
Most major PaaS offerings support Private Link at this point. For anything not listed here, check the Azure documentation — Microsoft adds new services regularly.
Private Endpoint vs Service Endpoint #
This comparison comes up on every Azure networking exam. Both improve how your VNet talks to PaaS services, but they solve the problem differently.
| Feature | Service Endpoint | Private Endpoint |
|---|---|---|
| Network path | Optimized route over Azure backbone | Traffic stays in your private VNet |
| IP type | Service keeps its public IP | Private IP from your subnet |
| Security level | Medium — public endpoint still exists | High — public endpoint can be disabled |
| DNS required | No | Yes — and this is where things break |
| Data exfiltration protection | Limited | Strong — scoped to a single resource |
Selection logic: #
Service Endpoints make sense when you want a quick, free way to keep VNet-to-service traffic on the Azure backbone. No DNS to manage, no extra cost.
Private Endpoints are the answer when the requirements get serious — on-premises access, compliance mandates, zero-trust enforcement, or any scenario where “the public endpoint still technically exists” isn’t acceptable.
Architecture Design Considerations (AZ-305 Focus) #
Common design patterns: #
In a hub-and-spoke topology, centralize your Private DNS Zones in the hub VNet. Link them to each spoke. This avoids zone sprawl and keeps DNS management in one place — which matters a lot more than you’d think once you’re running dozens of Private Endpoints across multiple subscriptions.
Dedicated subnets for Private Endpoints are worth the minor overhead. They simplify NSG rules, make routing predictable, and keep your architecture auditable.
Trade-offs to consider: #
There’s no getting around it: Private Endpoints add complexity. DNS configuration alone can consume hours of troubleshooting if something’s off. And unlike Service Endpoints, they’re not free — you’re paying hourly charges plus data processing fees. The security gains are real, but so is the operational cost.
Hybrid and multi-region scenarios: #
For hybrid setups, Private Endpoints let on-premises servers reach PaaS services over VPN or ExpressRoute through a routable private IP. That’s straightforward enough.
Multi-region gets trickier. You need region-aware DNS designs that handle failovers cleanly. A storage account with geo-redundancy, for instance, needs DNS that points to the right Private Endpoint in each region without introducing latency during failover. Plan this early — retrofitting it later is painful.
Architecture Diagram Flow (Text Description) #
Core Components: #
- Virtual Network with a dedicated subnet
- Private Endpoint (the NIC holding a private IP)
- Target Azure PaaS resource
- Private DNS Zone
- Client VM initiating the connection
The Routing Flow: #
Your client VM queries DNS for mydb.database.windows.net. The Private DNS Zone — linked to the VNet — intercepts that query and returns the private IP (say, 10.0.1.5). Traffic routes locally to the Private Endpoint NIC, Azure’s backbone carries it to the service, and the response comes back the same way. At no point does anything touch the public internet.
Private Endpoint DNS Configuration (Critical) #
This deserves its own section because DNS is where Private Endpoint deployments fail. Not sometimes. Most of the time. The Private DNS Zone’s entire purpose is to override the service’s public FQDN and resolve it to your private IP instead.
Example zone: privatelink.blob.core.windows.net
The resolution flow: #
- Client requests the standard service URL —
mystorage.blob.core.windows.net - Public DNS returns a CNAME pointing to
mystorage.privatelink.blob.core.windows.net - Your Private DNS Zone (linked to the VNet) resolves that to the private IP
- Traffic stays internal
If step 3 doesn’t happen — because the zone isn’t linked, or doesn’t exist, or the client is using a custom DNS server that doesn’t know about it — the query falls through to public DNS. You get the public IP back. Traffic goes out over the internet. And nothing tells you this is happening.
Common mistakes to avoid: #
Forgetting the VNet link. The Private DNS Zone must be linked to every VNet where clients need private resolution. This is the single most common misconfiguration.
Custom DNS servers without forwarding. If your VNet uses Active Directory DNS or another custom resolver, those servers need a conditional forwarder for privatelink.* queries pointing to 168.63.129.16. Without it, the Private DNS Zone is invisible.
Typos in the zone name. Each service has its own privatelink.* suffix. Get one character wrong and resolution fails silently.
AZ-104 Exam Focus (Operational) #
The AZ-104 tests whether you can actually do this, not just describe it.
Configuration knowledge is essential — you should be comfortable deploying a Private Endpoint through the portal, selecting the right sub-resource, and enabling DNS integration.
DNS validation comes up repeatedly. Know how to run nslookup from a VM and interpret whether the result is a private or public IP.
Troubleshooting scenarios are the bread and butter of AZ-104 Private Endpoint questions. “A VM can’t reach a storage account after enabling Private Endpoint” almost always comes down to DNS — a missing zone link, a custom DNS server that isn’t forwarding, or a zone with the wrong name.
AZ-305 Exam Focus (Design) #
The AZ-305 expects you to think like an architect, not an operator.
Decision-making is the core skill here. You need to articulate why you’d choose a Private Endpoint over a Service Endpoint for a given set of requirements — and when the simpler option is actually the right one.
Security enforcement patterns matter. Can you design an environment where public access is disabled by default across all PaaS resources? Azure Policy makes this possible, and the exam expects you to know how.
Scalability and governance round things out. How do you manage Private DNS Zones across 50 subscriptions in a hub-spoke topology? Where do the zones live? Who owns the VNet links? These are the kinds of design questions AZ-305 throws at you.
Real-World Use Cases #
Regulated workloads. A healthcare organization running patient data in Azure SQL with zero public exposure. The database’s public endpoint is disabled. Period. Access comes exclusively through Private Endpoints from authorized VNets.
Hybrid cloud. On-premises legacy applications that need to reach Azure Key Vault for secrets management. Private Endpoint gives them a routable private IP over ExpressRoute — no application changes, no public internet dependency.
Zero Trust enforcement. Azure Policy denying creation of any storage account that lacks an associated Private Endpoint. Combined with disabled public access and NSG rules, every data path is explicitly authorized and auditable.
Step-by-Step Setup (Azure Portal) #
Step 1: Create your VNet #
Define your address space and carve out a subnet specifically for Private Endpoints. Keeping them separate from your VM subnets makes life easier down the road.
Step 2: Deploy the PaaS resource #
Create your target service — a storage account, SQL database, whatever you’re securing. No special configuration needed yet.
Step 3: Create the Private Endpoint #
Go to the resource’s Networking blade → Private endpoint connections. Select your VNet and dedicated subnet. Choose the sub-resource type (e.g., blob, sqlServer). Toggle DNS integration on.
Step 4: Configure DNS #
Verify that Azure created the Private DNS Zone with the correct privatelink.* name. Confirm the zone is linked to your VNet. Check that an A record exists pointing to the private IP.
Step 5: Validate Connectivity #
From a VM in the VNet:
nslookup storageaccount.blob.core.windows.net
You should see a private IP — something in your subnet’s range. If a public address comes back, your DNS configuration needs work.
Best Practices #
- Dedicated subnets for Private Endpoints. It simplifies NSG management and makes your network topology easier to reason about during audits or incident response.
- Always configure and link Private DNS Zones. This isn’t optional. Without them, the Private Endpoint exists but doesn’t actually get used.
- Disable public access on the PaaS resource once you’ve confirmed the private path works. Leaving both doors open defeats the purpose.
- Layer your defenses. NSGs on the Private Endpoint subnet, Azure Firewall for inspection if needed, Azure Policy to enforce that new resources always get Private Endpoints. No single control is enough on its own.
Troubleshooting #
DNS resolving to public IPs: #
Start with the basics. Is the Private DNS Zone linked to the VNet where the client lives? Does the zone actually contain an A record for the resource? If the client uses a custom DNS server, is that server forwarding privatelink.* queries to 168.63.129.16? Nine times out of ten, one of these three things is the answer.
Connection timeouts: #
Check the Private Endpoint’s connection state in the portal. If it says “Pending,” someone needs to approve it — this happens when the target resource is in a different subscription or the owner configured manual approval.
Also verify the PaaS resource’s own firewall settings. Some services have a resource-level firewall that can block traffic even when it arrives through a Private Endpoint, especially if “deny all” rules are in place without an exception for the VNet.
NSG traffic drops: #
This one has a gotcha. NSGs on Private Endpoint subnets only take effect if PrivateEndpointNetworkPolicies are enabled on the subnet — and that setting is off by default. Enable it first, then check your rules. Make sure outbound from the client and inbound on the required ports (443, 1433, etc.) aren’t being caught by deny rules.
Summary #
Azure Private Endpoint is how you bring PaaS services inside your network perimeter. Private IP, no public exposure, traffic that never leaves the Microsoft backbone. The security model is strong — but only if DNS is configured correctly. That’s the piece that makes or breaks every deployment.
If you’re studying for the AZ-104, spend your time on DNS troubleshooting and portal-based configuration. Know how to validate that nslookup returns a private IP, and know what to check when it doesn’t.
For the AZ-305, zoom out. Understand when Private Endpoints are the right architectural choice versus Service Endpoints, how to enforce private-only access through policy, and how to design DNS governance for hub-spoke environments at scale. The exam rewards candidates who can reason through trade-offs, not just recite features.