CH03-07: Private Endpoints and Private Access

Goal

The previous sections explained workload networks, routing, peering, hub-spoke design, and hybrid connectivity. This section explains how workloads privately reach supported Azure platform services.

The goal is to understand private endpoints as a private access pattern that includes both networking and DNS design.

Private access is easy to describe too simply. A private endpoint is not magic privacy dust sprinkled over a service. It changes how clients reach the service, which network path they use, and which name-resolution behavior they depend on.

The Short Version

A private endpoint gives a supported Azure service a private IP address inside a virtual network.

Private DNS helps clients resolve the service name to that private IP address.

The durable idea is:

A private endpoint gives an Azure service a private IP path, but DNS determines whether clients actually use that path.

Private endpoints reduce public network exposure, but they do not replace identity, authorization, encryption, service configuration, logging, or monitoring.

The Problem Private Endpoints Solve

Many Azure platform services can be accessed through service endpoints that are publicly reachable at the network layer unless restricted. Examples include storage accounts, databases, and key vaults.

Publicly reachable does not mean open to everyone. A storage account or database can still require authentication, authorization, encryption, firewall rules, and service-specific configuration. But for sensitive workloads, teams often want more than identity and service configuration. They want the network path itself to stay private.

Private endpoints help answer questions such as:

Can the application reach this Azure service through a private IP address?
Can we reduce or disable public network exposure for the service?
Can traffic stay on private Azure network paths?
Can on-premises systems reach the service through private hybrid connectivity?
Can DNS make the private path transparent to applications?

How a Private Endpoint Works

A private endpoint creates a network interface with a private IP address in a subnet of your VNet. That private IP represents access to a supported Azure service.

A simplified model looks like this:

Application subnet
        |
        | request: mystorage.blob.core.windows.net
        v
Private DNS resolves name to private IP
        |
        v
Private endpoint IP in VNet
        |
        v
Azure Storage account

The application may still use the normal service name, such as a storage account or database hostname. The important change is that DNS resolves that name to the private endpoint address instead of the public address.

That is why private endpoint design is also DNS design.

Why DNS Matters

Applications usually connect to services by name, not by hardcoded private IP address.

If DNS resolves the service name to the public endpoint, the client may try to use the public path. If DNS resolves the service name to the private endpoint IP, the client can use the private path.

Private DNS zones are commonly used with private endpoints. They let Azure resolve service names to private endpoint addresses for linked VNets. In hybrid environments, on-premises DNS may need forwarding or resolver design so on-premises clients also resolve names correctly.

This is where many private endpoint issues start. The private endpoint may exist. The subnet may be reachable. The service may be configured. But if clients resolve the wrong address, the design fails.

A useful troubleshooting habit is:

Before asking whether the network path works, ask what address the name resolves to.

Private Endpoint Placement

Private endpoints are placed in subnets. Some organizations use dedicated private endpoint subnets. Others place private endpoints closer to workloads. The right answer depends on scale, ownership, routing, DNS, policy, and operations.

A dedicated private endpoint subnet can make it easier to:

Apply consistent NSGs or route behavior where appropriate.
Track private endpoint resources.
Separate private access plumbing from application compute.
Standardize naming and ownership.
Troubleshoot service access paths.

But centralizing everything without a plan can create its own complexity. The design should make ownership visible. Who owns the private endpoint? The workload team? The platform team? The data service owner? The answer matters during incidents and changes.

Public Endpoint, Service Endpoint, and Private Endpoint

You may hear about public endpoints, service endpoints, and private endpoints. Do not let the names blur together.

At a high level:

Access Pattern	Plain-Language Meaning	Architecture Use
Public endpoint	Service is reachable through its public network endpoint, subject to identity, firewall, and service settings.	Useful when public reachability is acceptable and controlled.
Service endpoint	Extends VNet identity to some Azure service traffic while still using the service's public endpoint model.	Useful for some simpler network restrictions, but not the same as private IP access.
Private endpoint	Gives the supported service a private IP address in your VNet.	Useful when the service should be reached through a private network path.

This section focuses on private endpoints because they are a common architecture decision for sensitive workloads. The important distinction is that a private endpoint changes the network path to private IP access.

Private Access Does Not Replace Identity

A private endpoint controls the network path. It does not decide who is authorized to read a secret, query a database, or download a blob.

For example, an application may reach a storage account through a private endpoint. The storage account still needs:

Proper identity and authorization.
Public access settings aligned with the design.
Encryption settings.
Logging and diagnostic settings.
Data protection and lifecycle rules.
Monitoring and alerting.

Private access is one layer. It reduces exposure by making the network path private. The service still needs secure configuration.

Hybrid Private Access

Private endpoints become more interesting in hybrid environments.

Suppose an on-premises application needs to reach an Azure SQL database privately. The network path may look like this:

On-premises application
        |
        | VPN or ExpressRoute
        v
Azure hub network
        |
        v
Spoke VNet with private endpoint
        |
        v
Azure SQL database

The network path is only part of the design. The on-premises application also needs to resolve the database name to the private endpoint address. That may require DNS forwarding from on-premises DNS to Azure private DNS resolution.

If the on-premises client resolves the public address while Azure clients resolve the private address, troubleshooting can become confusing. A strong design makes name resolution predictable across environments.

Example: Private Access to Storage

Imagine a production application stores documents in Azure Storage. The documents are sensitive, and the organization does not want the storage account reached through public network paths.

A private endpoint design may include:

A private endpoint for the storage account in the workload VNet.
A private DNS zone linked to the VNet.
Storage account network settings aligned with private-only access intent.
Managed identity or another approved identity model for application access.
Monitoring and diagnostics for storage access.
On-premises DNS forwarding if on-premises systems need the same private path.

The application still uses the storage account name. DNS resolves that name to the private endpoint IP. Traffic follows the private path. Authorization still controls what the application can do with the data.

This is the difference between private reachability and complete security. You need both network path control and service-level access control.

Common Mistakes

Creating a private endpoint without planning DNS. The endpoint exists, but clients may still resolve the public address.
Assuming private endpoint access replaces authorization. The service still needs identity and access control.
Leaving public access enabled when the intent is private-only. Private access should align with service network settings.
Creating private endpoints one by one without standards. Naming, ownership, DNS, and troubleshooting become harder.
Forgetting on-premises name resolution. Hybrid clients need DNS behavior that matches the private path.
Treating service endpoints and private endpoints as identical. They are different access patterns with different architecture implications.

If Someone Asks You

If someone asks, "What is a private endpoint in Azure, and why does DNS matter?" a clear answer is:

A private endpoint gives a supported Azure service a private IP address inside a virtual network, so clients can reach the service through a private network path. DNS matters because clients usually connect to the service by name. The name must resolve to the private endpoint address for the client to use the private path. Private endpoints reduce public network exposure, but they do not replace identity, authorization, encryption, service configuration, or monitoring.

This answer explains the network path and avoids overstating the security benefit.

What You Should Remember

Private endpoints are private access paths to Azure platform services.

The most important idea is this:

Private access is a network path and a name-resolution design.

Design private endpoints with DNS, ownership, routing, hybrid access, and service configuration in mind. Otherwise, the private path may exist but not behave the way the architecture expects.

Questions to Check Your Understanding

What problem does a private endpoint solve?
Why does DNS matter for private endpoints?
Why does private access not replace identity and authorization?
How can on-premises clients use private endpoint paths?
What operational problems can private endpoint sprawl create?