5.5 AWS PrivateLink and Endpoint Services
Key Takeaways
PrivateLink provides private connectivity to services using interface endpoints — Elastic Network Interfaces with private IPs inside your subnet.
Interface (PrivateLink) endpoints are billed per hour plus per GB and target most AWS services; Gateway endpoints are free and serve only S3 and DynamoDB.
A provider exposes a service behind a Network Load Balancer as a VPC Endpoint Service; consumers create interface endpoints to reach it.
PrivateLink is unidirectional (consumer → provider) and tolerates overlapping CIDRs because no VPC-level routing occurs between the networks.
PrivateLink needs no VPC peering, Internet Gateway, NAT, or VPN, and scales to thousands of consumer VPCs per service.
Quick Answer: AWS PrivateLink gives private connectivity to AWS services and your own applications through interface endpoints — Elastic Network Interfaces (ENIs) with private IPs placed in your subnet. It needs no VPC peering, Internet Gateway, NAT, or VPN. Connectivity is unidirectional (consumer → provider) and works even when CIDRs overlap. Gateway endpoints are a separate, free mechanism for S3 and DynamoDB only.
Interface Endpoints vs. Gateway Endpoints
This distinction is heavily tested. PrivateLink powers interface endpoints; gateway endpoints are a different (and free) feature.
| Interface endpoint (PrivateLink) | Gateway endpoint | |
|---|---|---|
| Mechanism | ENI with private IP in your subnet | Route-table prefix-list entry |
| Services | Most AWS services + your own | Only S3 and DynamoDB |
| Cost | Per hour plus per GB processed | Free |
| Cross-Region / on-prem | Reachable from peered/VPN networks | VPC-local only |
| DNS | Private DNS overrides the public name | Uses public service name with prefix list |
On the Exam: "Private S3 access with no cost" → Gateway endpoint. "Private access to SQS, Kinesis, or Secrets Manager" → Interface endpoint (PrivateLink). "Reach S3 privately from on-premises over Direct Connect" → interface endpoint, because gateway endpoints are VPC-local only.
Endpoint Services — Exposing Your Own Application
PrivateLink also lets you publish your own service to other VPCs and accounts.
Provider side:
- Put the service behind a Network Load Balancer (NLB) — PrivateLink requires an NLB target.
- Create a VPC Endpoint Service that points to the NLB.
- Approve connection requests (manually or via an allow-list of principals).
Consumer side:
- Create an interface VPC endpoint targeting the provider's endpoint service.
- An ENI with a private IP appears in the consumer's subnet.
- The application connects to that private IP — traffic never touches the public internet.
PrivateLink vs. VPC Peering
| Feature | PrivateLink | VPC Peering |
|---|---|---|
| Direction | Unidirectional (consumer → provider) | Bidirectional |
| Exposure | One service/port | All traffic between VPCs |
| Scale | Thousands of consumers per service | One connection per pair |
| Overlapping CIDR | Allowed (no inter-VPC routing) | Not allowed |
| Transitive | No | No |
| Best for | SaaS / shared-service exposure | Full VPC-to-VPC connectivity |
Because traffic terminates on an ENI rather than being routed between VPC CIDRs, overlapping address ranges are fine — a decisive advantage when onboarding many customers whose VPCs all use 10.0.0.0/16.
On the Exam: "Expose an internal API to hundreds of customer VPCs without peering or shared CIDR planning" → PrivateLink endpoint service + NLB. "Allow private, one-way access where the provider must never reach back into the consumer" → PrivateLink (peering would be bidirectional).
Private Access to AWS Services and Cost Reasoning
A classic exam pattern: an EC2 instance in a fully private subnet (no NAT, no IGW) must call AWS APIs such as SSM, Secrets Manager, Kinesis, or ECR. The answer is an interface endpoint (PrivateLink) for that service, which keeps the API traffic on the AWS network with no internet path. For Amazon S3 or DynamoDB specifically, prefer a gateway endpoint because it is free, whereas interface endpoints bill per hour and per GB.
There is also a cost-optimization angle. Routing S3 traffic through a NAT Gateway incurs NAT per-GB data-processing charges on top of the NAT gateway's hourly charge; sending that S3 traffic through an S3 gateway endpoint removes the data-processing charge for it (the NAT gateway's hourly charge continues while it stays provisioned for other traffic). When a scenario stresses "reduce NAT data-processing costs for S3 access," the gateway endpoint is the intended answer.
Decision Summary
| Requirement | Solution |
|---|---|
| Private S3/DynamoDB access, no cost | Gateway endpoint |
| Private access to SQS, SSM, Kinesis, Secrets Manager | Interface endpoint (PrivateLink) |
| Reach S3 privately from on-premises over DX | Interface endpoint (gateway is VPC-local) |
| Expose your own API to many customer VPCs | Endpoint Service + NLB |
| One-way provider→consumer with overlapping CIDRs | PrivateLink |
| Full bidirectional VPC-to-VPC traffic | VPC peering or Transit Gateway |
Common Traps
- Gateway endpoint for everything: gateway endpoints serve only S3 and DynamoDB. Any other service requires an interface endpoint.
- Cross-Region S3 through a gateway endpoint: a gateway endpoint serves S3 or DynamoDB only in its own Region. Traffic to the service in a different Region still goes to the internet gateway (or NAT path), because prefix lists are Region-specific.
- PrivateLink is bidirectional: it is not — consumers initiate to the provider; the provider cannot reach back. If the scenario needs two-way traffic, that is peering or Transit Gateway.
- Endpoint service behind an ALB: PrivateLink endpoint services require a Network Load Balancer, not an Application Load Balancer.
- CIDR conflicts block PrivateLink: they do not — because no inter-VPC routing occurs, overlapping CIDRs are fine, which is the headline advantage over peering.
DNS, Security, and Cross-Account Sharing
Interface endpoints come with a per-endpoint DNS name, but enabling private DNS on the endpoint overrides the service's public hostname (for example sqs.us-east-1.amazonaws.com) so existing application code resolves to the private endpoint IP with no code change — a detail the exam rewards. Because each interface endpoint is just an ENI, you secure it with a security group, restricting which subnets or instances may reach the service. You can also attach a VPC endpoint policy (a resource-style IAM policy) to limit which principals and actions the endpoint permits, useful for locking an S3 gateway endpoint to specific buckets.
For exposing your own service, the endpoint service can auto-accept requests from an allow-list of account or IAM principals, enabling controlled cross-account SaaS delivery. When a question contrasts PrivateLink with a public path, the deciding factors are usually that PrivateLink keeps traffic off the internet, scales to thousands of consumers, and sidesteps CIDR coordination — none of which a public, IP-allow-listed endpoint can match.
A SaaS provider must expose one internal API to hundreds of customer VPCs without VPC peering, without internet exposure, and without coordinating CIDR ranges. Which approach fits best?
VPC peering with every customer VPC
A PrivateLink endpoint service fronted by a Network Load Balancer
A Transit Gateway shared with every customer
A public API protected by IP allow-listing
Which statement about AWS endpoint options is correct?
Gateway endpoints are free and support only Amazon S3 and DynamoDB
Interface endpoints are free, while gateway endpoints are billed per GB
Gateway endpoints work for any AWS service
Interface endpoints cannot place an ENI in your subnet
Which is a genuine advantage of PrivateLink over VPC peering for service connectivity?
PrivateLink supports fully bidirectional traffic between VPCs
PrivateLink permits overlapping CIDR blocks between consumer and provider
PrivateLink provides transitive routing across many VPCs
PrivateLink is always free of data-processing charges
Sections you finish are checked off in the contents.