AWS PrivateLink Explained: VPC Endpoints Without the Internet

AWS PrivateLink lets one VPC consume a service in another VPC — or in an AWS-managed account — without traffic ever touching the public internet, without overlapping CIDR concerns, and without exposing the producer’s full network. It is the right answer when you want a single private door into one service, not a hallway connecting two networks.

What and Why

Three nouns to know.

• Interface VPC endpoint: an ENI in your subnet that forwards traffic over PrivateLink to a target service.
• Endpoint service: a producer-side construct that fronts a Network Load Balancer (or Gateway Load Balancer) and accepts connections from consumer endpoints.
• Service name: the DNS-style identifier consumers reference, like com.amazonaws.us-east-1.s3 or a custom com.amazonaws.vpce.us-east-1.vpce-svc-abc123.

Why use it? Because peering two VPCs gives the other side full IP-level reachability into your network, requires non-overlapping CIDRs, and grows messy across many tenants. PrivateLink exposes exactly one service on one port and nothing else. It also works across AWS accounts, across regions (via PrivateLink with Region peering), and into AWS-managed services like S3, KMS, ECR, and SQS.

Mental Model

Think of PrivateLink as a phone line, not a bridge. Peering is a bridge: both shores can drive cars across. PrivateLink is a phone line: a consumer dials a number and reaches one specific receptionist on the other end. They never see the rest of the producer’s office.

Mechanically, the consumer endpoint is a set of ENIs (one per AZ) with private IPs in the consumer’s subnets. AWS gives them friendly DNS names (vpce-abc.s3.us-east-1.vpce.amazonaws.com) and, optionally, takes over the public service hostname inside your VPC so existing SDK code “just works”.

Hands-on Example

Expose an internal API in account A to consumers in account B.

Producer side (account A):

# 1. Front your service with an internal NLB on TCP/443
aws elbv2 create-load-balancer --name svc-nlb --type network --scheme internal ...

# 2. Create an endpoint service in front of that NLB
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:...:loadbalancer/net/svc-nlb/... \
  --acceptance-required

# 3. Whitelist consumer principal
aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id vpce-svc-0abc... \
  --add-allowed-principals arn:aws:iam::222222222222:root

Consumer side (account B):

aws ec2 create-vpc-endpoint \
  --vpc-endpoint-type Interface \
  --vpc-id vpc-bbb \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-0abc... \
  --subnet-ids subnet-1a subnet-1b \
  --security-group-ids sg-consumer

The producer accepts the connection request; the consumer’s app dials the endpoint DNS name and reaches the NLB privately.

Consumer VPC (Account B)              Producer VPC (Account A)
+---------------------+               +-----------------------+
|  EC2 / Lambda app   |               |   App tasks behind    |
|        |            |               |   internal NLB:443    |
|        v            |               |          ^            |
|  Interface Endpoint |               |          |            |
|   ENI 10.0.1.20     |  PrivateLink  |   Endpoint Service    |
|   ENI 10.0.2.20     | ============> |   accepts request     |
+---------------------+   AWS fabric  +-----------------------+
     (DNS: vpce-abc.svc.vpce.amazonaws.com)
 No IGW, no NAT, no peering, CIDRs may overlap

For AWS-managed services, replace step 1 with picking the right com.amazonaws.<region>.<service> name. Enable “Private DNS” so SDK calls to s3.us-east-1.amazonaws.com resolve to the endpoint inside your VPC.

PrivateLink vs Peering vs Transit Gateway

• VPC peering: full IP reachability between two VPCs, no overlapping CIDRs, no transitivity. Best for two tightly-coupled networks.
• Transit Gateway: hub-and-spoke for many VPCs and on-prem; transitive routing. Best for enterprise networks.
• PrivateLink: one-way private access to a specific service. Best for SaaS-style or multi-tenant exposure, overlapping CIDRs allowed.

Common Pitfalls

• Forgetting security groups on the endpoint ENI. The endpoint ENI has its own SG; if it blocks the consumer subnet, connections die silently.
• Private DNS clash. Enabling “Private DNS” on more than one endpoint for the same service in the same VPC will fail. Pick one.
• Cross-AZ data transfer charges. PrivateLink charges per-AZ; if your consumers are in a different AZ from the endpoint ENI, you pay inter-AZ rates. Always create endpoints in every AZ you consume from.
• Endpoint not enabled in a subnet’s route table. Gateway endpoints (S3, DynamoDB) need a route-table association. Interface endpoints do not, but their subnets must have the right SG and NACL.
• Producer NLB health checks failing. PrivateLink only forwards to healthy NLB targets; misconfigured health checks make the endpoint appear “available” but every connection RST.

Production Tips

Tag every endpoint with the consuming service name so the bill makes sense — interface endpoints cost about USD 7.30 per AZ per month plus data. Audit endpoints quarterly; orphaned endpoints from decommissioned workloads are a stealth cost line.

For SaaS providers, automate the accept-or-auto-accept flow with EventBridge so customer endpoint requests don’t queue waiting on an engineer. Use endpoint policies to further restrict which IAM principals or actions are allowed through.

Combine PrivateLink with Route 53 Resolver rules to keep DNS clean across hybrid networks. Finally, monitor PacketsDropped on the endpoint ENI; nonzero values almost always point to a security-group misconfiguration.

Wrap-up

PrivateLink is the one-door-into-one-service primitive of AWS networking. Use it for SaaS-style exposure, cross-account access, and consuming AWS-managed services privately. Provision endpoints in every consumer AZ, mind the security groups and Private DNS, and prefer it over peering whenever the relationship is “give me this one service, nothing else”.