This section assumes you already know VPC endpoints exist. We’re going straight into the mechanics that separate PrivateLink from a routing trick.

An interface endpoint is a real network interface, not a routing rule

The core primitive behind PrivateLink is the interface VPC endpoint: AWS provisions one or more Elastic Network Interfaces (ENIs), with private IP addresses drawn from your own VPC’s subnets, that represent the remote service inside your network. This is a fundamentally different mechanism from VPC peering or a Transit Gateway attachment, neither of which creates a device inside your VPC — they create routes to somewhere else’s network. An interface endpoint’s ENI is, from your VPC’s perspective, just another local resource with a local IP, which is exactly why no route table changes are needed to reach it: it’s already local.

Endpoint services: the provider side of the same coin

A VPC endpoint service is what a provider account creates to expose something through PrivateLink — and critically, that “something” is almost always a Network Load Balancer (or, for newer service types, a Gateway Load Balancer) sitting in the provider’s VPC. The endpoint service registers that NLB as the thing consumer-side interface endpoints ultimately reach. This means the provider’s actual backend fleet is never directly exposed through PrivateLink at all — the NLB is the only thing PrivateLink ever touches, and everything behind it is the provider’s own internal architecture, invisible to the consumer by construction.

The consumer never sees the provider’s network, and that’s the entire point

When a consumer creates an interface endpoint for a provider’s service, no peering connection is established, no route table on either side needs an entry pointing at the other’s CIDR range, and the consumer’s VPC never becomes reachable from the provider’s VPC in the reverse direction. This one-way, ENI-mediated model is what makes PrivateLink safe to offer to untrusted or semi-trusted external consumers (paying SaaS customers, partner organizations) in a way that VPC peering — which creates a genuine two-way network relationship — structurally cannot match without extensive additional security-group and NACL discipline on both sides.

AWS-managed endpoints versus customer-managed endpoint services — two different products under one name

Most engineers’ first PrivateLink experience is an AWS-managed interface endpoint — for S3, DynamoDB, Secrets Manager, or dozens of other AWS services — where AWS itself operates the endpoint service side entirely. The second, architecturally distinct use of PrivateLink is a customer-managed endpoint service, where you personally stand up the NLB, register it as an endpoint service, and control exactly which consumer accounts are allowed to connect. Both use the identical underlying interface-endpoint mechanism on the consumer side, but only the second one requires you to think about provider-side scaling, health checking, and access control at all — a distinction that matters enormously depending on which side of the relationship your architecture sits on.

Endpoint policies: resource-level access control layered on top of network access

For AWS-service interface endpoints that support it, an endpoint policy is an IAM-style resource policy attached directly to the endpoint itself, scoping exactly which API actions and which resources are reachable through that specific endpoint — independent of whatever IAM permissions the calling principal already has. This is a genuinely separate control from IAM: a principal with full S3 permissions in general can still be blocked from using a specific S3 interface endpoint to reach anything outside a narrowly scoped set of buckets, if the endpoint policy says so. Advanced designs use this to enforce “this VPC may only ever reach these specific resources through this specific network path,” a guarantee IAM policy alone cannot make, since IAM has no concept of which network path a request arrived through.

Service quotas and per-endpoint scaling limits as a real design constraint

Interface endpoints, ENIs per endpoint, and endpoint services per account are all subject to AWS service quotas, and a design that assumes unlimited horizontal growth of endpoints — for instance, one endpoint per customer in a very large multi-tenant SaaS platform — needs to check those quotas explicitly during capacity planning rather than discovering the ceiling during a live customer onboarding. This is precisely why very large-scale SaaS platforms typically model their endpoint-per-tenant ratio carefully rather than assuming an unbounded one-endpoint-per-customer pattern scales indefinitely without a quota increase request. A platform onboarding its thousandth customer under a strict one-dedicated-endpoint-per-tenant model has, by definition, committed to requesting quota increases on a predictable cadence tied directly to sales growth — a dependency worth surfacing to the business side of the organization, not just tracked quietly by infrastructure engineers.

DNS resolution: the mechanism that makes PrivateLink invisible to application code

Every interface endpoint gets its own AWS-generated DNS name, but the far more important detail for real applications is private DNS: when enabled on an interface endpoint, AWS creates a Route 53 private hosted zone that overrides resolution of the service’s normal public DNS name — inside your VPC only — to resolve to the endpoint’s private ENI IP addresses instead of the service’s public IP. This is what lets an application call `s3.amazonaws.com` or a partner’s `api.vendor.com` completely unmodified, with zero code or configuration change, and have that traffic silently routed through the private endpoint rather than the public internet. The application never knows a substitution happened.

graph LR
  App[Application Code] -->|calls api.vendor.com unmodified| DNS[VPC DNS Resolver]
  DNS -->|private hosted zone override| ENI[Interface Endpoint ENI in Your Subnet]
  ENI -->|PrivateLink backbone| NLB[Provider NLB / Endpoint Service]
  NLB --> Backend[Provider Backend Fleet]
    

The role of the Network Load Balancer on the provider side

Because NLB operates at Layer 4 with flow-hash based packet forwarding rather than terminating connections the way an Application Load Balancer does, it’s uniquely suited to sit behind an endpoint service: it can forward extremely high volumes of consumer-originated connections toward the provider’s backend fleet with very low added latency, and — because NLB itself is a managed, auto-scaling resource — the provider never has to think about scaling “the PrivateLink layer” as a separate concern from scaling the NLB itself.

Gateway Load Balancer endpoints: a second, distinct PrivateLink pattern

A newer and architecturally distinct use of the same underlying PrivateLink mechanism is the Gateway Load Balancer endpoint, used specifically to insert a consumer’s traffic transparently through a provider’s fleet of security appliances (firewalls, intrusion detection). Unlike an interface endpoint (which a client explicitly connects to), a GWLB endpoint is typically referenced from a VPC route table so that traffic matching certain routes is transparently redirected through it — meaning PrivateLink here isn’t serving an API at all, it’s serving as an invisible detour through inspection infrastructure, which is a genuinely different use case wearing the same plumbing.

Split-horizon DNS and the coexistence of public and private resolution

Private DNS on an interface endpoint doesn’t delete the public DNS record for a service — it creates a private hosted zone that only takes effect for resolvers inside the specific VPC the endpoint lives in. A resource outside that VPC resolving the exact same hostname still gets the public IP (or no result, if the service is entirely private). This split-horizon behavior is precisely what allows the same application code, and even the same configuration, to behave correctly whether it’s running inside a VPC with the endpoint or outside it — the resolution outcome depends entirely on where the DNS query originates, not on anything the application does differently.

What “supports PrivateLink” actually means for a third-party appliance or SaaS product

When a vendor advertises “PrivateLink support,” concretely it means they’ve stood up an NLB (or, less commonly, a GWLB) in front of their service and published it as an endpoint service that customer accounts can request connections to. There’s no separate “PrivateLink protocol” a vendor implements beyond that — supporting PrivateLink is entirely an infrastructure decision on the provider’s side, not a new API surface or SDK the vendor’s customers need to integrate against.

The lifecycle of establishing a new endpoint connection

A consumer creates an interface endpoint targeting a specific endpoint service, which — depending on the endpoint service’s acceptance setting — either connects immediately (if the provider has enabled automatic acceptance) or sits in a pending state until the provider explicitly approves that specific consumer’s connection request. Once accepted, AWS provisions the ENIs in the consumer’s chosen subnets, assigns them private IPs, and — if private DNS is enabled — updates the private hosted zone so the service’s normal hostname resolves locally. Only after this full sequence completes does traffic actually begin flowing.

Explicit acceptance as a deliberate access-control gate in the lifecycle

The choice between automatic and manual endpoint acceptance is not a minor toggle — it’s the primary access-control decision a service provider makes. Automatic acceptance suits an internal, same-organization service where any account in an approved list should connect without friction. Manual acceptance suits an external-facing SaaS product where every new customer connection should be a deliberate, auditable decision — often tied to provisioning or billing workflows — rather than something any account that discovers the service name can trigger unilaterally.

What happens on request completion and connection teardown

Traffic flowing through an interface endpoint follows the exact same flow-hash consistency the underlying NLB provides — a given connection is pinned to a specific backend target for its lifetime. When a consumer deletes an interface endpoint, the ENIs are removed, the private DNS override is withdrawn (reverting resolution to the service’s normal public behavior, if any), and any in-flight connections are terminated — a lifecycle event that, in a multi-tenant SaaS context, is often exactly what an off-boarding workflow triggers when a customer’s subscription ends.

Rejection and revocation as distinct lifecycle branches

A provider can reject a pending connection request outright (the consumer’s endpoint never becomes active), or revoke an already-accepted connection later (immediately cutting off a previously-working consumer). These are meaningfully different lifecycle events: rejection prevents access from ever starting, while revocation actively terminates access that was already flowing — a distinction that matters for how a provider’s off-boarding or compliance-driven access-removal automation needs to be built, since it has to handle both a request that hasn’t been approved yet and a connection that’s actively serving traffic. A well-designed off-boarding workflow treats these as two separate code paths rather than one generic “remove access” function, because the state each connection starts from, and the cleanup each requires, genuinely differs.

Endpoint modification as a non-disruptive lifecycle event

Adding a new subnet (and therefore a new AZ) to an existing interface endpoint, or attaching an additional security group, is a modification to the existing endpoint resource rather than a recreation — existing connections and DNS resolution for already-active AZs continue uninterrupted while the new AZ’s ENI provisions independently. This matters for planned resilience improvements: expanding an endpoint’s AZ coverage from one to three AZs is an additive, low-risk change rather than a cutover requiring a maintenance window.

The cost trade-off at multi-tenant scale

Because each interface endpoint accrues an hourly charge per AZ, an architecture that provisions one dedicated endpoint per customer scales its PrivateLink cost linearly with customer count, which is a materially different cost curve than a shared endpoint model where many customers route through a single, more heavily-trafficked endpoint service. Advanced SaaS cost modeling weighs this explicitly — the per-tenant isolation a dedicated endpoint provides is a real security and blast-radius benefit, but it’s a benefit purchased at a cost that scales with the customer base, not a free architectural choice.

The trade-off between transparency and observability

PrivateLink’s biggest usability win — that application code needs zero changes because DNS silently redirects traffic — is also exactly what limits its own observability. A network path that requires no application awareness to use also gives the application no natural place to log or trace that the path was used, which is why, as covered later in the monitoring chapter, most of the useful visibility into PrivateLink traffic has to come from VPC Flow Logs and the provider’s own NLB metrics rather than anything PrivateLink itself surfaces at the request level.

Why PrivateLink’s performance ceiling is really the NLB’s performance ceiling

Because every endpoint service is backed by an NLB (or GWLB), the throughput and connection-handling characteristics that apply to NLB apply directly here: near-linear scaling with very low per-connection overhead, since PrivateLink adds essentially no application-layer processing of its own — it’s a network-path substitution, not a proxy that inspects or transforms payloads. A provider scaling to serve thousands of consumer connections is, underneath, scaling an NLB’s target fleet the same way any other NLB-fronted service would.

One interface endpoint per AZ, and why that matters for both resilience and latency

An interface endpoint is created per-subnet, typically one per AZ the consumer chooses to enable, each with its own ENI. This means a request originating in a given AZ resolves (through private DNS) to that AZ’s local endpoint ENI rather than crossing AZ boundaries to reach an endpoint in a different AZ — keeping request latency low and avoiding unnecessary cross-AZ data transfer. Consumers that only enable an endpoint in one AZ, while running application instances across multiple AZs, inadvertently force cross-AZ traffic for every request originating outside that one AZ — a subtle but real latency and cost cost that’s easy to miss during initial setup.

Cross-zone considerations on the provider’s NLB

On the provider side, the same NLB cross-zone load balancing behavior discussed in general NLB architecture applies directly to endpoint services — if the provider’s backend targets are unevenly distributed across AZs and cross-zone load balancing is left disabled, consumer requests landing on an NLB node in a lightly-staffed AZ create the same silent hot-spot problem as any other NLB deployment, just with an added layer of indirection that makes it slightly less obvious to diagnose.

Connection concurrency at extreme consumer counts

A single endpoint service backed by one NLB can, in principle, serve an enormous number of simultaneous consumer connections, since NLB’s own scaling characteristics — near-linear, very high ceiling — apply directly. The practical scaling conversation for a large multi-tenant provider is therefore less about “will the endpoint service handle this many consumers” and more about whether the backend fleet behind the NLB can actually process that aggregate request volume — PrivateLink and its underlying NLB are rarely the bottleneck; the application logic behind them almost always is. This is a useful mental shortcut during capacity reviews: when a PrivateLink-fronted service shows signs of strain under growing customer count, the investigation should start at the backend fleet and its own scaling configuration, not at the endpoint service or NLB layer, because that layer’s headroom is almost never the limiting factor in practice.

Latency overhead is close to negligible, but not exactly zero

Because PrivateLink traffic still traverses a real network path — client to endpoint ENI, endpoint to provider’s NLB, NLB to backend target — there is a small, consistent latency floor compared to a hypothetical direct connection with no intermediary at all. In practice this overhead is small enough to be irrelevant for the overwhelming majority of workloads, but it is not literally zero, and ultra-latency-sensitive workloads (the same category that would choose NLB pass-through over ALB termination in a general load-balancing context) should benchmark it explicitly rather than assume it away. For the vast majority of API-style, request-response workloads this distinction is academic; it only becomes a real design factor once a workload’s latency budget is already measured in single-digit milliseconds before PrivateLink is even added to the path.

Multi-AZ resilience is opt-in per subnet, not automatic across the whole VPC

Unlike some AWS constructs that are inherently multi-AZ, an interface endpoint’s resilience is exactly as wide as the set of subnets (and therefore AZs) you explicitly enable it in. An endpoint enabled in only one AZ has exactly the availability profile of that one AZ — if it fails, the endpoint’s ENI in that AZ becomes unreachable, and unless the consumer application can fail over to a different AZ’s endpoint (which requires that endpoint to already exist), the service becomes unreachable through PrivateLink entirely, even if the provider’s own backend remains perfectly healthy in other AZs.

Provider-side reliability is entirely inherited from the NLB and backend fleet behind it

PrivateLink itself introduces essentially no additional reliability risk beyond what the underlying NLB and its target fleet already carry — there’s no separate “PrivateLink service” with its own failure mode distinct from NLB’s own well-understood high availability model. This means a provider’s PrivateLink reliability posture is really just their NLB’s reliability posture, made available to consumers through a different access path.

Health checking is entirely provider-side; PrivateLink adds no independent health signal

Consumers connecting through an interface endpoint have no visibility into, or control over, the provider’s backend health checking — that’s fully encapsulated inside the provider’s own NLB and target group configuration. From the consumer’s perspective, a degraded provider backend simply manifests as slow or failing requests through the endpoint, indistinguishable at the network layer from any other kind of service degradation; PrivateLink itself surfaces no separate health signal a consumer can monitor independently of the actual request traffic.

PrivateLink is a regional construct — cross-region access needs a different mechanism entirely

An interface endpoint connects to an endpoint service within the same AWS Region; PrivateLink does not natively bridge a consumer in one Region to a provider’s endpoint service in another. Cross-region private access to a PrivateLink-fronted service requires either the provider operating an independent endpoint service in each Region they want to serve, or the consumer routing through some other cross-region mechanism (like Transit Gateway inter-region peering) to reach a Region where the endpoint service exists — a design consideration that matters directly for any multi-region disaster-recovery architecture built around a PrivateLink dependency.

What a provider-side NLB failure actually looks like to every connected consumer simultaneously

Because a single endpoint service is typically backed by one NLB, a failure or severe degradation of that NLB (or the backend fleet behind it) is felt simultaneously by every consumer account connected to it — there’s no per-consumer isolation at the network layer beyond whatever the provider has built into their own backend fleet’s multi-tenancy design. This is a direct consequence of the shared-service architecture PrivateLink enables, and it’s exactly why providers serving many high-value customers through one endpoint service invest heavily in their own NLB and backend-fleet reliability, since a shared failure domain now affects every tenant at once. Providers with the highest reliability requirements sometimes deliberately split their customer base across multiple endpoint services, each backed by an independently scaled NLB, precisely to shrink this shared blast radius down to a defined, bounded subset of tenants rather than the entire customer base at once.

Two independent access-control layers that both need to be correct

Security on an interface endpoint operates at two genuinely independent layers: security groups attached to the endpoint’s ENIs (controlling which sources within the VPC can even reach the endpoint) and endpoint policies (an IAM-style resource policy attached to the endpoint itself, controlling which API actions or resources can be accessed through it, for AWS-service endpoints that support this). A security group can be wide open while an endpoint policy is tightly scoped, or vice versa — real security requires both to be deliberately configured, since either one alone can create a false sense of restriction while the other layer remains permissive.

The provider’s allow-list as the primary security boundary for endpoint services

For a customer-managed endpoint service, the provider controls exactly which AWS principals (accounts, IAM roles, or organizations) are permitted to even request a connection in the first place — a boundary enforced before any traffic-level security group or policy consideration comes into play at all. This principal-level allow-list is the provider’s primary defense against unauthorized consumers discovering and attempting to connect to a service, entirely independent of whatever network-level controls exist further down the stack. It’s worth treating this allow-list with the same rigor as any other identity boundary in the system — a stale or overly broad allow-list is functionally equivalent to a stale IAM policy, quietly widening who can reach a service long after the original justification for that access has expired.

PrivateLink doesn’t imply encryption — that’s still your job

A very common misconception is that PrivateLink traffic is automatically encrypted because it “stays on AWS’s private network.” PrivateLink guarantees the traffic doesn’t traverse the public internet — it makes no guarantee about encryption in transit on its own. TLS between the client and the provider’s NLB (or all the way to the backend, in a pass-through configuration) remains an application-level decision exactly as it would be for any other network path; PrivateLink changes where the bytes travel, not whether they’re encrypted while doing so.

Cross-account trust without cross-account IAM role assumption

A common misunderstanding is that connecting through PrivateLink requires some form of cross-account IAM role assumption between provider and consumer. It doesn’t — the endpoint service’s allowed-principal list is a connection-admission control, entirely separate from any IAM role-assumption relationship. A provider and consumer can have zero IAM trust relationship between their accounts and still establish a working PrivateLink connection, because the two concerns — “who may open this network path” and “what may an authenticated identity do once connected” — are handled by entirely different mechanisms that don’t need to reference each other at all.

Auditability: who connected, when, and whether it was approved

CloudTrail captures the control-plane events around endpoint and endpoint-service creation, modification, and connection acceptance or rejection, giving providers an audit trail of exactly which consumer accounts requested access and when that access was granted — a detail that matters directly for compliance frameworks requiring evidence of deliberate, reviewed access grants rather than self-service connectivity that leaves no accountable decision point in its history. Pairing this control-plane audit trail with the endpoint-service’s SNS connection notifications gives a provider both a durable historical record and a near-real-time operational signal from the same underlying set of events, satisfying two different stakeholders — compliance auditors and on-call engineers — from a single source of truth.

PrivateLink’s own observability surface is comparatively thin compared to the services it connects — a deliberate consequence of it being a network path substitution rather than a request-processing layer, which means most of the useful monitoring signal actually comes from the endpoint’s underlying network flow data and the NLB behind an endpoint service, not from PrivateLink as a distinct product.

Endpoint connection notifications as an operational automation trigger

Configuring SNS notifications on an endpoint service turns every new connection request, acceptance, or rejection into an event a provider’s automation can act on — automatically provisioning per-tenant resources the moment a new customer’s connection is accepted, for instance, rather than requiring a manual step after the network-level connection already exists.

Reconstructing request-level visibility despite PrivateLink’s thin observability

Because PrivateLink itself provides no request-level tracing, providers who need to correlate individual customer requests with specific tenants typically rely on their own application-layer logging (capturing tenant identity from an authentication token, not from network path) combined with NLB target-level metrics for aggregate health. VPC Flow Logs can confirm that traffic from a specific consumer’s endpoint reached the NLB, but reconstructing which specific request came from where still requires the application to log that detail itself — the network layer alone cannot answer “which tenant made this specific call.”

Monitoring endpoint state as a distinct concern from monitoring traffic

The endpoint’s own state (available, pending-acceptance, rejected, deleting) is a separate signal from whether traffic is flowing successfully through an available endpoint. A dashboard that only shows “endpoint is available” can mask a scenario where the endpoint is technically up but every request through it is failing due to a backend problem — which is exactly why endpoint state monitoring and NLB/target health monitoring need to be treated as two independent checks, not one combined “PrivateLink is healthy” indicator.

Cross-account and cross-organization deployment as PrivateLink’s signature use case

The deployment pattern PrivateLink is most architecturally distinctive for is exposing a service across account and even AWS Organization boundaries without any of the trust and routing complexity VPC peering or Transit Gateway would require for the same relationship. A single endpoint service, published once by a provider, can be consumed by any number of separate AWS accounts — each creating its own interface endpoint independently — with the provider controlling admission per-principal rather than needing a bespoke network relationship established with every consumer.

graph TB
  Consumer1[Consumer Account A VPC] -->|Interface Endpoint| Service[Endpoint Service]
  Consumer2[Consumer Account B VPC] -->|Interface Endpoint| Service
  Consumer3[Consumer Account C VPC] -->|Interface Endpoint| Service
  Service --> NLB[Provider NLB]
  NLB --> Backend[Provider Backend Fleet]
    

Interoperability with hybrid, on-premises connectivity

PrivateLink endpoints, being ordinary ENIs with private IPs inside a VPC, are reachable from on-premises networks connected via Direct Connect or Site-to-Site VPN exactly like any other resource in that VPC — meaning a hybrid architecture can extend private access to a PrivateLink-fronted service all the way back to an on-premises data center, without that service ever needing to be exposed publicly at any point in the path.

Infrastructure-as-code and the operational discipline of managing consumer allow-lists

Because a customer-managed endpoint service’s allowed-principal list is itself just a resource configuration, production deployments manage it declaratively alongside the endpoint service and NLB definition — treating “which customers are allowed to connect” as version-controlled infrastructure state rather than an ad hoc console change, which matters enormously for auditability in any regulated SaaS context.

Automating consumer-side endpoint provisioning at scale

Large enterprises consuming many internal PrivateLink-fronted platform services standardize on a shared infrastructure-as-code module that provisions an interface endpoint (with the correct subnets, security groups, and private DNS settings) as a reusable building block, so every application team consuming a shared service does so consistently rather than reinventing endpoint configuration — including AZ coverage — independently each time, which is exactly the kind of inconsistency that produces the single-AZ reliability gap covered earlier.

Service quota planning for provider-side scale

A provider anticipating rapid customer growth needs to track their endpoint-service-related quotas (accepted connections per endpoint service, for instance) with the same discipline as any other capacity-planning exercise, requesting quota increases ahead of projected growth rather than discovering a ceiling during a high-visibility customer onboarding event — a failure mode that’s entirely preventable with routine quota monitoring built into the same operational cadence as any other capacity review.

Pattern: PrivateLink as the standard SaaS multi-tenant access model

B2B SaaS vendors building on AWS overwhelmingly standardize on exposing their product through a customer-managed endpoint service rather than a public API endpoint plus IP allow-listing, because it eliminates the operational burden of maintaining and updating customer-side firewall rules every time the vendor’s own infrastructure IPs change — the private connection is stable by construction, tied to the endpoint relationship rather than to any specific IP address.

Pattern: shared-services VPC exposing internal platform APIs via PrivateLink

Large enterprises running many AWS accounts under an AWS Organization commonly centralize internal platform services (a shared logging API, a feature-flag service, an internal secrets broker) in one shared-services account, then expose each one through its own endpoint service, letting every other account in the organization consume them via interface endpoints without needing a Transit Gateway attachment or full network peering — a pattern that keeps blast radius contained to exactly the service being consumed, not the entire shared-services network.

Anti-pattern: using PrivateLink as a substitute for proper IAM authorization

Network-level access through PrivateLink (an accepted endpoint connection) is not equivalent to application-level authorization. A provider that assumes “if they can reach the endpoint, they’re authorized” and skips per-request authentication and authorization inside the application itself has confused network reachability with identity — anyone with access to the consumer VPC that owns the accepted endpoint can now reach the service, which is a much broader population than whatever the original authorization intent was.

Anti-pattern: single-AZ endpoint deployment for a multi-AZ dependent application

As covered in the reliability chapter, deploying an interface endpoint in only one AZ while the consuming application spans multiple AZs quietly reintroduces a single point of failure and adds unnecessary cross-AZ latency — a design smell that’s easy to miss during initial setup because it works perfectly fine until the one AZ with the endpoint has a problem.

Pattern: endpoint-per-tenant isolation versus shared-endpoint multi-tenancy

A provider can choose between provisioning a dedicated endpoint service per customer (maximizing isolation and blast-radius containment, at linear cost growth) or a single shared endpoint service consumed by many customer accounts through their own individual interface endpoints (lower cost, but a shared failure domain and shared NLB capacity across all tenants). Neither is universally correct — the decision depends on how strongly a given industry’s compliance posture or customer contracts demand tenant isolation versus how much cost sensitivity the business model can tolerate at scale.

Anti-pattern: forgetting that PrivateLink is regional when designing for disaster recovery

A DR plan that fails over an application to a second Region without also standing up (or already having) an endpoint service and interface endpoints in that second Region discovers, mid-incident, that the private connectivity to a critical dependency simply doesn’t exist in the failover Region — a gap that’s invisible during normal operation and only surfaces exactly when it’s most costly to discover.

The most common mistake: confusing gateway endpoints and interface endpoints

Because both are labeled “VPC endpoints” in the console and documentation, teams frequently apply interface-endpoint reasoning (ENIs, security groups, private DNS, per-AZ deployment, hourly charges) to gateway endpoints, which work through an entirely different, route-table-based mechanism with none of those properties. Getting this distinction wrong early in a design leads to real misconfiguration, not just terminology confusion. A team that budgets for per-AZ hourly endpoint charges on what’s actually a gateway endpoint has modeled a cost that will never materialize, while a team that assumes a gateway endpoint needs security-group configuration the way an interface endpoint does will spend time configuring a control that has no effect on that resource type at all.

The second most common mistake: treating an accepted connection as a trust boundary substitute

The single most consequential security mistake in PrivateLink architectures is skipping identity-based authorization on the assumption that “PrivateLink already handles access control.” PrivateLink controls who can reach the network path — it says nothing about who should be allowed to perform which actions once they’re on it, and that gap has to be closed at the application layer every time.

The third most common mistake: not planning for the regional boundary during DR design

Because PrivateLink connectivity doesn’t automatically extend across Regions, a disaster-recovery plan that assumes “our private connectivity will just work” after a regional failover needs to explicitly verify that an equivalent endpoint service and interface endpoints already exist, or can be provisioned quickly enough, in the failover Region — treating this as a DR runbook checklist item rather than an assumption baked silently into the failover plan.

Across all six of these patterns, the same underlying discipline recurs: PrivateLink gets chosen not because it’s the default option, but because the specific combination of cross-account trust, per-tenant isolation, and one-directional reachability it provides is exactly the shape of connectivity the use case actually needs — and no other AWS networking primitive offers quite that same combination. A team evaluating VPC peering, Transit Gateway, or a public API with IP allow-listing against PrivateLink for any of these scenarios would find each alternative solving a related but meaningfully different problem, which is exactly why PrivateLink earned its place as a distinct, named primitive rather than being absorbed into one of those broader connectivity options.

Every chapter above points back to the same underlying idea: PrivateLink’s value isn’t that it hides traffic from the internet — it’s that it replaces a bidirectional network relationship with a one-directional, ENI-mediated connection that scales to thousands of consumers without the provider ever exposing its own network topology. Designing around that asymmetry — not around PrivateLink as a generic “private connectivity” checkbox — is what separates an architecture that scales cleanly to hundreds of tenants from one that quietly accumulates operational debt with every new consumer.

The deepest lesson underneath every section here is that PrivateLink is not a feature bolted onto VPC networking — it’s a deliberate redesign of what “connecting two networks” even means, trading the broad, bidirectional reach of peering for a narrow, one-directional, explicitly-admitted path. That trade-off is exactly why it became the default connectivity model for nearly every service built to be consumed by parties you don’t fully trust with your network topology.