Why architecture matters here
The architecture matters because the alternatives couple things that should stay separate. Public endpoints put your service on the internet and make you responsible for defending it there — WAF, IP allowlists, DDoS posture — for traffic that never needed to leave AWS in the first place. VPC peering connects whole networks: it demands non-overlapping CIDR ranges (a real constraint across many teams and acquisitions), it exposes far more than the one service you meant to share, it does not transit (peer-of-a-peer is unreachable), and it grows into an unmanageable mesh at scale. Transit Gateway solves the mesh but still connects networks, still needs address hygiene, and still shares more than a single service. PrivateLink is categorically different: it shares a service, not a network, and that difference is the entire value proposition.
Three properties fall out of the 'service, not network' model. First, CIDR independence: because the service appears as ENIs with IPs from the consumer's subnets, the provider's internal address space is irrelevant and the two sides can use identical CIDR blocks — impossible with peering. Second, minimal surface: the consumer can reach exactly the NLB's listener and nothing else in the provider's VPC; there is no route to the provider's other subnets, instances, or services. Third, directionality: PrivateLink is one-way by design — the consumer initiates connections to the provider, and the provider gets no route back into the consumer's VPC. That asymmetry is a security feature (a compromised provider cannot pivot into consumers) but also a common source of confusion for people expecting peering's bidirectional reachability.
The second architectural pressure is access control on both ends, which peering lacks entirely. The provider controls who may connect via acceptance (manual approval or an allowlist of principal ARNs), so publishing an endpoint service does not mean anyone can consume it. The consumer controls what their endpoint may do via an endpoint policy, an IAM-style document that can restrict which API actions or resources the endpoint permits — so even an authorized endpoint can be scoped. Two independent gates, provider-side and consumer-side, replace peering's all-or-nothing network trust.
The third pressure is that PrivateLink is fundamentally an availability-zone-scoped, capacity-bearing construct, and this shapes both reliability and cost. Interface endpoints are created per-AZ as ENIs, each with finite bandwidth and connection capacity, and you pay per endpoint-hour per AZ plus per GB processed. That means designing for AZ redundancy (endpoints in every AZ your workload runs in, matched by NLB targets in those AZs to avoid cross-AZ data charges and single-AZ failure) and budgeting the endpoint sprawl that a hundred consuming accounts can create. The economics and the resilience both live in the per-AZ ENI model, so understanding it is not optional.
A fourth property worth internalizing is that PrivateLink changes who owns the exposure decision, and that has organizational consequences beyond the network. With a public endpoint, security review focuses on the internet-facing perimeter; with peering, a network team owns a shared connection that implicitly trusts whole VPCs. With PrivateLink the provider team owns a narrow, explicit, auditable list of who consumes each service, and the consumer team owns a scoped policy on what their endpoint may do — so exposure becomes a per-service, per-principal decision recorded in configuration rather than a network-team ticket. In large enterprises this is precisely why PrivateLink underpins internal service marketplaces: a platform team can publish a shared service once and let dozens of application accounts consume it privately, each connection individually authorized and individually revocable, without anyone ever flattening the network or granting blanket trust. The architecture is as much a governance model as a connectivity mechanism.
The architecture: every piece explained
Provider side (bottom-left of the diagram). A provider exposes a service by fronting their fleet with a Network Load Balancer — PrivateLink requires an NLB (or Gateway Load Balancer) because it operates at the connection/flow level, preserving the model where the consumer's ENI hands flows to the NLB, which distributes them to targets (instances, IPs, containers) in the provider's VPC. The provider then creates an endpoint service from that NLB, which gives it a service name and makes it discoverable to authorized consumers. The acceptance / allowlist gate decides who may connect: the provider either manually accepts each connection request or pre-authorizes specific AWS principals, so exposure is explicit, not open.
Consumer side (top of the diagram). The consumer creates an interface endpoint for that service name in their VPC, choosing the subnets (and thus AZs) where it should live. AWS provisions an ENI with a private IP in each chosen subnet; these ENIs are the local presence of the remote service inside the consumer's address space. Private DNS ties it together: when enabled, the service's DNS name resolves, inside the consumer's VPC, to the endpoint's private IPs, so applications use the normal hostname and transparently reach the endpoint rather than any public address. The endpoint policy attached to the interface endpoint scopes what the endpoint is allowed to do — a consumer-side IAM-style restriction independent of the provider's controls.
The path and the boundaries. Traffic from the consumer's application goes to the endpoint ENI's private IP, across the AWS backbone (never an internet gateway, NAT, or peering connection) to the provider's NLB, and on to the targets — a private, one-directional flow. Cross-account and cross-region reach is native: the provider and consumer can be different accounts (the common SaaS case) and, with the right configuration, different regions, all without joining networks. The ops strip captures what actually governs a healthy deployment: the DNS strategy (private DNS vs explicit endpoint-specific names, and the split-horizon implications), per-AZ capacity (endpoints and NLB targets in matching AZs for resilience and to avoid cross-AZ charges), endpoint cost (hourly-per-AZ plus per-GB, which multiplies across many consumers), and connection monitoring (endpoint and NLB metrics, connection counts, and health).
End-to-end flow
Trace a SaaS observability vendor exposing its ingestion API to a customer privately. The vendor (provider account) runs its ingestion fleet behind an NLB in three AZs and creates an endpoint service, choosing to require acceptance and pre-authorizing the customer's AWS account principal. The vendor hands the customer the endpoint service name. Nothing is on the public internet; the service simply waits to be consumed.
The customer (consumer account) creates an interface endpoint for that service name, selecting the three subnets where their application runs — one per AZ. AWS provisions an ENI with a private IP in each subnet, and because the vendor pre-authorized the customer, the connection is accepted automatically. The customer enables private DNS, so the vendor's ingestion hostname now resolves, inside the customer's VPC only, to those three endpoint IPs. The customer attaches an endpoint policy scoping the endpoint to the ingestion actions and nothing more.
Now an application instance sends telemetry. It resolves the vendor's hostname; private DNS returns an endpoint ENI IP in the instance's own AZ. The connection goes to that local private IP, across the AWS backbone to the vendor's NLB — staying within the AZ, so no cross-AZ data charge — and the NLB forwards it to an ingestion target. From the application's perspective it called a normal hostname; in reality the traffic never left AWS's private network, the vendor's internal VPC is completely invisible, and the customer's VPC is unreachable from the vendor's side. Both sides share one CIDR block (10.0.0.0/16) with no conflict, because the service is presented on the consumer's addresses.
Now the stress cases. Suppose the customer created the endpoint in only one AZ to save money; when that AZ has an issue, all telemetry from the other two AZs' instances either fails or, if it resolves to the surviving endpoint, pays cross-AZ charges and concentrates load — the per-AZ ENI model means single-AZ endpoints are a single-AZ dependency. The fix is an endpoint per AZ the workload uses. Suppose instead the customer forgot to enable private DNS and hardcoded a public hostname; traffic would silently route to the public endpoint (if one exists) over NAT, defeating the entire private-connectivity goal — a misconfiguration that 'works' but leaks to the internet, which is why DNS strategy is treated as a first-class concern. And suppose the vendor wants to reach back into the customer to poll a webhook: they cannot, because PrivateLink is one-directional; the correct pattern is a second PrivateLink in the other direction (customer as provider), not an attempt to bend one endpoint into a two-way link. Finally, as the vendor onboards a thousand customers, each with their own interface endpoints, the vendor watches NLB connection counts and per-AZ capacity, and each customer watches their own endpoint-hour and per-GB bill — the sprawl is real and is managed by monitoring, not by hoping.