AWS PrivateLink service
Exposing a service privately with AWS PrivateLink
Publish one service, let hundreds of accounts reach it privately, and never fight a CIDR overlap again.
The provider/consumer model
AWS PrivateLink lets a service provider expose a single application to other AWS accounts as if it lived inside each consumer's own VPC, with no internet gateway, NAT device, public IP, Direct Connect, or VPN required for the connection itself. The provider builds the service behind a Network Load Balancer (NLB), then creates an endpoint service that references that NLB as its front end. AWS assigns the endpoint service a service name of the form com.amazonaws.vpce.us-east-2.vpce-svc-071afff70666e61e0, which the provider shares with customers so they can create endpoints against it. (Separately, AWS also generates a Regional DNS hostname for the service, vpce-svc-071afff70666e61e0.us-east-2.vpce.amazonaws.com, plus zonal variants.)
A consumer connects by creating an interface VPC endpoint that names the provider's service. For every subnet the consumer selects, AWS provisions an endpoint network interface (an ENI) in that subnet and assigns it a private IP address from the consumer's own subnet range. Traffic sent to that ENI is carried across the AWS backbone to the provider's NLB, which round-robins it to the registered targets. The endpoint service itself is not reachable until the provider grants the consumer's principal permission and the connection request is accepted.
This is a fundamentally different shape than VPC peering or Transit Gateway. Peering and TGW build a shared, routable address space where both sides must have non-overlapping CIDRs and routes to each other. PrivateLink instead exposes one service through a per-consumer ENI, so the only thing a consumer routes to is a private IP that already sits in its own VPC.
Why overlapping CIDRs stop mattering
The reason PrivateLink sidesteps CIDR conflicts is that the two VPCs never have to be mutually routable. The consumer's client talks to an ENI whose IP comes from the consumer's own subnet, so from the client's routing table the destination is local. On the provider side, the NLB receives the flow from AWS PrivateLink, not from the consumer's VPC CIDR, so the provider never needs a route back to the consumer and never sees (or collides with) the consumer's address space. In the diagram, Consumer A deliberately reuses the provider's exact CIDR (10.0.0.0/16) and still connects cleanly, right alongside Consumer B on 172.16.0.0/16.
Connectivity is also one-directional at the data plane. The consumer initiates connections toward the endpoint service; the provider can only accept or reject the connection request and then serve responses on the established flows. The provider cannot open new connections back into the consumer's VPC over the endpoint. That property is what makes it safe to hand the same service to hundreds of untrusted customers: exposure is limited to the one TCP/UDP service the NLB fronts, in one direction.
Because the NLB sees connections arriving via PrivateLink rather than the original client IP, providers that need the real client address commonly enable NLB proxy protocol v2. Keep in mind the endpoint enforces an MTU of 8500 bytes, does MSS clamping, and does not support Path MTU Discovery, so applications that assume jumbo frames or PMTUD need testing.
Access control and the one-directional contract
By default an endpoint service is private to everyone. The provider must add allowed principals (AWS account, IAM role, or IAM user ARNs, or the wildcard *) before anyone can even create an interface endpoint against it. On top of that, the provider chooses an acceptance mode: with 'acceptance required' set, every consumer connection lands in the PendingAcceptance state and a human or automation must approve it; with auto-accept, approved principals connect immediately. Pairing a narrow principal list with auto-accept, or a broad list with manual acceptance, are the two common trust postures.
The classic failure mode is documented explicitly by AWS: if you grant * as an allowed principal and also auto-accept all requests, your load balancer becomes effectively public even though it has no public IP address. Removing a principal later does not tear down connections that were already accepted, so revocation is not retroactive.
Controls exist on the consumer side too. The consumer attaches security groups to the endpoint network interfaces to decide which of its own resources may reach the ENIs, and can apply a VPC endpoint policy (an IAM resource policy, up to 20,480 characters) to constrain what actions are allowed through the endpoint. Provider-side permissions decide who may connect; consumer-side security groups and endpoint policies decide who inside the consumer VPC may use the connection.
DNS: making it look native, from the VPC and on-prem
Out of the box, a consumer would have to call the generated Regional endpoint name ({endpoint_id}.{service_id}.{region}.vpce.amazonaws.com) or its zonal variants. To let customers keep using the service's real name, the provider associates a private DNS name (for example api.example.com) with the endpoint service and completes an AWS domain-ownership verification. Once verified, consumers simply enable 'private DNS names' on their interface endpoint, and AWS creates the DNS records that point the friendly name at the ENI's private IP. This is also how split-horizon DNS works: inside the consumer VPC the public hostname resolves to the private ENI addresses, while the same name resolves to the public endpoint everywhere else.
Reaching the service from on-premises adds a DNS wrinkle. The private ENI IP is reachable over Direct Connect or VPN, but on-prem resolvers cannot see the VPC's private DNS. The standard pattern is a Route 53 Resolver inbound endpoint (or a private hosted zone shared appropriately) so that on-prem clients resolve the service name to the interface endpoint's private IP, then send the actual traffic across the Direct Connect or VPN link to that ENI, as shown in the hybrid diagram.
The Regional endpoint name load-balances across ENIs in different Availability Zones using round robin; the zonal names let a consumer pin traffic to a single AZ when it wants to avoid cross-AZ hops.
Scale, resiliency, and cost tradeoffs
PrivateLink scales to many consumers precisely because there is no shared routing domain to coordinate. One endpoint service serves an arbitrary number of interface endpoints; onboarding a new account is just another allowed-principal entry plus an interface endpoint the consumer creates on its side. There is no route propagation, no CIDR de-confliction, and no transitive path between consumers, so two customers of the same service can never route to each other through it.
Availability comes from Availability Zone breadth. The endpoint service is available only in the AZs where the provider's NLB is enabled, so AWS recommends at least two AZs with targets registered in each. Cross-zone load balancing is an alternative to spanning zones, but it is a trap for resiliency: if the single hosting zone fails, consumers lose access from all zones, and enabling cross-zone on an NLB also incurs inter-AZ EC2 data transfer charges. Aligning consumer endpoint subnets with the provider's AZs keeps traffic in-zone and cheaper.
Performance headroom is generous: each VPC endpoint supports up to 10 Gbps per AZ and automatically scales to 100 Gbps per AZ, so aggregate throughput is roughly the number of AZs times 100 Gbps. A provider can even offer the service across multiple Regions using cross-Region access (gated by the vpce:AllowMultiRegion action), though AWS recommends intra-Region connections for lower latency and cost, and PrivateLink manages failover only between AZs, not across Regions.
Sources
Practice what you just read