DEV Community

Cover image for AWS VPC Peering vs Transit Gateway: A Practical Guide to Scalable Cloud Networking
Toqeer Afzal
Toqeer Afzal

Posted on

AWS VPC Peering vs Transit Gateway: A Practical Guide to Scalable Cloud Networking

#aws #cloudstorage #networking #tutorial

AWS VPC Peering vs Transit Gateway: A Practical Guide to Scalable Cloud Networking

*Modern cloud environments rarely stay simple.
*
A startup may begin with a single Amazon VPC and a few EC2 instances. As the organization grows, separate environments are introduced for production, development, testing, security, monitoring, analytics, and shared services.

Soon, an important question appears:

How should these networks communicate securely, privately, and at scale?

Two important AWS networking solutions commonly used to solve this problem are:

  • Amazon VPC Peering
  • AWS Transit Gateway

Both can connect VPCs using private networking, but they are designed for different architectural requirements.

In this article, we will compare VPC Peering and Transit Gateway from a practical cloud-engineering perspective, including routing, scalability, network design, real-world use cases, cost considerations, and hands-on AWS scenarios.

## The Short Answer

Before going deeper, remember this:

VPC Peering connects two VPCs directly.

Transit Gateway provides a centralized hub for connecting multiple VPCs and networks.

A simple VPC Peering architecture looks like this:

┌───────────────┐   **    VPC Peering  **     ┌───────────────┐
│    VPC-A      │────────────────────────│    VPC-B      │
│ 10.0.0.0/16   │                        │ 10.1.0.0/16   │
└───────────────┘                        └───────────────┘
Enter fullscreen mode Exit fullscreen mode

A Transit Gateway architecture looks like this:

                    ┌───────────────┐
                    │    Transit    │
                    │    Gateway    │
                    └───────┬───────┘
                            │
             ┌──────────────┼──────────────┐
             │              │              │
             ▼              ▼              ▼
          VPC-A           VPC-B           VPC-C
Enter fullscreen mode Exit fullscreen mode

The difference may look simple, but it becomes extremely important as your cloud environment grows.

1. What Is Amazon VPC Peering?

Amazon VPC Peering is a networking connection between two VPCs that allows resources in those VPCs to communicate using private IP addresses.

The VPCs can be in the same AWS Region or, where supported, across AWS Regions.

For example:

Application VPC
10.0.0.0/16
      │
      │
      │ VPC Peering
      │
      ▼
Database VPC
10.1.0.0/16
Enter fullscreen mode Exit fullscreen mode

An EC2 instance in the application VPC can communicate with a database or service in the second VPC using private addressing, assuming routing and security controls allow the traffic.

VPC Peering is particularly useful when you have a relatively small number of VPCs and a clear requirement for direct connectivity.

2. How VPC Peering Works

Creating a peering connection does not automatically make all traffic work.

Three major areas need to be considered:

  1. VPC Peering connection
  2. Route tables
  3. Security controls

Suppose we have:

VPC-A
CIDR: 10.0.0.0/16

VPC-B
CIDR: 10.1.0.0/16
Enter fullscreen mode Exit fullscreen mode

The route table associated with the relevant subnet in VPC-A could contain:

Destination       Target
10.1.0.0/16       pcx-xxxxxxxx
Enter fullscreen mode Exit fullscreen mode

VPC-B needs the return route:

Destination       Target
10.0.0.0/16       pcx-xxxxxxxx
Enter fullscreen mode Exit fullscreen mode

The security groups and network ACLs must also permit the required traffic.

This leads to an important AWS networking principle:

Connectivity is not the same thing as reachability.

A connection can exist while traffic still fails because of missing routes or security rules.

3. A Practical VPC Peering Scenario

Imagine a SaaS company has separated its application and data workloads.

Application VPC 

CIDR: 10.10.0.0/16
Enter fullscreen mode Exit fullscreen mode

Database VPC 

CIDR: 10.20.0.0/16
Enter fullscreen mode Exit fullscreen mode

The application needs private access to a database service.

The architecture could be:

┌──────────────────────┐
│   Application VPC    │
│    10.10.0.0/16     │
│                      │
│      EC2 / App       │
└──────────┬───────────┘
           │
           │ VPC Peering
           │
┌──────────▼───────────┐
│     Database VPC     │
│    10.20.0.0/16      │
│                      │
│    Database Tier     │
└──────────────────────┘
Enter fullscreen mode Exit fullscreen mode

The application subnet needs a route toward the database CIDR.

The database side needs a return route.

The database security group should allow only the required application traffic.

For example, if the application requires HTTPS:

Source: 10.10.0.0/16
Protocol: TCP
Port: 443
Enter fullscreen mode Exit fullscreen mode

In a production environment, avoid opening unnecessary ports or using broader access rules when more restrictive rules are possible.

4. The Most Important VPC Peering Limitation: No Transitive Routing

This is one of the most important concepts to understand.

Suppose:

VPC-A
   │
   │ Peering
   │
VPC-B
   │
   │ Peering
   │
VPC-C
Enter fullscreen mode Exit fullscreen mode

A common assumption is:

VPC-A → VPC-B → VPC-C
Enter fullscreen mode Exit fullscreen mode

But VPC Peering does not automatically provide this kind of transitive routing.

In other words:

A VPC cannot use another VPC as a router simply because both have peering connections.

If VPC-A needs direct connectivity to VPC-C, an appropriate connectivity design is required.

This becomes increasingly difficult to manage as the number of VPCs increases.

*5. Why VPC Peering Can Become Difficult at Scale
*
Imagine an organization with:

  • Production VPC
  • Development VPC
  • Testing VPC
  • Security VPC
  • Monitoring VPC
  • Shared Services VPC
  • Analytics VPC

If many of these VPCs need direct communication, a mesh of peering connections can become difficult to manage.

For a full mesh, the number of point-to-point connections is:

N × (N − 1) / 2

For example:

*| Number of VPCs *| *Full-Mesh Connections *|
| -------------: | --------------------: |
| 2 | 1 |
| 3 | 3 |
| 4 | 6 |
| 5 | 10 |
| 10 | 45 |
| 20 | 190 |

The mathematical problem is not the only concern.

You also have to think about:

  • Route tables
  • Security rules
  • Connection lifecycle
  • Network documentation
  • Troubleshooting
  • Change management
  • Operational ownership

This is where a centralized networking architecture becomes attractive.

6. What Is AWS Transit Gateway?

AWS Transit Gateway is a centralized network transit service that can connect multiple VPCs and supported network environments through a central hub.

Instead of creating direct connections between every VPC, each VPC can attach to the Transit Gateway.

                    ┌────────────────────┐
                    │   AWS Transit      │
                    │      Gateway       │
                    └─────────┬──────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
       VPC-A                VPC-B                VPC-C
Enter fullscreen mode Exit fullscreen mode

This is commonly described as a hub-and-spoke architecture.

The Transit Gateway acts as the hub.

The VPCs become the spokes.

7. Practical Transit Gateway Architecture**

Consider an organization with separate AWS environments:

                    AWS Transit Gateway
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
       ▼                    ▼                    ▼
 Production VPC       Security VPC        Shared Services
       │                                         │
       ▼                                         ▼
 Application                               Monitoring
Enter fullscreen mode Exit fullscreen mode

Additional VPCs can be connected to the same Transit Gateway according to the organization's architecture and routing requirements.

This approach can simplify connectivity management compared with maintaining a large collection of direct VPC-to-VPC connections.

## 8. Transit Gateway Routing

Transit Gateway introduces another important concept:

Transit Gateway route tables.

These allow network administrators to control how traffic is routed between Transit Gateway attachments.

For example:

                 Transit Gateway
                       │
             ┌─────────┴─────────┐
             │   TGW Route Table │
             └─────────┬─────────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
        VPC-A        VPC-B        VPC-C
Enter fullscreen mode Exit fullscreen mode

The VPC route tables still matter.

For example, VPC-A may need:

Destination: 10.20.0.0/16
Target: Transit Gateway
Enter fullscreen mode Exit fullscreen mode

The Transit Gateway then needs the appropriate route toward the attachment containing that destination.

A useful troubleshooting mindset is:

Source
  ↓
VPC Route Table
  ↓
Transit Gateway
  ↓
TGW Route Table
  ↓
Destination VPC
  ↓
Security Controls
Enter fullscreen mode Exit fullscreen mode

If connectivity fails, each layer should be checked.

## 9. Transit Gateway and Network Segmentation

One of the powerful features of a centralized architecture is the ability to design different connectivity domains.

For example:

                Transit Gateway
                       │
       ┌───────────────┼────────────────┐
       │               │                │
       ▼               ▼                ▼
   Production      Development       Security
      VPC              VPC             VPC
Enter fullscreen mode Exit fullscreen mode

An organization might want:

Production → Security       ✓
Production → Monitoring     ✓
Development → Shared        ✓
Development → Production    ✕
Enter fullscreen mode Exit fullscreen mode

The exact implementation depends on the organization's routing and security design, but the centralized model makes this kind of segmentation easier to manage.

This is especially useful in environments following principles such as:

  • Least privilege
  • Network segmentation
  • Environment isolation
  • Centralized security controls

## 10. VPC Peering vs Transit Gateway

Here is the practical comparison:

| Area *| VPC Peering * | Transit *Gateway * |
| -------------------- | -------------------------------- | --------------------------------------------- |
| Connectivity model | Point-to-point | Hub-and-spoke |
| Best suited for | Smaller/simple environments | Larger/multi-VPC environments |
| Centralized routing | No | Yes |
| Transitive routing | No | Supports centralized transit |
| Management | Distributed | More centralized |
| Network segmentation | More distributed | Centralized design option |
| Hybrid connectivity | Not its primary role | Strong use case |
| Initial complexity | Low | Higher |
| Scalability | Can become operationally complex | Designed for large-scale connectivity |
| Pricing model | Data transfer considerations | Attachment and data-processing considerations |

Pricing varies by architecture, traffic patterns, AWS Region, and service usage, so always check current AWS pricing when estimating costs.

## 11. When Should You Use VPC Peering?

VPC Peering is a good candidate when:

You have a small number of VPCs

For example:

Application VPC
      │
      │
   Peering
      │
      ▼
Shared Services VPC
Enter fullscreen mode Exit fullscreen mode

### You need direct connectivity

If two VPCs have a specific and well-defined communication requirement, direct peering may be simpler.

### You want a straightforward architecture

Fewer components can mean easier initial implementation and troubleshooting.

12. When Should You Use Transit Gateway?**

Transit Gateway becomes attractive when you have:

### Multiple VPCs

VPC-A ──┐
VPC-B ──┤
VPC-C ──┼── Transit Gateway
VPC-D ──┤
VPC-E ──┘
Enter fullscreen mode Exit fullscreen mode

### Centralized network management

You want routing and connectivity decisions to follow a centralized architecture.

### Hybrid networking requirements

Organizations may need to connect AWS environments with on-premises networks through supported connectivity architectures.

### Network segmentation

Different environments may need different communication policies.

### A growing cloud footprint

As AWS accounts, VPCs, Regions, and environments grow, a scalable network architecture becomes increasingly important.

13. Hands-On AWS Lab: Build VPC Peering

If you're learning AWS networking, don't stop at theory.

Try this lab.

Step 1 — Create VPC-A

Name: VPC-A
CIDR: 10.0.0.0/16
Enter fullscreen mode Exit fullscreen mode

Step 2 — Create VPC-B 

Name: VPC-B
CIDR: 10.1.0.0/16
Enter fullscreen mode Exit fullscreen mode

Make sure the CIDR ranges do not overlap.

Step 3 — Create the Peering Connection

In the AWS VPC console:

VPC → Peering connections → Create peering connection

Select the requester and accepter VPC.

Step 4 — Accept the Connection

Accept the peering request from the other VPC.

Step 5 — Update Route Tables

VPC-A:

10.1.0.0/16 → Peering Connection
Enter fullscreen mode Exit fullscreen mode

VPC-B:

10.0.0.0/16 → Peering Connection
Enter fullscreen mode Exit fullscreen mode

Step 6 — Configure Security Groups

Allow only the traffic required for your test.

Step 7 — Test Connectivity

Launch test instances and verify connectivity using an appropriate protocol.

Then intentionally remove a route and observe the failure.

This is a great way to understand how AWS routing actually works.

14.** Hands-On AWS Lab: Build a Transit Gateway**

Create three VPCs:

VPC-A → 10.0.0.0/16
VPC-B → 10.1.0.0/16
VPC-C → 10.2.0.0/16
Enter fullscreen mode Exit fullscreen mode

Step 1

Create a Transit Gateway.

Step 2

Create Transit Gateway attachments for the VPCs.

VPC-A ──┐
VPC-B ──┼── Transit Gateway
VPC-C ──┘
Enter fullscreen mode Exit fullscreen mode

Step 3

Update VPC route tables.

For example:

10.1.0.0/16 → Transit Gateway
10.2.0.0/16 → Transit Gateway
Enter fullscreen mode Exit fullscreen mode

Step 4

Configure the Transit Gateway route table according to your desired connectivity.

Step 5

Check security groups and network ACLs.

Step 6

Test traffic between the instances.

Then make the lab more interesting:

Try blocking Development → Production while allowing Development → Shared Services.

This turns a simple connectivity lab into a real network-design exercise.

15. A Real-World Cloud Architecture

Imagine an organization operating an e-commerce platform.

Its AWS environment contains:

  • Production
  • Development
  • Security
  • Monitoring
  • Shared Services
  • Analytics

A scalable architecture could look like:

                         ┌──────────────────┐
                         │ Transit Gateway  │
                         └────────┬─────────┘
                                  │
          ┌───────────────┬───────┼────────┬───────────────┐
          │               │       │        │               │
          ▼               ▼       ▼        ▼               ▼
     Production     Development Security Monitoring   Shared Services
        VPC              VPC        VPC       VPC          VPC
Enter fullscreen mode Exit fullscreen mode

Each environment can have its own CIDR range and security controls.

The network architecture can then define which environments are allowed to communicate.

This is closer to how enterprise cloud networking is designed than simply connecting every VPC to every other VPC.

16. Common AWS Networking Mistakes

Mistake 1: Assuming a connection automatically creates routes

It doesn't.

Always check the relevant route tables.

Mistake 2: Forgetting return traffic

Networking is bidirectional.

A route from A to B is not enough if B has no route back to A.

Mistake 3: Ignoring security groups

Correct routing does not override security controls.

Mistake 4: Assuming VPC Peering is transitive

It isn't.

Mistake 5: Choosing architecture only based on price

A low initial cost can become expensive operationally if the architecture becomes difficult to manage.

Mistake 6: Using overlapping CIDRs

Overlapping address ranges can create major networking limitations.

Good IP address planning should happen before connecting networks.

17. How to Choose Between Them

A useful way to approach the decision is to ask five questions.

1. How many VPCs do I have?

Two VPCs?

Peering may be enough.

Many VPCs?

Start evaluating a centralized architecture.

2. Do the VPCs need direct connectivity?

If only two environments need to communicate, direct peering may be simpler.

3. Do I need centralized routing?

If yes, Transit Gateway becomes more attractive.

4. Do I need network segmentation?

If different environments need different connectivity policies, a centralized architecture can simplify the design.

5. Will the environment grow?

Today's two-VPC architecture may become tomorrow's twenty-VPC architecture.

Good cloud architecture considers not only today's requirements but also reasonable future growth.

18. Interview Question: What Is the Difference?

Q*: What is the difference between VPC Peering and Transit Gateway?
*
A professional answer:

VPC Peering provides direct private connectivity between two VPCs, while Transit Gateway provides a centralized hub through which multiple VPCs and supported networks can connect. VPC Peering is often suitable for simple point-to-point requirements, whereas Transit Gateway is better suited to larger environments that require centralized routing, segmentation, and scalable network connectivity.

19. Interview Question: Does VPC Peering Support Transitive Routing?

No.

If:

A ↔ B
B ↔ C
Enter fullscreen mode Exit fullscreen mode

you cannot assume:

A ↔ C
Enter fullscreen mode Exit fullscreen mode

through B.

This is one of the most important differences to remember when designing AWS networks.

20. Is Transit Gateway Always Better?

No.

Architecture should be based on requirements.

For two VPCs:

VPC-A ───── VPC-B
Enter fullscreen mode Exit fullscreen mode

VPC Peering may be perfectly reasonable.

For dozens of VPCs:

VPC-A ──┐
VPC-B ──┤
VPC-C ──┤
VPC-D ──┼── **Transit Gateway**
VPC-E ──┤
VPC-F ──┘
Enter fullscreen mode Exit fullscreen mode

Transit Gateway may provide a much cleaner architecture.

The goal is not to use the most advanced service.

The goal is to use the right architecture for the problem.

21. Final Architecture Comparison

VPC Peering

                Direct Connectivity

┌───────────┐                  ┌───────────┐
│   VPC-A   │══════════════════│   VPC-B   │
└───────────┘                  └───────────┘
Enter fullscreen mode Exit fullscreen mode

Think:

"I need these two VPCs to communicate directly."

Transit Gateway 

                    ┌──────────────┐
                    │   Transit    │
                    │   Gateway    │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
           VPC-A         VPC-B        VPC-C
              │
              ▼
        Shared Network
Enter fullscreen mode Exit fullscreen mode

Think:

"I need a scalable central network architecture."

## Conclusion

AWS VPC Peering and Transit Gateway solve related but different networking problems.

VPC Peering is a direct connectivity model that works well when the number of VPCs and connectivity requirements are relatively simple.

Transit Gateway provides a centralized network hub that becomes increasingly valuable as environments grow and require scalable routing, segmentation, and connectivity between multiple networks.

The most important lesson is not simply memorizing the definitions.

It is understanding the architectural trade-off:

Simple network → consider direct connectivity.

Growing network → consider centralized connectivity.

Good cloud networking is not just about making two systems communicate.

It is about designing connectivity that remains:

  • Secure
  • Understandable
  • Scalable
  • Maintainable
  • Cost-conscious

If you're learning AWS networking, build both architectures yourself.

Create the VPCs.

Configure the routes.

Test connectivity.

Break a route.

Fix it.

Then build the same scenario with Transit Gateway.

That's when networking stops being a diagram and starts becoming a real engineering skill.

**## Key Takeaways

VPC Peering**

  • Direct VPC-to-VPC connectivity
  • Simple for smaller environments
  • No transitive routing
  • Distributed route management

** Transit Gateway**

  • Centralized hub-and-spoke architecture
  • Designed for connecting multiple networks
  • Centralized routing capabilities
  • Useful for scalable and hybrid cloud architectures

Final Thought

The real cloud-engineering skill is not knowing the definition of VPC Peering or Transit Gateway.

Top comments (0)