Skip to content

AWS PrivateLink

AWS PrivateLink connects a VPC to services outside it over private IP addresses, without a peering connection, an internet gateway or a NAT device. It is implemented with interface VPC endpoints: requester-managed network interfaces placed in your subnets, carrying private addresses from your own address space.

Traffic between an endpoint and the service it reaches stays on the AWS network and never traverses the public internet.

  1. Create private subnets in the VPC — endpoint interfaces belong in private subnets, since there is no reason to expose them.
  2. Create the interface endpoint, selecting one subnet per Availability Zone. AWS places an endpoint network interface in each.
  3. Attach a security group to the endpoint that allows the expected traffic, typically HTTPS from the VPC CIDR block.
  4. Leave private DNS enabled so that the service’s normal hostname resolves to the endpoint’s private addresses, and applications need no configuration change.
  5. Optionally attach an endpoint policy to restrict which principals and actions the endpoint will carry.
  • AWS service endpoints that support PrivateLink — a long list including API Gateway, Amazon SNS, Amazon SQS, AWS KMS, CloudWatch and Amazon S3.
  • Endpoint services published by another AWS account, including your own accounts.
  • Applications behind a Network Load Balancer or a Gateway Load Balancer in a provider VPC.
  • AWS Marketplace services offered over PrivateLink.
  • Individual resources shared from another VPC — a database, an EC2 instance, an IP address — through a resource endpoint, which needs no load balancer.
  • A whole VPC Lattice service network through a service-network endpoint.

Interface endpoints are no longer confined to a single Region. When creating an endpoint for an AWS service you can enable a cross-Region endpoint and select the Region the service runs in, so a VPC in one Region can reach a supported service in another Region of the same AWS partition over PrivateLink.

Gateway endpoints, which are a different mechanism, remain same-Region only.

Plan for the difference in practice: a cross-Region endpoint keeps the traffic on the AWS network, but it does not remove the latency of crossing between Regions, and data transfer is charged accordingly.

AWS Marketplace and SaaS. A vendor publishes an endpoint service; you create an interface endpoint and call their API over a private address. No credentials or traffic cross the internet, and there is no shared address space to reconcile.

Service-to-service across accounts. One team exposes a single service through an endpoint service rather than peering two VPCs. The consumer reaches exactly that one service, and nothing else in the provider’s VPC becomes reachable. This is the main reason to prefer PrivateLink over peering: peering joins networks, PrivateLink publishes a service.

Applications outside AWS. An endpoint service backed by a Network Load Balancer can front targets reached over Direct Connect or VPN, so a consumer VPC gets a private path to an application that is not in AWS at all.

  • Traffic remains on the AWS network backbone.
  • No internet gateway, NAT gateway or public IP address is needed on the consumer side.
  • Access is controlled twice: by the security group on the endpoint interfaces, and by the endpoint policy on the endpoint itself.
  • The provider controls who may connect through the endpoint service’s allowed-principals list, and accepts or rejects each connection request.

Interface endpoints are billed per endpoint-hour per Availability Zone plus per gigabyte processed. That is a real cost at scale, and it is the reason gateway endpoints — which are free — remain the right choice for straightforward Amazon S3 and DynamoDB access from within a VPC.

AWS’s networking blog has a worked design that uses PrivateLink to centralise outbound web filtering behind an explicit proxy: How to use AWS PrivateLink to secure and scale web filtering using explicit proxy.