Articles

AWS PrivateLink vs VPC Peering: Which to Use (2026)

April 16, 2026 6 min read

PrivateLink and VPC Peering both connect AWS networks, but PrivateLink is the secure, scalable, and managed way to access services, while VPC Peering is the simpler, direct connection for your own networks.

Let’s see this in action. Imagine you have a microservice running in us-east-1 that needs to be accessed by another application in eu-west-2.

VPC Peering:

You’d set up a peering connection between the VPC in us-east-1 and the VPC in eu-west-2.

  • VPC A (us-east-1):
    • VPC CIDR: 10.1.0.0/16
    • Subnet: 10.1.1.0/24
    • EC2 instance IP: 10.1.1.10
  • VPC B (eu-west-2):
    • VPC CIDR: 10.2.0.0/16
    • Subnet: 10.2.1.0/24
    • Application IP: 10.2.1.20
  1. Initiate Peering Request: From VPC A, go to VPC dashboard -> Peering Connections -> Create Peering Connection.
    • Name tag: peering-us-east-1-to-eu-west-2
    • VPC ID (Requester): vpc-0a1b2c3d4e5f67890 (VPC A)
    • Account: 111122223333 (Your account ID)
    • Region: eu-west-2
    • VPC ID (Accepter): vpc-0f9e8d7c6b5a43210 (VPC B)
  2. Accept Peering Request: From VPC B, go to VPC dashboard -> Peering Connections. Find the request and accept it.
  3. Update Route Tables:
    • In VPC A’s route table for subnet 10.1.1.0/24, add a route:
      • Destination: 10.2.0.0/16 (VPC B’s CIDR)
      • Target: The peering connection ID (e.g., pcx-1234567890abcdef0)
    • In VPC B’s route table for subnet 10.2.1.0/24, add a route:
      • Destination: 10.1.0.0/16 (VPC A’s CIDR)
      • Target: The peering connection ID (e.g., pcx-1234567890abcdef0)
  4. Update Security Groups: Ensure the security group for the EC2 instance (10.1.1.10) in VPC A allows inbound traffic from 10.2.1.20 on the required port (e.g., TCP 8080). Similarly, update the security group for the application in VPC B.

Now, 10.2.1.20 can reach 10.1.1.10 directly using its private IP.

PrivateLink:

This is for when you have a service (e.g., a database, an API) that you want to expose to other AWS accounts or VPCs without making it public, and without the complexities of VPC peering across regions or accounts managed by different entities.

Let’s say you have an API in VPC A (us-east-1) that you want to provide as a managed service to a customer in VPC B (eu-west-2), and potentially other customers.

  1. Create a VPC Endpoint Service:

    • In VPC A, you’d create a Network Load Balancer (NLB) that fronts your API instances.
    • Then, go to VPC dashboard -> Endpoint Services -> Create Endpoint Service.
    • Select the NLB.
    • Set Acceptance required to Yes if you want to approve each connection.
    • This creates an Endpoint Service Name, e.g., com.amazonaws.vpce.us-east-1.vpce-svc-1234567890abcdef0.

  2. Create a VPC Endpoint (in the consumer’s VPC):

    • In VPC B (eu-west-2), the customer goes to VPC dashboard -> Endpoints -> Create Endpoint.
    • Service Category: Find service by name.
    • Service Name: com.amazonaws.vpce.us-east-1.vpce-svc-1234567890abcdef0 (the name from step 1).
    • VPC: vpc-0f9e8d7c6b5a43210 (VPC B).
    • Subnets: Select subnets in VPC B where you want the endpoint to reside (e.g., 10.2.1.0/24).
    • Security Group: Assign a security group to the endpoint.
    • This creates a VPC endpoint in VPC B. AWS provisions Elastic Network Interfaces (ENIs) in the specified subnets of VPC B, each with a private IP address.

  3. Accept the Connection (if required): Back in VPC A, on the Endpoint Services page, you’d see the pending connection request from VPC B. Accept it.

  4. Update Route Tables and Security Groups (in consumer’s VPC):

    • The application in VPC B (10.2.1.20) now accesses the service using the private IP address of one of the VPC endpoint ENIs in VPC B (e.g., 10.2.2.100).
    • You’d update the route table in VPC B to direct traffic for the service’s expected destination (or a specific CIDR if you’ve defined one for the service) to the endpoint ENI.
    • The security group attached to the VPC endpoint ENIs in VPC B must allow outbound traffic to the service (which will appear as traffic originating from the endpoint ENI’s IP).
    • The security group of the NLB in VPC A must allow inbound traffic from the CIDR range of VPC B or the specific security group of the endpoint ENIs.

The key difference is that PrivateLink creates a private connection to a service via a managed endpoint, abstracting away the underlying VPC networking. VPC peering is a direct network-to-network connection.

The Problem It Solves:

  • VPC Peering: Connects two VPCs directly. It’s simple for connecting your own networks, especially within the same region. It allows private IP communication between instances in different VPCs.
  • PrivateLink: Provides private connectivity to AWS services (like S3, DynamoDB, or your own custom services deployed as endpoints) hosted by another AWS account or by AWS itself. It keeps traffic off the public internet and within the AWS network, even across regions. It’s ideal for SaaS providers offering services to customers or for consuming AWS managed services privately.

Internal Mechanics:

  • VPC Peering: AWS modifies the network ACLs and route tables of both VPCs to allow traffic to flow between their respective CIDR blocks. It’s essentially a Layer 3 connection. Transitive routing is not supported (if VPC A peers with B, and B peers with C, A cannot talk to C through B).
  • PrivateLink: It uses Elastic Network Interfaces (ENIs) within the consumer’s VPC that act as private entry points to the service. These ENIs have private IP addresses from the consumer’s VPC. The traffic from these ENIs is then directed by AWS’s internal network to the service endpoint (often an NLB) in the provider’s VPC, without traversing the internet or requiring manual route table configurations across VPCs for the service itself. It supports cross-region and cross-account access seamlessly.

Levers You Control:

  • VPC Peering:
    • CIDR blocks of the peered VPCs (ensure they don’t overlap).
    • Route table entries in each VPC to direct traffic through the peering connection.
    • Security group and network ACL rules to permit traffic between specific instances or IP ranges.
  • PrivateLink:
    • Service Provider: Create the NLB, define the Endpoint Service, manage acceptance policies, and configure security groups for the NLB.
    • Service Consumer: Create the VPC endpoint, select subnets, assign security groups to the endpoint ENIs, and ensure route tables in their VPC point to the endpoint ENIs for the service’s traffic. You also control which accounts can connect via the Endpoint Service configuration.

The Counterintuitive Part:

While VPC peering appears simpler for connecting two VPCs, its limitations (no transitive routing, manual route table management across many VPCs, potential CIDR overlap headaches, and less granular control for service providers) make PrivateLink a more robust and scalable solution for exposing services, even if it involves more initial setup. You might think a direct network link is always simpler, but for complex or shared service architectures, the managed abstraction of PrivateLink offers significant benefits.

The next logical step after understanding PrivateLink is exploring how to secure and manage traffic for services exposed via PrivateLink, which often involves AWS Private Certificate Authority (PCA) for mTLS or advanced AWS WAF configurations.

Want structured learning?

Take the full Aws course →