What Is AWS PrivateLink? How It Works and When to Use It

Simple explanation

Without PrivateLink, resources in your private subnets reach AWS services like SSM or Secrets Manager by routing through a NAT Gateway to the service’s public IP. PrivateLink removes that path. Instead, an interface endpoint sits directly in your own subnet: it is a network interface with a private IP address. Traffic flows from your resource to the endpoint, then through AWS’s private infrastructure to the service.

The most important thing to understand before going further: PrivateLink gives private access to a specific service, not full private network-to-network connectivity. If you need two VPCs to communicate broadly with each other, that is a different problem solved by VPC peering or Transit Gateway.

Why teams use AWS PrivateLink

• Security and compliance. Regulated workloads (healthcare, financial services, government) often require that service traffic never use public IP addressing. Interface endpoints satisfy this without adding architectural complexity.
• Private access from private subnets. Resources in private subnets normally need a NAT Gateway to reach AWS services. Interface endpoints eliminate that dependency for the specific services you configure them for, reducing NAT processing costs and removing a single point of failure for private workloads.
• Limiting exposure to one service, not a full network path. When you share a service across accounts or VPCs, PrivateLink exposes only that one service endpoint. The consumer cannot see or reach anything else in your VPC. There is no network-level access granted.
• Overlapping CIDR ranges. If your VPCs have overlapping IP address ranges, VPC peering is not possible. PrivateLink works regardless of CIDR overlap because it operates at the service level, not the network routing level.

How AWS PrivateLink works

PrivateLink has two sides: a consumer and a provider.

• Consumer: the VPC that wants to access a service. You create an interface endpoint in one or more subnets in your VPC.
• Provider: the entity exposing the service. For built-in AWS services, AWS is the provider. For your own services, you create an endpoint service backed by a Network Load Balancer in your VPC.

When you create an interface endpoint, AWS deploys an Elastic Network Interface (ENI) into the subnet you specify. That ENI gets a private IP address from your subnet’s CIDR range. Traffic flow once the endpoint is in place:

1. Your application calls the service using its standard hostname (for example, ssm.us-east-1.amazonaws.com).
2. If private DNS is enabled on the endpoint, Route 53 Resolver inside your VPC returns the private IP of the endpoint ENI instead of the service’s public IP.
3. Traffic goes from your resource to the ENI, then through the AWS backbone directly to the service.
4. No internet gateway and no NAT gateway are in this path.

Interface endpoints have security groups attached to the ENI, just like any other network interface. The security group controls which resources in your VPC can send traffic through the endpoint. For most AWS services, you need an inbound rule allowing HTTPS (port 443) from the instances or services that will use the endpoint.

You can also restrict what actions consumers are allowed to perform through an endpoint using an endpoint policy: an IAM-style resource policy attached to the endpoint itself. By default, endpoints allow all traffic; endpoint policies let you scope that down.

When to use AWS PrivateLink

A common practical example: enabling Systems Manager Session Manager on EC2 instances in private subnets. Session Manager requires reaching three AWS endpoints: SSM, SSM Messages, and EC2 Messages. Without interface endpoints, your instances need internet access to reach those services. With PrivateLink, everything stays private without adding internet access to private subnets.

Cross-account service sharing is another strong fit. Instead of peering VPCs and exposing entire networks, you put your service behind a Network Load Balancer, create an endpoint service, and let consumers connect through PrivateLink. They reach only your service. Nothing else in your VPC is visible to them.

When not to use AWS PrivateLink

Interface endpoints vs gateway endpoints

Gateway endpoints work by adding an entry to your route table that intercepts traffic destined for S3 or DynamoDB and redirects it through the gateway rather than through the internet path. No ENI is created. DNS for the service still resolves to a public IP; the route table intercepts the traffic before it can leave your VPC.

For S3 and DynamoDB: start with gateway endpoints. They are free, and for single-VPC access they cover almost every use case. Only switch to interface endpoints for S3 or DynamoDB if you specifically need cross-VPC or cross-account private access.

AWS PrivateLink vs VPC Peering vs NAT Gateway

This is the decision most beginners need help making. Each option solves a different connectivity problem.

The simplest way to choose: if you need to access one specific service privately, use PrivateLink. If two VPCs need broad two-way connectivity and their CIDRs do not overlap, use peering. If workloads need to reach the public internet, use a NAT Gateway. PrivateLink does not replace that path.

Common real-world use cases

Systems Manager access from private subnets

EC2 instances in private subnets cannot reach SSM endpoints without a route to the internet. Creating interface endpoints for ssm, ssmmessages, and ec2messages enables Session Manager and other SSM features to work entirely within the AWS private network.

# Create interface endpoint for SSM
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.ssm \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-private-1a subnet-private-1b \
  --security-group-ids sg-ssm-endpoint \
  --private-dns-enabled \
  --tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=ssm-endpoint}]'

# Repeat for ssmmessages and ec2messages
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.ssmmessages \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-private-1a subnet-private-1b \
  --security-group-ids sg-ssm-endpoint \
  --private-dns-enabled

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.ec2messages \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-private-1a subnet-private-1b \
  --security-group-ids sg-ssm-endpoint \
  --private-dns-enabled

Consuming a third-party or cross-account private service

Many SaaS vendors and internal platform teams expose their services via PrivateLink. You create an interface endpoint pointing to their endpoint service name, and all traffic flows privately. The vendor never gains access to your VPC, and you never expose your workloads to their network. CIDR overlap between your VPC and theirs is not a concern.

Exposing your own service to other AWS accounts

Put your service behind a Network Load Balancer, create an endpoint service pointing to the NLB, and share the service name with consumers in other accounts. They create interface endpoints and connect privately. You control who can connect with allow-list entries on the endpoint service, and you can require manual approval for each new consumer.

# Create an endpoint service backed by your NLB
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/internal-nlb/abc123 \
  --acceptance-required \
  --tag-specifications 'ResourceType=vpc-endpoint-service,Tags=[{Key=Name,Value=my-endpoint-service}]'