Hey everyone!

Today I wanted to cover a very important topic that caused me some confusion when I first started studying. I only got clarity on it when I had to implement it in a real project.

When designing networks on AWS, one of the most important decisions is defining how different environments will communicate securely, scalably, and cost-effectively.

AWS offers several options for private connectivity between resources, but three services tend to generate frequent confusion:

  • VPC Peering
  • AWS Transit Gateway
  • AWS PrivateLink

At first glance, they seem to solve the same problem, but each one was built for completely different scenarios.

In this article we’ll analyze when to use each solution, their advantages, limitations, and practical examples from the day-to-day work of cloud architects.

Presenting the problem

Imagine a company with the following environments:

  • Production Account
  • Staging Account
  • Development Account
  • Security Account
  • Shared Services Account

Each environment has its own VPC and now there is a need for communication between them. The question is:

How do you connect these VPCs the right way?

The answer depends on the purpose of the communication.

Not every situation calls for connecting the entire network. In many cases it is enough to expose just one specific service.

That is exactly where the differences between Peering, Transit Gateway, and PrivateLink come into play.

VPC Peering

VPC Peering creates a direct private connection between two VPCs. After the connection is created, instances can communicate using private IP addresses.

How it works

VPC A  <------->  VPC B

Traffic stays within the AWS network and does not travel over the internet.

When to use it

Peering works best when there are only a few VPCs that need to communicate. Examples:

  • A Production environment accessing a Database VPC
  • Two applications that share internal services
  • Simple communication between different accounts

Advantages

  • Simple to set up
  • Low latency
  • No single point of failure
  • No additional appliance or gateway required

Limitations

No transitive routing

Consider:

VPC A <--> VPC B
VPC B <--> VPC C

VPC A cannot reach VPC C through VPC B.

You need to create another Peering:

VPC A <--> VPC C

Exponential growth

With just a few VPCs it works great, but imagine 20 VPCs fully interconnected.

The number of connections grows quickly.

N x (N-1) / 2

20 VPCs = 190 Peerings

Management becomes complex.

Real-world scenario

A company has:

  • Application VPC
  • Database VPC

Only these two networks need to talk to each other.

In this case, VPC Peering is usually the simplest and most cost-effective solution.

AWS Transit Gateway

Transit Gateway was built to solve the scaling problem of Peering.

It works as a central connectivity hub.

How it works

           VPC A
             |
             |
VPC B ---- TGW ---- VPC C
             |
             |
           VPC D

All VPCs connect to the Transit Gateway and routing happens through it.

When to use it

Ideal when there are many VPCs. Examples:

  • Multi-account environments
  • AWS Organizations
  • Landing Zones
  • Large enterprise environments

Advantages

Scalability

Adding a new VPC requires only a new attachment.

There is no need to create dozens of Peerings.

Transitive routing

Unlike Peering:

VPC A -> TGW -> VPC B
VPC A -> TGW -> VPC C

All of them can communicate as allowed by the route tables.

Integration with on-premises networks

The Transit Gateway can aggregate connections from:

  • Site-to-Site VPN
  • AWS Direct Connect
  • SD-WAN

Governance

Very useful for platform teams and Cloud Centers of Excellence.

Enables centralized connectivity control.

Limitations

Cost

Charges apply for:

  • Attachments
  • Processed traffic volume

For small environments it may cost more than Peering.

Complexity

Requires understanding of:

  • TGW Route Tables
  • Attachments
  • Traffic segmentation

Real-world scenario

A company has:

  • 50 AWS accounts
  • Production environment
  • Staging
  • Development
  • Security
  • Shared Services

Creating Peerings between all VPCs would be unmanageable. Transit Gateway becomes the natural architecture.

AWS PrivateLink

PrivateLink solves a different problem.

It was not built to connect networks — it was built to expose services. This is the key difference that often confuses certification candidates.

How it works

Imagine there is an API running in VPC A.

VPC B needs to consume that API.

With PrivateLink:

Consumer
(VPC B)

     |
     |
Endpoint
     |
     |
PrivateLink
     |
     |
NLB
     |
     |
Service
(VPC A)

The consumer accesses only the service — it does not gain access to the entire network.

When to use it

Whenever you want to share a service without sharing the VPC.

Examples:

  • Internal APIs
  • SaaS services
  • Corporate databases
  • Shared tools

Advantages

Smaller attack surface

The client cannot see:

  • Subnets
  • Routes
  • Internal resources

Only the published service.

Isolation

There is no full connectivity between VPCs.

Only access to the defined endpoint.

Cross-account sharing

Widely used by SaaS providers.

Limitations

Does not replace network connectivity

If you need to access multiple resources in a remote VPC, PrivateLink is probably not the right solution.

Requires an NLB

The published service normally sits behind a Network Load Balancer.

This adds components and costs.

Real-world scenario

A central team provides a corporate authentication service.

Dozens of AWS accounts need to consume that service. Granting full VPC access would be a security risk.

With PrivateLink, each consumer accesses only the required API.

Quick comparison

Feature VPC Peering Transit Gateway PrivateLink
Connects full networks Yes Yes No
Shares only a single service No No Yes
Scales to dozens of VPCs No Yes Yes
Transitive routing No Yes Not applicable
On-premises integration Limited Excellent No
Complexity Low Medium/High Medium
Best for Few VPCs Many VPCs Sharing services

What tends to show up on the certification exam

A simple way to remember:

Few VPCs?

Use VPC Peering.

Many VPCs?

Use Transit Gateway.

Need to share only one application or API?

Use PrivateLink.

Conclusion

The choice between VPC Peering, Transit Gateway, and PrivateLink does not depend solely on connectivity, but mainly on the desired architectural model.

VPC Peering is excellent for simple, direct scenarios.

Transit Gateway becomes essential when the number of VPCs grows and connectivity management needs to be centralized.

PrivateLink is the best option when the goal is to share specific services without exposing the entire network.

In modern enterprise projects it is common to find all three services coexisting:

  • Transit Gateway connecting corporate environments
  • VPC Peerings in specific low-complexity scenarios
  • PrivateLink exposing APIs and shared services across accounts

Understanding this distinction is fundamental both for passing the AWS Solutions Architect Associate certification and for building scalable, secure architectures in the real world.