Here's an awkward truth from Lesson 1: when your private-subnet task calls S3, Secrets Manager, or DynamoDB, those APIs live on public AWS endpoints. So by default the call goes out through your NAT gateway toward "the internet" — even though the destination is AWS itself, possibly in the same building. You pay NAT processing fees for the privilege, and your security story includes a path to the public network you never wanted.
VPC endpoints fix this: they bring the AWS API inside your VPC, so the traffic never leaves the private network. There are two kinds, and they work completely differently.
Watch the path change
Private task → AWS service
Pick a destination and a path, then make the call. Watch the route — and the meter. The NAT numbers are real order-of-magnitude AWS pricing.
calls made
0
GB through NAT
0.0
NAT processing cost
$0.000
traffic left the VPC?
—
The two kinds, and why the difference matters
Gateway endpoint
Only two services: S3 and DynamoDB
Implemented as a route table entry — the S3 prefix list routes to the endpoint instead of the NAT
Free. No hourly fee, no per-GB fee
No ENI, no IP, no security group — it's pure routing
Only reachable from inside the same VPC
Interface endpoint (PrivateLink)
Nearly every other AWS service — Secrets Manager, ECR, CloudWatch, SQS…
Implemented as an ENI with a private IP in your subnet
Costs per hour per AZ + per GB
Has its own security group — you control who may use it (Lesson 2 applies!)
DNS magic: secretsmanager.eu-central-1.amazonaws.com resolves to the private ENI IP inside your VPC
The classic incident this prevents: a fully private ECS task fails to start with "unable to pull secrets" or "cannot pull container image." No NAT, no endpoints — the task simply cannot reach Secrets Manager or ECR at all. The fix is either a NAT gateway (money, public path) or interface endpoints for exactly the services the task needs (tighter, and each endpoint's SG limits who can call it). If subnets have no internet path by design, endpoints aren't an optimization — they're the only way AWS APIs work at all.
PrivateLink: the same trick, for anyone's service
Interface endpoints are built on PrivateLink, and PrivateLink is not AWS-only. Any provider can put a Network Load Balancer in front of their service and publish it as an endpoint service. Consumers then create an interface endpoint to it in their own VPC — and consume the product over private IPs, with no peering, no route table exchange, no CIDR coordination, and no visibility into each other's networks. Overlapping CIDRs? Irrelevant — PrivateLink is a one-way keyhole, not a bridge.
This is how serious B2B SaaS is delivered to security-conscious customers: the customer's data never crosses the public internet, and neither side exposes its network. If you ever productize "connect privately to our platform," PrivateLink is the mechanism — and "supports PrivateLink" is a checkbox enterprise buyers actively look for.
Check yourself
1. Your data pipeline moves 10 TB/month from S3 into private-subnet workers via a NAT gateway. The quickest large cost win?
NAT processing at ~$0.045/GB on 10 TB is ~$450/month for traffic that never needed the NAT. A gateway endpoint is a route table change, costs nothing, and the transfer becomes VPC-internal. This is one of the most common easy wins in an AWS bill.
2. What's the key security difference between an interface endpoint and a gateway endpoint?
A gateway endpoint is a route — anything in the VPC with that route can use it (you'd use endpoint policies to restrict). An interface endpoint is a network interface wearing a security group, so the "who can talk to what" toolkit from Lesson 2 applies directly to the AWS API itself.
3. A vendor offers their API over PrivateLink. Your VPC's CIDR overlaps with theirs. Problem?
This is PrivateLink's superpower over peering. You get an ENI with an IP from your range; their network is never routed into yours. Overlap is a non-issue — which matters, since half the world uses 10.0.0.0/16.