Publishing Services with PrivateLink

Service-level connectivity instead of network-level

Peering connects whole networks: once routes exist, any port allowed by security groups is reachable both ways. Often you want something narrower. With PrivateLink, a service provider puts an application behind a Network Load Balancer (or Gateway Load Balancer) and creates an endpoint service. A consumer in another VPC, even another account, creates an interface endpoint to it. The consumer gets a private IP in its own subnet that forwards to the provider's service, and that is all: traffic can only be initiated from consumer to provider, only to that service. Because the consumer talks to an address in its own range, overlapping CIDRs do not matter, which makes PrivateLink the usual choice for SaaS vendors serving many customers. Providers can require acceptance of each connection request and allow-list principals. The trade-off is that it fits request-response services; it is not a general network join.

A service counter window

Instead of letting a customer walk into your shop's back rooms (peering), you open a counter window into their lobby. They can hand you requests through the window and get answers, but they cannot wander around, and neither side needs to know the other's floor plan.

The endpoint has its own security group

The interface endpoint ENI has a security group. If calls to a PrivateLink service hang, check that the endpoint's SG allows inbound from your clients on the service port.

त्वरित जाँच: Why do SaaS vendors often prefer PrivateLink over VPC peering with customers?

• It is the only option that encrypts traffic
• It works even when customer and vendor CIDRs overlap and exposes only one service
• It lets customers use the vendor's NAT gateway
• It removes the need for any load balancer