A private endpoint is a network interface with a private IP address inside a customer’s virtual network that connects privately to a managed cloud service, such as a storage account, a database or a partner API. In cloud networking, it lets workloads reach platform services without traversing the public internet and often without the service having any public exposure at all.
The concept appears under different names. Microsoft Azure uses the term Private Endpoint with Azure Private Link, AWS provides interface VPC endpoints powered by AWS PrivateLink, and Google Cloud offers Private Service Connect endpoints. The underlying idea is the same: the service appears as a local IP address in the consumer’s VPC or virtual network.
How a private endpoint connects to a service
When a private endpoint is created, the provider places an elastic network interface in a chosen subnet and assigns it an address from that subnet’s range. Traffic sent to this address travels over the provider’s backbone network to the target service, which sees the request as coming from the private link connection rather than from a public IP address.
Connectivity is one-directional by design. Clients in the consumer network can open connections to the service, but the service cannot initiate connections back into the consumer network. This property makes private endpoints useful for exposing services between separate organizations or accounts without peering entire networks.
| Component | Role | Where it lives |
|---|---|---|
| Endpoint network interface | Holds the private IP address clients use | Consumer subnet |
| Private link service | Publishes the target behind a load balancer | Provider side |
| Private DNS zone | Resolves the service name to the private IP | Consumer DNS configuration |
| Approval workflow | Lets the service owner accept or reject connections | Provider resource settings |
| Security group or policy | Filters which clients may reach the interface | Consumer network |
DNS resolution is the critical detail
Applications usually connect to a managed service by its public fully qualified domain name, not by IP address. For traffic to use the private endpoint, that same name must resolve to the private IP address inside the network. Providers solve this with private DNS zones that override public resolution for clients in linked networks.
In hybrid environments, on-premises DNS servers must forward the relevant zones to a cloud resolver, for example a DNS forwarder or an inbound resolver endpoint. Without this forwarding, on-premises clients resolve the public address and either bypass the endpoint or fail when public access is disabled. Misconfigured DNS is the most frequent cause of private endpoint failures.
Private endpoints compared with related options
Several mechanisms restrict how resources in a VPC reach cloud services. They differ in where traffic goes, which IP address the service sees and how granular access can be.
| Mechanism | How it works | Reachable from on-premises | Granularity |
|---|---|---|---|
| Private endpoint | Private IP in the consumer subnet | Yes, through VPN or dedicated link | One specific service instance |
| Gateway endpoint | Route table entry to a regional service | No | Whole service, filtered by policy |
| Service endpoint | Optimized route from a subnet, public IP retained | No | Service type, restricted by firewall rules |
| Cloud NAT | Outbound translation to public addresses | Not applicable | Any internet destination |
| VPC peering | Joins two networks at the routing level | Depends on transit design | Entire address ranges |
Private endpoints are the strongest of these options for data exfiltration control, because each endpoint maps to a single resource instance. A compromised workload cannot simply use the same path to copy data into a storage account owned by an attacker, which gateway or service endpoints alone do not always prevent.
Designing private endpoint deployments
In larger estates, private endpoints are usually placed in a hub-and-spoke topology: a central hub network hosts shared endpoints and DNS zones, while spoke networks route through it. This keeps the number of endpoints and DNS records manageable.
| Decision | Common choice | Reason |
|---|---|---|
| Public access on the service | Disabled after endpoint validation | Removes the internet attack surface |
| Endpoint placement | Dedicated subnet per region | Simplifies address planning and policies |
| DNS zone ownership | Central platform team | Avoids conflicting records across teams |
| Multi-region services | One endpoint per region | Keeps traffic local and resilient |
| Access control | Security groups plus service policies | Defense in depth at network and identity layers |
Costs consist of an hourly charge per endpoint plus a per-gigabyte data processing fee in most providers. For high-volume data flows such as backups or analytics exports, this processing fee can become significant and should be estimated before migration.
Limitations and common mistakes
A private endpoint secures the network path only. It does not replace authentication, authorization or encryption in transit, and the service still enforces its own identity controls.
- Leaving public access enabled, so the service remains reachable from the internet in parallel.
- Duplicate private DNS zones for the same service, which cause inconsistent resolution.
- Overlapping IP ranges between networks, which block routing to the endpoint address.
- Forgetting endpoint quotas, since providers limit endpoints per network or subscription.
- Testing only by IP address, which hides DNS problems that appear once applications use hostnames.
Some managed features also behave differently behind a private endpoint. Portal consoles, monitoring agents or service-to-service integrations may expect public reachability, so disabling public access can break them unless each dependency is checked and routed through its own endpoint or a trusted-service exception.
In everyday language
A private endpoint gives a cloud service a private doorway inside a company’s own network. Instead of reaching a database or file storage over the public internet, servers talk to it through an internal address that only the company’s network can use.
It is like a building with a private corridor straight to the bank vault, instead of walking outside along a public street to the front entrance. The service stays reachable for the people who need it and invisible to everyone else.
Seen in the real world
A health insurance company moves its claims processing system to the cloud. Regulators and internal policy require that patient data never travels over the public internet. The team creates private endpoints for the managed database and the document storage account in a dedicated subnet of the hub network, links the private DNS zones and configures on-premises DNS forwarding.
After testing that every application resolves the service names to private addresses, they disable public network access on both services. Auditors can now verify that the data stores accept connections only from approved networks, and a later penetration test confirms that the services are unreachable from outside the corporate network.