Private Endpoint

A private endpoint provides a private-address entry point in a consumer network for a supported service or resource. Azure implements it as a network interface in a subnet; AWS interface VPC endpoints provide a corresponding PrivateLink access mechanism. The endpoint does not mean the underlying managed service has moved into the customer’s subnet.

For the supported service path, AWS PrivateLink does not require an internet gateway, NAT device, public client address, Direct Connect, or site-to-site VPN. The client still needs working private connectivity, DNS, and access controls. Other application dependencies must be assessed separately.

What it actually buys you

Public destination addresses do not necessarily send traffic across the public internet. AWS documents that traffic between AWS network destinations stays on its global network, with exceptions for its China and European Sovereign Cloud Regions. Evaluate the actual path and controls instead of equating a public address with an internet transit path.

Private endpoints provide explicit service entry points and can support restricted private connectivity. Public endpoints can also enforce source-network and identity policies. Azure service endpoints, for example, keep public destination addresses while allowing service-side subnet restrictions without NAT. Compare the supported controls for the service rather than assuming that only a private address can restrict reachability.

• The service path can avoid internet egress. If all required dependencies have suitable private paths, a tier may not need an internet gateway or NAT. Inventory updates, identity services, telemetry, and other dependencies before removing shared egress. Endpoint charges may replace some NAT costs; compare the actual path.
• Public access remains a separate policy. The private path and public-access restrictions need separate configuration and tests, as the deployment sequence below shows.

Creating it does not close the public endpoint

Azure documents that a private endpoint supplies a private address without necessarily restricting public network access. Apply the service’s public-access controls separately and test them from a relevant outside location. Identity and authorization remain necessary on permitted paths.

For a migration, a staged sequence can preserve connectivity while the private path is verified. A new deployment can begin with public access restricted. In either case, establish and test the following conditions:

1. Create the endpoint in a suitable subnet and verify its target and approval state where the service requires approval.
2. Configure the application’s DNS and connection path to use the expected private endpoint for its location.
3. Verify from inside that clients actually use the private path.
4. Restrict public access according to policy and test both allowed private use and denied public use. Keep those tests separate so success on one path cannot conceal exposure on another.

For Azure Storage, Blob and File access require their respective subresource endpoints. Azure private endpoint connections must be approved before carrying traffic. Verify subresource coverage and connection state directly rather than assuming one successful connection covers the whole service.

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

Configure the service hostname according to the endpoint’s supported DNS design. A client using an unexpected public answer may follow a public route or fail. The relevant evidence is the address and path selected by the application, including any proxy, not only a lookup from an administrator’s shell.

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 VM, or the reverse; compare resolver settings, routes, rules, and proxies.
• It worked until a workload moved, or until someone changed a private DNS zone link.

Compare each location’s DNS response with the endpoint expected there. Different valid private endpoints may serve the same resource, so different answers are not automatically a fault. Identical test answers do not rule out an application cache, resolver, or proxy difference. Verify the actual destination, approval state where applicable, TCP establishment, TLS, and service response. A timeout and a refusal provide different evidence, but neither alone identifies every possible cause. Azure’s troubleshooting guide likewise checks application credentials after validating connectivity.

Treat private DNS zones and their links as owned infrastructure. Assess which clients a change affects and test resolution from their actual network contexts.

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.

A public endpoint can be appropriate when its supported network restrictions, identity controls, encryption, and operating arrangements satisfy the workload’s requirements. A private endpoint can be appropriate when private reachability or removal of internet egress is required. Data sensitivity and environment labels alone do not decide the architecture; compare the available controls, dependencies, cost, and verification plan.

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?
• AWS, What is AWS PrivateLink?
• AWS, How Amazon VPC works
• Microsoft Learn, Troubleshoot Azure Private Endpoint connectivity problems
• Microsoft Learn, Virtual network service endpoints