All projects
Cloud

Private Multi-VPC Service Access

Private service access across three isolated AWS networks. PrivateLink connects consumers without exposing the rest of the network.

PrivateLink architecture diagram from the project write-up
Architecture diagram

At a glance

  • 3 VPCs, 0 peering connections
  • Service EC2 has no public IP
  • Traffic stays on the AWS backbone
  • Consumer approval is per-endpoint

VPC · PrivateLink · NLB · Endpoint Services · Security Groups

Architecture

Two consumer VPCs reach a shared service through PrivateLink interface endpoints, with no peering between themPAYMENTS VPCInterface Endpointprivate IP, in-VPCANALYTICS VPCInterface Endpointprivate IP, in-VPC✕ no path between consumersSHARED SERVICES VPCVPC Endpoint Serviceowner approves each consumerNetwork Load Balancerinternal-facingEC2 · internal appno public IPAWS private backbonenever traverses the internetService-level access, not network-level reachability.

Scroll the diagram horizontally to explore the full flow.

The problem

Payments and Analytics both needed an internal service owned by Shared Services. The consumer VPCs needed access to that service, but they did not need access to each other or to the rest of the provider network.

Exposing the service publicly would have turned a network boundary into an application-authentication problem. VPC peering would have connected entire networks when the requirement was access to one service.

The decision

I published the service through an internal Network Load Balancer and an AWS PrivateLink endpoint service. Each consumer receives an interface endpoint inside its own VPC, and the service owner approves consumers individually.

The resulting network has three VPCs and zero peering connections. The application instance has no public IP, and the consumer networks have no route to one another.

The trade-off

PrivateLink has hourly and data-processing costs that peering does not. The Network Load Balancer also changes what the application sees as the source address. That loss of direct client identity matters for observability and per-consumer logging.

What broke

Per-consumer logs came back without the identity I expected. The NLB rewrites the source address before the request reaches the instance, so the application could not distinguish Payments from Analytics using the packet source.

The correct recovery is to enable Proxy Protocol v2 on the endpoint service and parse its header at the application layer. The useful lesson was that network reachability and consumer identity are separate concerns.

Shape of the build

  • Three isolated VPCs
  • One internal endpoint service behind an NLB
  • No public service instance
  • Per-endpoint consumer approval
  • Security groups scoped to the service path
View Markdown on GitHubRead the write-up