Skip to content

PrivateLink for a SaaS provider

Exposing a service from your VPC to many customer VPCs is the case AWS PrivateLink was designed for. It scales to thousands of consumers, across accounts you do not control, with no peering connections, VPNs or Direct Connect circuits to negotiate — and no requirement that anybody’s address space line up.

The provider creates an endpoint service in front of a Network Load Balancer or a Gateway Load Balancer, and adds the consumer accounts to its allowed principals. The load balancer sits in front of the application.

The consumer creates an interface VPC endpoint to that service name. Endpoint network interfaces appear in the consumer’s chosen subnets with private addresses from the consumer’s own ranges.

Traffic between them stays on the AWS network. Connections are one-directional: the consumer initiates, the provider responds. The provider never gains a route into the consumer’s VPC, and vice versa.

flowchart TD subgraph consumer["Consumer VPC"] direction TB subgraph consumerPrivate["Private Subnet"] EC2["EC2 Instance"] VPCE["Interface VPC Endpoint (ENI)"] RT1["Route Table"] end CSG["Consumer Security Group"] end subgraph provider["Service Provider VPC"] direction TB subgraph providerPrivate["Private Subnet"] APP["Application Servers"] NLB["Network Load Balancer"] RT2["Route Table"] end PSG["Provider Security Group"] subgraph endpoint["VPC Endpoint Service"] EPSVC["Endpoint Service (AWS PrivateLink)"] end end subgraph shared["AWS PrivateLink Infrastructure"] direction TB DNS["DNS Service"] PLNET["PrivateLink Network"] end EC2 --> VPCE VPCE -.->|"Protected by"| CSG VPCE --> PLNET APP --> NLB APP -.->|"Protected by"| PSG NLB --> EPSVC EPSVC --> PLNET PLNET -.->|"DNS Resolution"| DNS classDef awsService fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:white classDef networkComponent fill:#4595D4,stroke:#232F3E,stroke-width:2px,color:white classDef vpc fill:#E7F4FF,stroke:#232F3E,stroke-width:2px classDef security fill:#DD3522,stroke:#232F3E,stroke-width:2px,color:white classDef shared fill:#95DAB6,stroke:#232F3E,stroke-width:2px,color:black class APP,NLB awsService class EC2,VPCE,EPSVC,PLNET networkComponent class consumer,provider,consumerPrivate,providerPrivate vpc class CSG,PSG security class DNS,shared shared
  1. Put the application behind a Network Load Balancer (for TCP, UDP and TLS) or a Gateway Load Balancer (for transparent inspection appliances).
  2. Create the endpoint service against that load balancer, choosing whether connection requests are accepted automatically or manually.
  3. Add the consumer accounts, roles or users as allowed principals. Until you do, nobody can create an endpoint.
  4. Optionally associate a private DNS name with the service, so consumers can use your public hostname unchanged. AWS requires domain ownership verification by TXT record before this is permitted.
  5. Enable the endpoint service in every Availability Zone your consumers use, or they will need cross-zone traffic to reach you.

Endpoint service metrics appear in the AWS/PrivateLinkServices CloudWatch namespace, including a per-endpoint breakdown through Contributor Insights — which is how you find out which customer is generating the load.

  1. Obtain the service name from the provider.
  2. Create an interface endpoint in private subnets, one per Availability Zone.
  3. Attach a security group that permits only the required ports.
  4. Leave private DNS enabled where the provider offers it.
  5. Confirm the endpoint reaches available — it stays pendingAcceptance until the provider accepts.

Peering joins two networks: every route table entry the other side adds becomes reachable, and the address spaces must not overlap. An endpoint service publishes exactly one service. The consumer reaches that service and nothing else in the provider’s VPC, and the two VPCs can use identical private ranges without consequence.