AWS PrivateLink launched in 2017 to solve a problem that VPC peering and public internet access both handled poorly: letting one network reach a single specific service in another network without exposing everything else in either network to the other side. VPC peering connects two entire networks together, meaning route tables and, depending on configuration, broad IP ranges become mutually reachable — appropriate for closely trusted networks, but excessive when the actual goal is “let consumers reach this one service, nothing else.”

PrivateLink’s underlying idea borrows from a familiar pattern in enterprise networking: rather than connecting networks, connect specific service endpoints. AWS built this natively into VPC infrastructure through what are now called Interface VPC Endpoints, powered by AWS PrivateLink technology, allowing both AWS’s own services (like S3, DynamoDB via gateway endpoints, or dozens of others via interface endpoints) and entirely custom, self-hosted services to be exposed this same surgical way.

A concrete example: many SaaS security and observability vendors, including companies like Datadog and Snowflake, offer PrivateLink connectivity options specifically so enterprise customers can send sensitive telemetry or data to the vendor’s service without that traffic ever traversing the public internet, which is frequently a hard compliance requirement in regulated industries.

Consider a SaaS company offering an API that customers need to call from inside their own VPCs. The naive approach is to expose the API over the public internet, protected by TLS and API keys — functional, but it means customer traffic leaves their private network, traverses the internet (even if briefly and encrypted), and the customer’s security team now has to justify and audit an allowed outbound path to a third party’s public endpoint, which many compliance frameworks scrutinize heavily.

The alternative — VPC peering between the SaaS provider and every customer — solves the “stay off the public internet” problem but creates new ones: peering connects entire CIDR ranges, requires careful non-overlapping IP address planning between the two parties, and a misconfigured route table can expose far more of each network to the other than intended. It also doesn’t scale gracefully to hundreds or thousands of customers, since each one requires manual, bespoke network configuration.

PrivateLink’s answer is to expose a single, specific service as an endpoint, backed by a Network Load Balancer on the provider side and represented as a private IP address with its own elastic network interface inside the consumer’s VPC — no CIDR range planning, no shared route tables, and connectivity scales to as many consumers as needed without bespoke per-customer network engineering.

Interface Endpoints vs. Gateway Endpoints

Two distinct mechanisms are both sometimes referred to loosely as “VPC endpoints,” and confusing them is a common mistake. A gateway endpoint is a route table entry pointing at Amazon S3 or DynamoDB specifically — it doesn’t consume an IP address in your subnet and doesn’t use PrivateLink technology at all. An interface endpoint, by contrast, is powered by AWS PrivateLink: it provisions an actual elastic network interface (ENI) with a private IP address directly inside your subnet, and that ENI is what your applications connect to.

Endpoint Services: The Provider Side

On the provider side, exposing a service via PrivateLink starts with a Network Load Balancer sitting in front of the actual service (or a Gateway Load Balancer for certain appliance-style use cases). The provider then creates a VPC Endpoint Service pointing at that load balancer, and this is the object consumers actually connect to. The provider controls exactly which AWS principals (accounts, IAM roles, or organizations) are allowed to create a connection to that endpoint service, and can require manual acceptance of each new consumer connection request rather than allowing automatic acceptance.

Private DNS

Without any additional configuration, an interface endpoint is reachable at a PrivateLink-specific DNS name that’s different from the service’s normal public hostname — which means existing application code pointing at the normal hostname wouldn’t automatically use the private path. Enabling private DNS for an endpoint solves this: it lets Route 53 (or the consumer’s own DNS resolution) transparently resolve the service’s normal hostname to the private endpoint’s IP address instead of its public address whenever the query originates from within the VPC where the endpoint exists, so application code requires zero changes to start using the private path.

You may likeAmazon ECR→

Cross-Zone Considerations

An interface endpoint provisions one ENI per enabled Availability Zone, and traffic from a consumer’s resource in a given AZ stays within that AZ’s endpoint ENI by default unless cross-zone load balancing is specifically enabled on the underlying Network Load Balancer — an important detail for both cost (inter-AZ data transfer) and resilience (an AZ outage affecting the endpoint ENI in just that zone) planning.

On the consumer side, the interface endpoint is the entire footprint required — an ENI in each chosen subnet/AZ, associated with security groups the consumer controls, resolving via optional private DNS. On the provider side, the Network Load Balancer distributes incoming connections to the actual backend targets (EC2 instances, ECS tasks, or EKS pods), while the VPC Endpoint Service object sits between the two, acting as the access-controlled front door that decides which consumer accounts or principals may connect at all.

Notably, neither side needs visibility into the other’s internal network topology: the provider never sees the consumer’s VPC CIDR range or route tables, and the consumer never sees how the provider’s backend is architected behind the load balancer — only the exposed service endpoint matters to either party.

When a consumer creates an interface endpoint targeting a specific endpoint service, AWS provisions an ENI in each selected subnet and, depending on the endpoint service’s configuration, either automatically accepts the connection or leaves it pending until the provider manually approves it. Once accepted, traffic sent to that ENI’s private IP address is transparently forwarded over AWS’s internal network backbone to the endpoint service, which the Network Load Balancer then distributes across healthy backend targets using standard load balancer target-group health checks.

Critically, this forwarding happens without the consumer’s traffic ever being routed through a route table entry pointing at the provider’s VPC, and without the provider’s VPC ever advertising routes into the consumer’s VPC — the ENI itself is the entire mechanism, which is why PrivateLink avoids the CIDR-overlap and shared-route-table complexity inherent to VPC peering.

Security groups attached to the interface endpoint act exactly like security groups on any other ENI, controlling which resources within the consumer’s own VPC are permitted to initiate connections to the endpoint — an important, sometimes overlooked control point, since without appropriately scoped security group rules, any resource in the VPC that can reach the endpoint’s subnet could reach the private service.

You may likeAmazon EBS→

The lifecycle begins on the provider side: a service is deployed behind a Network Load Balancer, a VPC Endpoint Service is created pointing to that load balancer, and the provider configures which consumer principals may connect — either an open acceptance policy or a manual-approval allowlist. On the consumer side, an interface endpoint is created referencing the service name the provider shares (often distributed out-of-band, such as through documentation or a SaaS onboarding process), selecting the subnets and security groups to use.

If manual acceptance is required, the connection sits in a pending-acceptance state until the provider approves it, at which point traffic can begin flowing. From there, ongoing traffic follows the pattern described in the previous chapter — consumer resources send requests to the endpoint’s private IP or private DNS name, which is forwarded over the PrivateLink backbone to the provider’s load balancer and backend targets. If the provider later needs to modify their backend infrastructure, they can do so freely behind the load balancer without any coordination required with consumers, since the endpoint service’s exposed interface remains stable regardless of backend changes.

The essential trade-off is scope versus breadth: PrivateLink deliberately exposes exactly one service, which is precisely what makes it safer than peering for many-to-one or SaaS-style relationships, but it is the wrong tool when the actual requirement is broad, bidirectional connectivity between two trusted networks.

Because PrivateLink traffic travels entirely over the AWS backbone rather than the public internet, it typically experiences lower and more consistent latency than equivalent public-internet paths, with no exposure to internet routing variability. Throughput scales with the underlying Network Load Balancer’s capacity on the provider side, and consumers can scale their own access by adding additional ENIs across more Availability Zones as needed.

Providers scaling to a large number of consumers benefit from PrivateLink’s design specifically because the endpoint service abstraction means adding the thousandth consumer requires no more provider-side network engineering than adding the first — a property VPC peering fundamentally cannot offer at that scale, since each peering relationship is its own discrete network configuration to maintain.

Deploying an interface endpoint across multiple Availability Zones is a deliberate resilience decision — if only one AZ’s ENI is provisioned and that AZ experiences an issue, consumer resources in other AZs lose access to the endpoint entirely. Best practice is to provision the endpoint in every AZ where consumer workloads run, matching the AZ footprint of the actual application.

On the provider side, reliability depends on the Network Load Balancer’s own health checks against backend targets — unhealthy targets are automatically removed from rotation, and as long as the load balancer itself spans multiple AZs with healthy targets in each, the endpoint service as a whole remains available even if individual backend instances fail.

Security in a PrivateLink architecture operates at several layers simultaneously. On the provider side, the endpoint service’s allowlist controls which AWS accounts or principals may even request a connection at all, and manual connection acceptance adds a human or automated approval gate before any traffic can flow. Endpoint policies — IAM-style resource policies attached to the interface endpoint itself — can further restrict which specific API actions or resources are reachable through that endpoint, particularly relevant for AWS service endpoints like S3, where an endpoint policy might restrict access to only a specific bucket even though the broader S3 service is reachable through the endpoint.

On the consumer side, security groups attached to the endpoint’s ENI control which internal resources can initiate connections to it, functioning as an additional access boundary layered on top of the provider’s own controls. Because all traffic stays on the AWS network backbone rather than the public internet, PrivateLink inherently reduces exposure to a wide category of network-based attacks that rely on traffic being observable or interceptable in transit across the public internet.

Amazon CloudWatch collects VPC endpoint metrics, including bytes processed and active connection counts, letting teams monitor throughput and detect unusual traffic patterns through a specific endpoint. VPC Flow Logs can be enabled on the endpoint’s ENI to capture accepted and rejected connection attempts at the network level, which is valuable both for troubleshooting connectivity issues and for security review of who is actually connecting.

On the provider side, standard Network Load Balancer metrics and access logs provide visibility into backend target health, connection counts, and processed bytes, giving the provider insight into consumer usage patterns even though they can’t see into the consumer’s own VPC. AWS CloudTrail logs management-level API actions — creating, modifying, or deleting endpoints and endpoint services — supporting change auditing for what is often a security-sensitive piece of infrastructure.

Endpoints and endpoint services are typically defined through CloudFormation or Terraform as part of standard infrastructure-as-code practice, given how central they often are to a network’s security posture. Many AWS services beyond core networking — including CloudWatch, Systems Manager, KMS, Secrets Manager, and many others — natively support interface endpoints, allowing entire application stacks to avoid public internet dependencies for their AWS API calls, which is a common requirement in fully private “air-gapped-style” VPC architectures with no internet gateway at all.

PrivateLink also underpins the AWS Marketplace SaaS integration pattern extensively: many third-party SaaS offerings available through AWS Marketplace provide a PrivateLink-based connectivity option specifically so enterprise customers can adopt the SaaS product without their security or compliance teams needing to approve a new public internet egress path.

• Deploy interface endpoints across every AZ your application actually runs in, not just one, to avoid AZ-specific connectivity gaps.
• Enable private DNS whenever possible so existing application code can adopt the private path without hostname changes.
• Scope security groups on the endpoint ENI tightly, restricting which internal resources may even attempt a connection, rather than leaving broad VPC-wide access.
• Use endpoint policies to further narrow access to specific resources or actions for AWS service endpoints, rather than relying solely on IAM permissions elsewhere.
• Common mistake: reaching for VPC peering or a Transit Gateway when the actual requirement is exposing one specific service, resulting in unnecessarily broad network exposure.
• Common mistake: forgetting cross-zone load balancing considerations on the provider’s Network Load Balancer, leading to uneven backend utilization across AZs.
• Common mistake: not requiring manual connection acceptance for sensitive internal endpoint services, allowing unintended principals to establish a connection automatically.