AWS PrivateLink

What is AWS PrivateLink?

PrivateLink exposes a service in one VPC as an interface endpoint — an elastic network interface with a private IP — inside another VPC. Consumers connect to that local IP; traffic traverses AWS’s backbone directly to the provider’s Network Load Balancer. No internet gateway, no NAT, no VPC peering. Where VPC peering merges two networks bidirectionally (with all the CIDR-overlap and lateral-movement baggage that implies), PrivateLink is a one-way keyhole to exactly one service.

Why security teams push it

Three arguments recur. No public exposure: internal APIs consumed cross-account never need public IPs at all. No transitive access: the consumer reaches the endpoint’s service and nothing else — compare peering, where a compromised consumer VPC can probe the entire provider network. CIDR indifference: both sides can use 10.0.0.0/16 without conflict, which matters enormously in M&A and multi-team sprawl. It’s also how you reach AWS’s own services (S3, Kinesis, Bedrock) without sending traffic through a NAT gateway — often justified by cost alone, since NAT data processing at ~$0.045/GB dwarfs endpoint pricing for high-volume internal traffic.

The cost shape

Interface endpoints bill per hour (~$0.01/AZ) plus ~$0.01/GB processed. The hourly part is the trap at scale: hundreds of endpoints across many VPCs and AZs quietly compound — which is why hub-and-spoke architectures centralize endpoints in a shared-services VPC.

What people get wrong

• Reaching for peering when PrivateLink fits. If the requirement is “consume one service,” the keyhole beats the merged network.
• Forgetting DNS: private DNS resolution for endpoints must be enabled or clients resolve public IPs and bypass the whole arrangement.
• NLB-only assumptions — provider-side services must sit behind an NLB (or Gateway LB), constraining some architectures.

Primary source: AWS PrivateLink documentation

Why “One-Way” Connectivity Is a Feature, Not a Limitation

PrivateLink’s one-way design — consumers can reach the service provider, but the provider has no visibility into or access back into the consumer’s VPC — is a deliberate security property rather than a limitation to work around. This asymmetry is exactly what makes PrivateLink suitable for commercial SaaS integrations, where a vendor needs to expose a service to many customer VPCs without any of those customers needing to expose their own internal network back to the vendor, a mutual-trust requirement that VPC peering’s bidirectional connectivity model doesn’t naturally provide without additional restrictive configuration.