Private Endpoint

A private endpoint is a network interface inside your own subnet that fronts a managed service, so the service is reached at an address in your network rather than at a public one. AWS describes the capability as letting you “privately connect your VPC to services and resources as if they were in your VPC.” Descriptions here follow the AWS documentation, checked in September 2026.

The operational consequence is stated plainly in the same documentation: “you do not need to use an internet gateway, NAT device, public IP address, Direct Connect connection, or AWS Site-to-Site VPN connection to allow communication with the service or resource from your private subnets.” A subnet with no path out can still use the service.

What it actually buys you

The benefit is usually explained as keeping traffic off the internet, and that framing is imprecise enough to cause bad arguments. Within one provider, traffic between resources frequently stays on the provider’s own network already: AWS states that packets originating on its network with a destination on its network “stay on the AWS global network” — “whether the destination is a private IP address or a public IP address,” with named regional exceptions.

The real gain is control over reachability, and the documentation draws exactly that conclusion: “therefore, you control the specific API endpoints, sites, services, and resources that are reachable from your VPC.” That control is what a public endpoint cannot offer, and it shows up in two places.

• No egress path is required. You can remove the internet gateway and NAT device entirely for that tier, which eliminates a whole class of accidental exposure and a recurring NAT charge.
• Reachability becomes an allowlist — once you also close the public door. That second step is separate, and skipping it is the most common way this goes wrong.

Creating it does not close the public endpoint

Azure states the limit plainly: private endpoints “provide a privately accessible IP address for the Azure service, but don’t necessarily restrict public network access to it,” and other services “require additional access controls.” Your clients now take the private path; anyone else can still reach the service at its public address if nothing was changed there.

So creating the endpoint is the beginning of the work rather than the whole of it. The full sequence, and the order matters because each step is verifiable only after the one before:

1. Create the endpoint in the subnet.
2. Make name resolution return its address — separate DNS settings are required, and “the settings must resolve to the private IP address of the private endpoint.”
3. Verify from inside that clients actually use the private path.
4. Restrict public network access on the service itself, then verify from outside that the public path is refused. Without this test, “private connectivity” has been demonstrated only from the side that was always going to work.

A couple of details save a second attempt at that sequence. Subresources need their own endpoints — for storage, “separate private endpoints to access the file and blob subresources” — so one endpoint does not cover a service’s other entry points. And traffic flows only after approval: “only private endpoints in an Approved state can send traffic,” so a pending connection presents exactly like a routing fault.

The same mechanism works beyond the provider’s own services. Interface endpoints can front a service hosted by another account or a partner offering, which is how one organization exposes an API to another without either side opening a path to the internet.

DNS is the other half, and it is where this fails

The endpoint gives the service an address in your network. Your application still asks for the service by its normal hostname. Unless resolution inside the network returns the private address, requests take the public path — or fail outright if you have already removed it.

Certain symptoms make resolution worth checking first, because they are what a per-location resolver difference looks like. They do not establish it as the cause — a route table, a network security group, a peering gap, or a service-side access rule can differ between locations in exactly the same way.

• It works from one subnet and not another.
• It works from a container or function and not from a virtual machine, or the reverse — different resolver configuration.
• It worked until a workload moved, or until someone changed a private DNS zone link.

So test resolution explicitly — what address does this hostname return here — rather than only testing whether a connection succeeds. If the two locations return different addresses, or a public one where a private was expected, that is the answer. If they return the same private address and only one connects, resolution is settled and the cause is elsewhere: check the connection’s approval state, then whether TCP establishes at all, then TLS, then what the service itself answers. A timeout and an immediate refusal point in different directions, and Azure’s own troubleshooting guidance sends you to application-layer credentials once the network checks pass.

Beyond the specific hostname, treat private DNS zones as owned infrastructure: they are shared state, and one team’s change to a zone link breaks name resolution for everyone using it.

What it costs, and when a public endpoint is fine

Private endpoints are typically billed per endpoint per hour plus data processed, and they consume addresses in your subnet. At scale — many services, many networks — that becomes both a line item and an address-planning input. There is also more to operate: each endpoint is a resource with its own lifecycle, and the DNS configuration is an extra dependency in every incident.

Given that, a public endpoint remains a reasonable choice when the service’s own firewall can restrict source networks, when the data is not sensitive, or in development environments where the operational overhead is not justified. The decision worth avoiding is the unexamined one — reaching a production data store over an egress path nobody chose deliberately.

Worth heading off the confusions that credit this control with work it does not do. A private endpoint is a network control, not an authorization one: identity and permissions still decide what a caller may do once connected, which is why least privilege is unaffected by it. And it says nothing about where data physically sits — data residency is a separate constraint that a private connection to a service in another region does not satisfy.

How private endpoints fit with subnets, routing, DNS, on-premises connectivity, and transfer cost is worked through in The Route Table Nobody Read.

References: Microsoft Learn, What is a private endpoint? (documentation updated 2026-08-11); AWS, What is AWS PrivateLink?; AWS, How Amazon VPC works; Microsoft Learn, Troubleshoot Azure Private Endpoint connectivity problems.