Private Endpoints Explained

By default, talking from your VPC to managed services like S3, DynamoDB, or any SaaS goes out the NAT gateway, across the public internet, and back into the provider's network. That works, but it routes private data over a public network, racks up NAT gateway bills, and creates an attack surface every security team would prefer to close. Private endpoints — PrivateLink in AWS, Private Endpoints in Azure, Private Service Connect in GCP — give you a private IP inside your VPC that reaches the service without ever leaving the cloud provider's network.

The default vs private flow

PathDefault (public)Private endpoint
App → NAT gatewayYesNo
NAT → internet gatewayYesNo
Across public internetYesNo
To service endpointVia public IPVia private IP in your subnet
NAT data processing costYes, per GBNo (or much less)

The naming across clouds

  • AWS: PrivateLink (the broader technology), VPC Endpoints (gateway or interface), Endpoint Services (provider side).
  • Azure: Private Endpoint (customer side), Private Link Service (provider side), Service Endpoints (an older simpler variant).
  • GCP: Private Service Connect (PSC) for both customer and provider sides; older Private Google Access mode for first-party services.

Mechanics are similar across the three; naming and minor details differ.

How DNS makes it transparent

Without DNS magic, switching to a private endpoint would require code changes — your app would have to use a different hostname. The cloud handles this transparently:

  1. You create a private endpoint for, say, s3.us-east-1.amazonaws.com.
  2. The cloud creates a private DNS zone that overrides resolution for that hostname inside your VPC.
  3. Your app queries s3.us-east-1.amazonaws.com; the VPC resolver returns the endpoint's private IP.
  4. The app connects to that IP; traffic stays inside the cloud network.

The same code that previously used the public endpoint now uses the private one without modification.

Gateway vs interface endpoints (AWS specifics)

PropertyGateway endpointInterface endpoint
ImplementationRoute-table entryENI with private IP
Services supportedS3, DynamoDB onlyMost AWS services and third-party PrivateLink
CostFreePer-hour + per-GB processed
Cross-regionSame-region onlySame-region; cross-region possible via additional config
Cross-VPC sharingNoYes (via PrivateLink)

For S3 and DynamoDB, the gateway endpoint is the obvious choice — free and simpler. For other services, interface endpoints are required.

Security benefits

  • No public exposure path. Traffic does not traverse the public internet; an attacker would need to compromise the cloud provider's internal network to intercept.
  • VPC endpoint policies. You can restrict which IAM principals, which resources, or which conditions the endpoint allows. A typical policy: "only requests from this VPC can use this endpoint, only to specific S3 buckets."
  • Egress lockdown. With private endpoints for all needed services, you can remove the NAT gateway entirely and lock down all egress. Workloads can only reach explicitly endpointed services.

Cost considerations

The cost equation is nuanced:

  • NAT gateway data processing is ~$0.045/GB. Traffic to S3 through a NAT can cost a lot at high volume.
  • Interface endpoint is ~$0.01/hour per AZ + ~$0.01/GB. Cheaper than NAT for high-volume workloads; more expensive than NAT for low-volume.
  • Gateway endpoint is free.
  • Inter-AZ data transfer still applies even with private endpoints.

For high-traffic services (data lake reads, container image pulls), private endpoints pay for themselves quickly. For sporadic use, they cost more than the NAT alternative.

Cross-VPC and cross-account PrivateLink

The most powerful pattern: a service provider exposes their service via PrivateLink to specific consumer VPCs in different accounts. The provider sets up an endpoint service; consumers create interface endpoints that connect to it. The consumer reaches the provider over private IPs without any VPC peering, without any internet exposure, and without ever revealing IP ranges between the parties.

This is how Snowflake, Databricks, Datadog, MongoDB Atlas, and many other SaaS providers offer enterprise-grade private connectivity.

Limits and gotchas

  • Cross-region endpoints are limited. Most clouds require the endpoint and the service to be in the same region. Cross-region access usually means peering plus an endpoint in the target region.
  • DNS misconfig is the biggest source of bugs. If the VPC's DNS settings (enableDnsHostnames, enableDnsSupport in AWS) are off, the private DNS doesn't activate and traffic still goes public.
  • Subnet sizing. Each interface endpoint consumes IPs in your subnets. Plan accordingly.
  • Per-endpoint security groups. Interface endpoints have their own security groups that must allow traffic from your workloads. Easy to forget.
  • Per-service quotas. Some services limit how many endpoints per region or per account. For large fleets, plan around the quota.

When not to use private endpoints

  • Small workloads with low data volume — the hourly endpoint charge exceeds savings.
  • Services that only support public access (rare, but exists).
  • Cases where the application explicitly needs the public IP path (some health check or routing test patterns).

Frequently Asked Questions

What is a private endpoint?

A network interface inside your VPC that gives you a private IP address to reach a service that would otherwise be accessible only over the public internet. Traffic to the endpoint stays inside the cloud provider's network — never traverses the public internet — and the service appears as if it lived in your own VPC.

Why use private endpoints?

Three reasons. Security: traffic between your VPC and the service never touches the public internet, reducing exposure to interception, man-in-the-middle attacks, and exfiltration risk. Compliance: many regulated workloads require data not to traverse public networks. Cost: traffic over private endpoints typically avoids NAT gateway data-processing charges and inter-zone or inter-region data transfer fees.

What is the difference between gateway and interface endpoints in AWS?

Gateway endpoints are route-table entries that send traffic for specific services (S3, DynamoDB) through the VPC's internal infrastructure — no extra cost, no ENI in your subnets. Interface endpoints are full ENIs in your subnets with a private IP, used for most other services. Interface endpoints work everywhere gateway endpoints don't and support more advanced features (cross-VPC sharing, PrivateLink to third-party services), but cost per hour plus per-GB processed.

How does DNS work with private endpoints?

When a private endpoint is created, the cloud creates a private DNS zone (or hosted zone) that resolves the service's public hostname to the endpoint's private IP — but only for queries coming from inside the VPC. So the same application code that uses the public service URL now resolves to a private IP and routes privately. No code changes required.

Can I use PrivateLink to reach third-party SaaS?

Yes. PrivateLink (and its AWS, Azure, GCP equivalents) lets a service provider expose their service privately to specific customers. Snowflake, Databricks, Datadog, and many other SaaS providers offer PrivateLink endpoints — you create an interface endpoint in your VPC that connects to their service without going over the public internet.

Related Guides

More From This Section