Cloud Sandbox
All writing

PrivateLink: private service connectivity without joining networks

AWS PrivateLink lets consumers reach a specific service through private endpoints without creating general routed connectivity between the consumer and provider VPCs. This changes the network contract from joining address spaces to publishing one controlled capability.

about 23 minutes min read

Suppose bfstore, the fictional organisation used throughout this series, runs its catalog platform in one VPC.

A developer tool in another account needs to query it.

The familiar answer is to connect the networks.

CONSUMER VPC
10.64.0.0/16
      │
      ▼
VPC PEERING OR TRANSIT GATEWAY
      │
      ▼
PROVIDER VPC
10.80.0.0/16

That creates routing, return-path, CIDR, DNS, security and ownership decisions for both networks.

Sometimes that is exactly what I need.

Sometimes the requirement is much smaller:

The consumer needs to call
one HTTPS or TCP service.

It does not need routes to the provider CIDR or access to the provider’s databases, nodes and future services.

It needs one private endpoint representing one published capability.

AWS PrivateLink now supports private access to services, individual resources and VPC Lattice service networks.

This article focuses primarily on the classic pattern:

consumer interface endpoint
        │
        ▼
AWS PrivateLink
        │
        ▼
provider endpoint service
        │
        ▼
Network Load Balancer

Resource and service-network endpoints are distinguished later because they preserve the narrow-connectivity idea without always requiring an NLB-backed service.

PrivateLink provides access to a published service or resource. Peering and Transit Gateway connect routing domains.

That difference is the architecture.

VPC peering and Transit Gateway provide Layer 3 connectivity between networks.

ROUTED CONNECTIVITY

Consumer route:
    10.80.0.0/16 → network connection

Provider route:
    10.64.0.0/16 → return connection

An NLB-backed PrivateLink endpoint service does not give the consumer a route to the provider VPC.

The consumer creates endpoint ENIs inside its own subnets and connects to their local private addresses.

SERVICE CONNECTIVITY

Consumer application
        │
        ▼
Private IP in consumer subnet
        │
        ▼
AWS PrivateLink
        │
        ▼
One provider service

The relationship is consumer initiated.

Responses return normally, but the provider receives no route for starting arbitrary connections to consumer resources.

NETWORK CONNECTION

You may route towards this network.


PRIVATELINK ENDPOINT SERVICE

You may connect to this
published service.

The narrower model can also work when both VPCs use the same CIDR because the provider range is never installed as a consumer route.

CONSUMER VPC

10.0.0.0/16

endpoint:
10.0.20.25


PROVIDER VPC

10.0.0.0/16

service:
behind provider NLB

PrivateLink solves that service-access problem. It does not make poor IPAM harmless.

Overlap still complicates broad integration, recovery, hybrid routing, acquisitions and future migration.

It should not become an excuse to issue 10.0.0.0/16 to every VPC with the confidence of someone scattering identical house keys across a city.

The endpoint is a local representation of the remote service

The consumer creates an interface VPC endpoint.

For each selected subnet, AWS creates a requester-managed endpoint network interface and assigns it a private IP address from that subnet.

The interface is visible in the consumer account, but it cannot be managed like an ordinary customer-created ENI.

Suppose the consumer selects one subnet in each of three Availability Zones:

CONSUMER VPC

application-a
10.64.10.0/24
    └── endpoint ENI: 10.64.10.25

application-b
10.64.11.0/24
    └── endpoint ENI: 10.64.11.38

application-c
10.64.12.0/24
    └── endpoint ENI: 10.64.12.19

The client connects to one of those local addresses, normally selected through DNS.

CLIENT
  │
  ▼
REQUESTER-MANAGED ENDPOINT ENI
IN THE CONSUMER VPC
  │
  ▼
AWS PRIVATELINK
  │
  ▼
PROVIDER LOAD BALANCER
  │
  ▼
SERVICE TARGET

The endpoint is not a router leading into the provider VPC.

It is a local network representation of the remote service.

That distinction matters operationally.

Interface endpoints consume:

  • subnet addresses
  • endpoint ENIs
  • security groups
  • DNS configuration
  • hourly cost per selected Availability Zone
  • data-processing cost

A large endpoint estate therefore influences subnet capacity and operating cost even though the provider network remains hidden.

Private connectivity still occupies infrastructure.

It has moved the consumer-facing edge into the consumer’s address space.

The provider publishes an endpoint service

For the classic application-service pattern, the provider creates:

  1. a service workload
  2. a Network Load Balancer
  3. an endpoint service configuration backed by that NLB
  4. permissions identifying which AWS principals may request access
  5. an acceptance policy
  6. optional private DNS

Endpoint services can also use Gateway Load Balancers for network-appliance insertion. The ordinary client-server pattern in this article uses NLB.

PROVIDER VPC

service targets
      ▲
      │
Network Load Balancer
      ▲
      │
endpoint service
      ▲
      │
AWS PrivateLink
      ▲
      │
consumer interface endpoint

The NLB determines:

  • listeners
  • transport protocols
  • target groups
  • health checks
  • zonal availability
  • TLS termination or passthrough
  • load distribution

The endpoint service determines:

  • who may request a connection
  • whether requests require acceptance
  • which Regions are supported
  • which IP address families are supported
  • which private DNS name represents the service

The application still determines:

  • client authentication
  • authorisation
  • tenant isolation
  • request validation
  • business behaviour

PrivateLink gives those layers a narrow private path.

It does not replace them.

One endpoint service can use several NLBs

One NLB can be associated with only one endpoint service.

One endpoint service can, however, use several NLBs.

This is not request-by-request balancing between the load balancers.

When an endpoint ENI initiates its first connection, AWS selects an eligible NLB in the same Availability Zone. Later connections from that ENI continue using that selected NLB.

ENDPOINT ENI IN AZ A
        │
        ▼
one selected NLB in AZ A
        │
        ▼
same service contract

Multiple NLBs should therefore expose equivalent listeners, targets and service behaviour.

They are parallel implementations of one endpoint contract, not unrelated products hidden behind one service name.

Access requires several independent controls

Private connectivity is not the same as authorised application access.

1. Provider permission

2. Connection acceptance

3. Consumer endpoint security group

4. Provider NLB and target controls

5. Application authentication

6. Application authorisation

Permissions and acceptance

The provider grants selected AWS principals permission to request endpoint connections.

Requests may then be accepted automatically or reviewed individually.

PERMISSION

May this principal request access?


ACCEPTANCE

Is this endpoint connection approved?

Narrow permissions with automatic acceptance may suit a tightly governed organisation.

Broader permissions may justify manual acceptance.

Granting access to every principal and automatically accepting every request can make a privately addressed service broadly available to AWS consumers.

Endpoint security groups

The consumer associates security groups with the endpoint ENIs.

Endpoint inbound:

tcp/443
from bfstore-platform-client security group

This protects the consumer-facing door.

It does not authenticate the application caller.

NLB and target controls

When inbound security-group evaluation is enabled for PrivateLink traffic, the NLB evaluates the original client’s private IP rather than the endpoint ENI address.

Target security groups can reference the NLB security group so that targets accept traffic through the approved load-balancer path.

Endpoint policies

Endpoint policies provide IAM-style restrictions for supported AWS services.

They do not replace identity policies or service resource policies.

A customer endpoint service must enforce its own application authentication and authorisation.

Application identity

The provider should authenticate callers through a suitable mechanism, such as:

  • mutual TLS
  • OAuth or OIDC tokens
  • signed requests
  • workload identity
  • service-specific credentials

An accepted endpoint proves that an approved network consumer established a path.

It does not prove that every process in that VPC may perform every operation.

Source addresses and consumer identity are separate layers

PrivateLink changes what each layer sees.

NLB SECURITY-GROUP EVALUATION

may evaluate the original
consumer client private IP


PROVIDER TARGET SOCKET

normally sees the private IP
of an NLB node


PROXY PROTOCOL V2

can carry client IP
and interface endpoint ID
to a compatible application

When a consumer sends traffic through an interface endpoint, the provider target normally sees the private source address of an NLB node rather than the original workload address.

This means source CIDR alone is a weak application identity.

Several consumers may appear through load-balancer addresses.

Proxy Protocol v2 can carry additional connection metadata, including the client address and endpoint ID, when the target supports and validates that format.

That metadata is useful evidence.

It still does not replace application authentication.

The service should be able to answer:

Which endpoint was connected?

Which AWS principal was permitted?

Which client address reached the NLB?

Which application identity made the call?

Which tenant or account
did that identity represent?

PrivateLink narrows the network path.

It does not absolve the application from knowing who is using it.

DNS turns endpoint infrastructure into a service name

AWS creates Regional and zonal DNS names for interface endpoints.

Regional names can resolve across endpoint ENIs. Zonal names let clients select one endpoint Availability Zone where locality matters.

A provider can also associate one verified private DNS name, including a suitable wildcard domain, with its endpoint service.

When a consumer enables private DNS, AWS maps that name to the endpoint’s Regional DNS name and local private addresses.

api.platform.bfstore.example
        │
        ▼
PRIVATE DNS
        │
        ▼
endpoint ENI addresses
        │
        ▼
AWS PrivateLink
        │
        ▼
provider service

This can create split-horizon behaviour:

Outside the consumer VPC:

api.example.com
    → public endpoint


Inside a PrivateLink-enabled VPC:

api.example.com
    → interface endpoint ENIs

Troubleshooting should compare:

  • the queried name and resolver
  • VPC DNS support and hostnames
  • whether private DNS is enabled
  • returned A or AAAA records
  • Regional versus zonal endpoint DNS
  • reachability to each endpoint ENI
  • TLS certificate-name matching

A PrivateLink service with broken DNS exists beautifully but can be reached only by engineers carrying the endpoint hostname in a notebook.

Availability exists on both sides

The provider and consumer each choose Availability Zone coverage.

Provider side

The provider enables Availability Zones on the NLB.

The endpoint service becomes available in those zones.

AWS recommends at least two Availability Zones for fault tolerance and lower latency.

Consumer side

The consumer selects one subnet per Availability Zone for the interface endpoint.

AWS creates one endpoint ENI in each selected subnet.

CONSUMER                    PROVIDER

endpoint ENI A              NLB node A
      │                         │
      └──── PrivateLink ────────┘

endpoint ENI B              NLB node B
      │                         │
      └──── PrivateLink ────────┘

For same-Region endpoint services, consumers see the Availability Zones they have in common with the provider.

Cross-account AZ names such as eu-west-2a may represent different physical zones in different accounts. Availability Zone IDs provide the stable coordination key.

A consumer with one endpoint ENI has one consumer-side zonal entry point.

A provider with one enabled NLB zone has one provider-side service zone.

PrivateLink is highly available as a service.

The deployment still needs multiple independent locations.

The cloud can provide a resilient bridge.

It cannot add a second riverbank after I selected only one.

A provider can enable supported remote Regions for an endpoint service.

Consumers can then create interface endpoints in one Region that connect privately to a service hosted in another.

CONSUMER REGION
      │
      ▼
interface endpoint
      │
      ▼
AWS cross-Region PrivateLink
      │
      ▼
PROVIDER REGION

AWS manages Availability Zone failover within the participating Regions.

It does not fail over between separate provider Regions.

Regional disaster recovery remains a service-level design.

Cross-Region access also has practical constraints:

  • providers choose supported Regions
  • IAM and SCPs must permit multi-Region PrivateLink actions
  • in-Region access usually offers lower latency and cost
  • NLBs using a custom TCP idle timeout cannot use cross-Region access
  • UDP fragmentation is not supported across the cross-Region path
  • zonal DNS is not available for every cross-Region endpoint model

The charging responsibility is also split.

For an NLB-backed cross-Region interface endpoint:

  • the endpoint owner pays endpoint hours
  • the endpoint owner pays data processing
  • the endpoint owner pays inter-Region transfer in both directions
  • the provider pays the hourly charge for each active remote Region
  • the provider does not pay a second PrivateLink inter-Region transfer charge for that path

Cross-Region PrivateLink is not a global service mesh.

It is a regional private endpoint consuming a service in another Region.

NLB-to-ALB combines two boundaries, with constraints

A traditional endpoint service uses NLB because PrivateLink publishes a transport-layer service boundary.

The NLB can forward to:

  • instances
  • private IP targets
  • Kubernetes workloads through an appropriate target model
  • one Application Load Balancer registered as an alb target

The NLB-to-ALB pattern combines PrivateLink or static NLB endpoint behaviour with ALB’s Layer 7 request routing.

CONSUMER
   │
   ▼
INTERFACE ENDPOINT
   │
   ▼
PRIVATELINK
   │
   ▼
NLB
   │
   ▼
ALB
   │
   ├── host routing
   ├── path routing
   └── HTTP controls
           │
           ▼
        SERVICES

The pattern has important constraints:

same AWS account

same VPC

one ALB per NLB target group

TCP between NLB and ALB

target-group port matches
an ALB listener port

IPv4 between the load balancers

maximum two NLB associations per ALB

Registering an ALB also reduces the NLB target quota per Availability Zone.

The pattern is useful when the architecture genuinely requires both:

  • the PrivateLink endpoint-service contract
  • application-aware HTTP routing

It also introduces two load balancers, two health-check layers and two operational boundaries.

A simpler NLB-to-service path remains preferable when the provider already exposes one transport endpoint or when Envoy owns Layer 7 routing behind the NLB.

PrivateLink is broader than the classic NLB-backed endpoint-service pattern.

Interface endpoints

Interface endpoints use requester-managed endpoint ENIs to reach supported AWS services, partner services and customer endpoint services backed by NLB or GWLB.

This is the primary model in this article.

Resource endpoints

A resource endpoint can provide private access to an RDS database, EC2 instance, application endpoint, domain-name target or private IP through a VPC Lattice resource configuration and resource gateway.

It does not require an NLB.

A shared resource configuration can be consumed directly or associated with a service network.

That creates one transitivity nuance: a consumer may associate the resource with a shareable service network and expose it to further consumers.

This is transitive resource publication, not routed VPC transit.

The provider can prohibit association with service networks that are shareable between accounts.

Service-network endpoints

A service-network endpoint gives a VPC access to resources and VPC Lattice services associated with one service network.

One endpoint can expose several controlled services or resources.

Connections remain consumer initiated. The provider side does not gain a path for initiating arbitrary connections into the endpoint VPC.

Gateway Load Balancer endpoints

GWLB endpoints use PrivateLink to insert virtual network appliances and service chains.

Gateway endpoints

S3 and DynamoDB gateway endpoints use route-table entries and prefix lists.

They do not use AWS PrivateLink.

S3 gateway endpoint

private service access

but not PrivateLink

An NLB-backed endpoint service does not create network transit into the provider VPC.

A consumer can route to the endpoint ENIs from connected VPCs or on-premises networks, provided routing, DNS and security are deliberately configured.

ON-PREMISES OR SPOKE VPC
          │
          ▼
ROUTED CONNECTION
          │
          ▼
CENTRAL ENDPOINT VPC
          │
          ▼
INTERFACE ENDPOINT
          │
          ▼
PRIVATELINK SERVICE

This may support a central endpoint architecture.

It still gives those clients access to the endpoint service, not the provider’s complete routing domain.

The consumer-side network used to reach the endpoint may be shared.

The provider-side contract remains narrow.

Resource configurations need the additional redistribution rule described above because they can be placed in shareable service networks unless the provider prohibits it.

The more accurate model is:

NO GENERAL NETWORK TRANSIT

but possibly

SHARED ACCESS TO A
SPECIFIC ENDPOINT OR RESOURCE

PrivateLink narrows the object being shared.

It does not eliminate the need to govern who can reach that object.

Requirement NLB-backed PrivateLink endpoint service VPC peering Transit Gateway
Reach one published service Strong fit Possible but broader Possible but broader
General bidirectional VPC routing No Yes Yes
Consumer-initiated service access Yes Not inherently directional Not inherently directional
Overlapping provider and consumer CIDRs Supported for service access No No ordinary overlapping routing
General transitive routing No No Yes through configured hub routing
Central hybrid connectivity Endpoint can be reached through connected networks Limited Strong fit
Consumer sees provider CIDR No general route required Yes Yes
Provider requires NLB Yes for this classic model No No
Cost model Endpoint AZ hours, data and provider service infrastructure Connection and transfer effects Attachments and data processing
Best mental model Service contract Network pair Routed network hub

The answer may combine them.

For example:

TRANSIT GATEWAY

connects workload VPCs
to a central endpoint VPC


PRIVATELINK

connects that endpoint VPC
to a specific provider service

The technologies should be composed according to the boundaries they create.

They should not be ranked as three levels of networking sophistication.

Cost depends on the endpoint model

NLB-backed interface endpoints

The consumer pays for:

  • each provisioned endpoint hour in each Availability Zone
  • data processed through the endpoint
  • applicable cross-Region transfer

The provider may pay for:

  • NLB hours and capacity units
  • backend workload
  • cross-zone transfer
  • observability
  • active remote Regions for cross-Region access
CONSUMER COST

endpoint ENIs per AZ
+
processed data
+
possible cross-Region transfer


PROVIDER COST

NLB
+
service capacity
+
monitoring
+
possible remote-Region charges

A service consumed by ten VPCs may create ten sets of endpoint infrastructure.

That may be exactly the desired trade.

Each consumer receives private local addresses, independent security groups, separate lifecycle and no broad routed network.

Resource endpoints

Resource endpoints use their own hourly resource charge and data-processing model.

The provider-side resource gateway and VPC Lattice processing should also be included in the complete cost.

Service-network endpoints

A service-network endpoint does not have the same hourly endpoint charge as an interface endpoint.

Charges instead arise through associated resource configurations and VPC Lattice data processing.

At scale, compare:

  • endpoint per VPC
  • central endpoint VPC
  • resource endpoints
  • service-network endpoints
  • routed service connectivity
  • authenticated public APIs

Private is not automatically cheapest.

It is a connectivity and trust model with a meter attached.

Observability must cross the abstraction boundary

PrivateLink hides the provider network from the consumer.

It can also hide the consumer’s original source address from the provider target.

Evidence therefore needs to exist at several layers.

Consumer evidence

  • DNS query result
  • endpoint ID
  • endpoint ENI address
  • security-group decision
  • VPC Flow Logs
  • client connection metrics
  • application traces
  • endpoint and endpoint-service CloudWatch metrics
  • endpoint connection state
  • NLB security-group blocked-flow metrics
  • NLB connection and health metrics
  • target health

Provider evidence

  • service logs
  • Proxy Protocol metadata where used
  • authenticated application identity
  • endpoint-connection inventory
  • tenant attribution
  • authorisation results

The investigation path becomes:

Did DNS select the endpoint?

Could the client reach
the endpoint ENI?

Was the endpoint connection accepted?

Did NLB security allow the flow?

Did PrivateLink carry traffic?

Did the NLB select a usable target?

Did the application authenticate
and authorise the caller?

A green NLB target does not prove the consumer’s private DNS is correct.

A reachable endpoint ENI does not prove the provider accepted the connection.

An accepted connection does not prove the application token is valid.

PrivateLink narrows the path.

Troubleshooting still walks through each boundary.

Two bfstore use cases

Observability ingestion

bfstore’s observability account can publish one OpenTelemetry ingestion service to development, staging and production.

EKS workloads
      │
      ▼
interface endpoint
      │
      ▼
AWS PrivateLink
      │
      ▼
internal NLB
      │
      ▼
OpenTelemetry ingest gateway

A possible contract is:

service:
  name: bfstore-observability-ingest
  protocol: grpc
  port: 4317

provider:
  account: bfstore-observability
  availability_zones: 3
  acceptance_required: true

consumer_endpoint:
  availability_zones: 3
  private_dns: otel.internal.bfstore.example

security:
  endpoint_ingress:
    source: telemetry-agent-security-group
  application_identity:
    mechanism: mutual-tls

The application should identify the originating environment and cluster through mTLS, not trust the NLB-visible source address.

PrivateLink fits if observability needs one-way ingestion.

Transit Gateway may fit better if the VPCs need several bidirectional operational services.

Internal platform registry

The private OpenTofu module registry may live in the shared-services account.

WORKLOAD RUNNER
       │
       ▼
interface endpoint
       │
       ▼
PrivateLink service
       │
       ▼
shared platform gateway
       │
       ├── module registry
       └── approved platform API

The platform team publishes one DNS name, protocol contract, identity requirement and availability objective.

Workload accounts consume that contract without receiving routes to every shared-services subnet.

That is a stronger promise than:

Your account can route to
the platform VPC.

Please avoid the bits
that are not for you.

The decision table I use

Area Core question
Boundary Does the consumer need one service or general network connectivity?
Endpoint model Is the right object an NLB-backed service, one resource or a service network?
Direction Who must be able to initiate connections?
Protocol Does the service require TCP, UDP, TLS passthrough or Layer 7 routing behind the NLB?
Consumers Which principals may request endpoints, and which requests require acceptance?
Identity How will the application authenticate the real caller?
DNS Which Regional, zonal or private name should clients use?
Availability How many provider and consumer Availability Zones are required?
Redistribution May a shared resource configuration be added to a shareable service network?
Evidence How will the provider attribute calls when the target does not see the original client source?
Cost Which side pays endpoint, data, load-balancer, VPC Lattice and cross-Region charges?
Alternative Would peering, Transit Gateway, VPC Lattice or an authenticated public endpoint fit better?

These questions stop PrivateLink from becoming a fashionable tunnel placed between two VPC diagrams without a service contract.

The mental model I am keeping

My earlier model was:

AWS PRIVATELINK

a private way
to connect two VPCs

The stronger classic endpoint-service model is:

PROVIDER SERVICE
      │
      ▼
NLB
      │
      ▼
ENDPOINT SERVICE
      │
      ▼
AWS PRIVATELINK
      │
      ▼
CONSUMER ENDPOINT ENIs
      │
      ▼
CLIENT

Permissions and acceptance answer:

Who may request a connection,
and which request is approved?

The endpoint answers:

Where does the service appear
inside the consumer VPC?

Private DNS answers:

Which name resolves
to that private access point?

Application identity answers:

Which workload is actually
making the request?

And the missing provider CIDR route answers:

Which parts of the provider network
have not been shared?

Resource and service-network endpoints alter the object being published, but preserve the central idea:

The consumer does not join the provider’s routing domain. The provider publishes a controlled service, resource or service network, and the consumer installs a private access point inside its own VPC.

PrivateLink’s most important property is precision.

It is not a smaller Transit Gateway.

It is what I choose when joining the networks would be a larger promise than the service or resource requires.

References and further reading