AWS PrivateLink
Private, one-way connectivity from your VPC to a service — no internet gateway, NAT, or peering.
Verified against AWS documentation · 2026-08-24
Key facts
- 01An interface endpoint is an ENI with a private IP in your subnet; DNS points the service hostname at it, so app code doesn't change
- 02Consumer-initiated only — the provider answers requests but can never open a connection back into your VPC
- 03Works across accounts and overlapping CIDRs because nothing is routed; there is no peering, no route table entry, no IP coordination
- 04Gateway endpoints (S3 and DynamoDB only) are a route table entry, are free, and are NOT PrivateLink — this is the #1 exam trap
- 05Limits: TCP only, one ENI per AZ per endpoint, 50 interface/GWLB endpoints per VPC (adjustable), 10 Gbps per AZ scaling to 100 Gbps
Exam triggers
Phrases and scenarios that point here.
- "Without traversing the public internet", "no internet gateway or NAT gateway" → interface endpoint
- A SaaS vendor must expose its service privately to customer VPCs → endpoint service behind an NLB
- Two VPCs with overlapping CIDRs need to share one service → PrivateLink, because peering is impossible
- Cheapest private access to S3 or DynamoDB from a private subnet → gateway endpoint, not interface
- On-premises over Direct Connect or VPN needs private access to an AWS API → interface endpoint (gateway endpoints don't work from outside the VPC)
Not this service
- Bidirectional, any-port reachability between two VPCs → VPC Peering or Transit Gateway
- Free private access to S3 or DynamoDB from inside the VPC → Gateway endpoint
- General outbound internet access for OS patching or third-party APIs → NAT Gateway
Use cases
- 01Reaching a vendor SaaS (Snowflake, Datadog, MongoDB Atlas) from private subnets while the VPC has zero egress path to the internet
- 02Publishing an internal platform service — shared auth, payments, feature flags — to other business units whose VPCs all sit on the same 10.0.0.0/16, where peering is off the table. Watch for the source-IP gotcha: your targets see the NLB's IPs unless you enable Proxy Protocol v2
- 03Stripping the NAT Gateway out of a compliance-heavy account entirely, then adding interface endpoints only for the APIs the workload actually calls (STS, KMS, Secrets Manager, SSM) and locking each one down with an endpoint policy
- 04Cutting NAT data processing on chatty container fleets — ECS/EKS tasks pull through ecr.api and ecr.dkr interface endpoints, with layer downloads riding the free S3 gateway endpoint
- 05Giving an on-premises data centre private access to SQS, Kinesis, or Secrets Manager over Direct Connect instead of routing API calls out to the public endpoints
How it's charged
- 01Billed per endpoint, per AZ, per hour — a three-AZ endpoint carries three hourly charges whether or not a single byte flows, and partial hours bill as full hours
- 02Plus a per-GB data processing charge on everything through the endpoint, regardless of direction, tiered down at regional volume
- 03Gateway endpoints for S3 and DynamoDB cost nothing — no hourly, no per-GB
- 04The consumer pays the endpoint charges; the provider pays for its own NLB and its own data processing
- 05The NAT replacement decision is arithmetic, not doctrine: per-GB savings have to clear the hourly cost of every endpoint × AZ you provision, and a sprawl of idle endpoints across accounts can cost more than the NAT Gateway it replaced
