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
| Path | Default (public) | Private endpoint |
|---|---|---|
| App → NAT gateway | Yes | No |
| NAT → internet gateway | Yes | No |
| Across public internet | Yes | No |
| To service endpoint | Via public IP | Via private IP in your subnet |
| NAT data processing cost | Yes, per GB | No (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:
- You create a private endpoint for, say,
s3.us-east-1.amazonaws.com. - The cloud creates a private DNS zone that overrides resolution for that hostname inside your VPC.
- Your app queries
s3.us-east-1.amazonaws.com; the VPC resolver returns the endpoint's private IP. - 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)
| Property | Gateway endpoint | Interface endpoint |
|---|---|---|
| Implementation | Route-table entry | ENI with private IP |
| Services supported | S3, DynamoDB only | Most AWS services and third-party PrivateLink |
| Cost | Free | Per-hour + per-GB processed |
| Cross-region | Same-region only | Same-region; cross-region possible via additional config |
| Cross-VPC sharing | No | Yes (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
All Cloud Networking Guides
VPCs, peering, NAT, transit gateways, egress costs, and load balancers.
Cloud DNS Architecture
How cloud DNS actually works — VPC resolvers, private hosted zones, conditional forwarding to on-prem, split-horizon…
Cloud Egress Costs Explained
Cloud egress pricing explained — AWS, Azure, GCP rates, inter-AZ vs inter-region, NAT processing, VPC endpoints,…
Run a Speed Test
Measure download, upload, ping, and jitter in your browser.