Skip to main content
AWS PrivateLink lets a VPC consume a service through private IP addresses without exposing the service to the public internet and without joining the two networks through broad routing. Updated October 9, 2026. The consumer sees an interface VPC endpoint in its own subnets. That endpoint creates elastic network interfaces with private addresses. Traffic enters those interfaces and reaches the provider service over the AWS network. Suppose a platform team runs an internal API in one VPC and dozens of application teams need to call it from other VPCs. The teams could use public HTTPS, VPC peering, a transit gateway, or a VPN. Each option creates a different boundary. Public HTTPS keeps networks separate but requires a public endpoint. Peering and transit routing provide private connectivity, but they also connect address spaces and require route management. Overlapping CIDR blocks can prevent simple routing. PrivateLink exposes one service rather than an entire network. Consumers do not need routes to the provider VPC, and the provider does not need routes back to every consumer CIDR.

​
How the connection works

For a service you own, the provider usually places a Network Load Balancer in front of the service and publishes a VPC endpoint service. The consumer creates an interface endpoint in selected subnets.
For AWS services, AWS operates the provider side. You create an interface endpoint for services such as Secrets Manager, ECR API, or CloudWatch Logs where supported. Private DNS can map the service’s normal hostname to the private endpoint addresses inside the VPC. The application can keep using the normal SDK hostname while its traffic stays on the private path. PrivateLink is not general network connectivity.
  • It does not make every host in the provider VPC reachable.
  • It does not provide transitive routing between connected networks.
  • It does not replace application authentication or authorization.
  • It does not automatically make a service highly available across zones.
  • It does not remove the need for security groups and endpoint policies.
The endpoint has security groups that control traffic reaching its ENIs. Supported AWS services can also use endpoint policies to restrict which actions or resources consumers may access. PrivateLink is especially useful for internal platform services, partner integrations, and software delivered to customer VPCs. It creates a narrow service boundary that scales independently of consumer CIDR plans.

​
Cost and availability

Interface endpoints have an hourly charge in each Availability Zone and a data-processing charge. Creating many endpoints for low-traffic services can cost more than sending traffic through a shared NAT gateway. High-volume AWS service traffic may favor endpoints by avoiding NAT processing, but you must calculate both paths. Create endpoints in the zones where consumers run if zonal availability matters. DNS may return endpoint addresses across zones, and cross-zone behavior can affect resilience and transfer cost depending on the design.
Private does not mean free or automatically secure. Review endpoint policies, security groups, DNS behavior, zonal placement, and cost before treating an endpoint as complete.

​
When to use it

Use PrivateLink when you want to expose a service, not a network. It is a strong fit when:
  • Consumer and provider CIDR ranges overlap.
  • Many accounts need the same private service.
  • You want no inbound routes from consumers into the provider VPC.
  • A workload should reach an AWS API without general internet egress.
  • The service boundary should remain stable while networks change.
If two VPCs need broad, bidirectional connectivity, peering or a transit gateway is usually clearer. If the service is already a secure public API, a public endpoint may be simpler. PrivateLink earns its place when the narrow private boundary is valuable enough to justify the extra endpoints and cost.

​
Frequently asked questions

​
Sources and further reading

Last modified on October 8, 2026