SAABlog
NetworkingIntermediate

VPC Peering vs Transit Gateway: When to Choose Which?

Use VPC Peering for small-scale VPC connections, Transit Gateway for large hub-spoke architectures. Master this essential SAA-C03 topic on VPC connectivity options.

PHILOLAMB-Updated: January 31, 2026
VPCVPC PeeringTransit GatewayNetworkingHybrid

Related Exam Domains

  • Domain 1: Design Secure Architectures
  • Domain 2: Design Resilient Architectures

Key Takeaway

For small-scale VPC connections (2-3), VPC Peering is simpler and cheaper. For large networks (10+) or on-premises connectivity, Transit Gateway is the better choice. VPC Peering is 1:1 without transitive routing, while Transit Gateway provides hub-spoke architecture connecting all VPCs centrally.

Exam Tip

Exam Essential: VPC Peering = 1:1 non-transitive + low latency + low cost, Transit Gateway = hub-spoke + transitive routing + scalability

VPC Connectivity Options at a Glance

AspectVPC PeeringTransit Gateway
Connection Type1:1 Point-to-PointHub-Spoke
Transitive RoutingNot supportedSupported
Max Connections125 per VPC5,000 VPCs
LatencyLowest (direct)Slightly higher (extra hop)
Management ComplexityIncreases with VPC countCentralized management
On-premises ConnectivityNot directly possibleVPN/Direct Connect supported
CostData transfer onlyAttachment + data processing
Cross-regionSupportedSupported

VPC Peering

What is VPC Peering?

VPC Peering establishes a private network connection between two VPCs. Resources communicate using private IPs as if on the same network.

VPC Peering Structure:

    VPC A                           VPC B
┌─────────────┐   Peering      ┌─────────────┐
│ 10.0.0.0/16 │ ←───────────→  │ 10.1.0.0/16 │
│             │   Connection   │             │
│ ┌─────────┐ │                │ ┌─────────┐ │
│ │ EC2     │ │ ←──────────→   │ │ RDS     │ │
│ │10.0.1.5 │ │  Private IP    │ │10.1.2.10│ │
│ └─────────┘ │                │ └─────────┘ │
└─────────────┘                └─────────────┘

Key VPC Peering Characteristics

1. Non-Transitive

VPC Peering only allows communication between directly connected VPCs. If A-B and B-C are peered, A-C cannot communicate.

Non-Transitive Routing:

VPC A ←──→ VPC B ←──→ VPC C

A → B: ✅ Possible
B → C: ✅ Possible
A → C: ❌ Not possible (direct peering required)

2. No CIDR Overlap

The CIDR blocks of peered VPCs must not overlap.

❌ Cannot peer:
VPC A: 10.0.0.0/16
VPC B: 10.0.0.0/16  ← Same CIDR

✅ Can peer:
VPC A: 10.0.0.0/16
VPC B: 10.1.0.0/16  ← Different CIDR

3. Manual Route Table Configuration

After creating a peering connection, you must manually update each VPC's route table.

VPC A Route Table:
Destination: 10.1.0.0/16 → Target: pcx-xxxxxxxx (Peering Connection)

VPC B Route Table:
Destination: 10.0.0.0/16 → Target: pcx-xxxxxxxx (Peering Connection)

Calculating VPC Peering Connections

To fully connect N VPCs (Full Mesh), you need:

Required peering connections = N × (N-1) / 2

Examples:
- 3 VPCs: 3 × 2 / 2 = 3 peerings
- 5 VPCs: 5 × 4 / 2 = 10 peerings
- 10 VPCs: 10 × 9 / 2 = 45 peerings
- 20 VPCs: 20 × 19 / 2 = 190 peerings

When to Use VPC Peering

Use CaseReason
2-3 VPC connectionsLow management complexity
Lowest latency requiredDirect connection, no extra hops
Cost minimizationNo attachment fees
Simple architectureNo on-premises connectivity needed

Exam Tip

Exam Point: VPC Peering does not support transitive routing. With A-B-C connections, A-C communication is not possible!

Transit Gateway

What is Transit Gateway?

Transit Gateway is a central hub that connects multiple VPCs and on-premises networks. It implements hub-spoke architecture.

Transit Gateway Structure (Hub-Spoke):

                    ┌─────────────────┐
                    │ Transit Gateway │
                    │      (Hub)      │
                    └────────┬────────┘
           ┌─────────────────┼─────────────────┐
           │                 │                 │
           ↓                 ↓                 ↓
    ┌───────────┐     ┌───────────┐     ┌───────────┐
    │   VPC A   │     │   VPC B   │     │   VPC C   │
    │  (Spoke)  │     │  (Spoke)  │     │  (Spoke)  │
    └───────────┘     └───────────┘     └───────────┘
           │                                   │
           └─── A ↔ B ↔ C all communicate ────┘

Key Transit Gateway Characteristics

1. Transitive Routing

All networks connected to Transit Gateway can communicate with each other.

Transitive Routing:

VPC A ──┐
        │
VPC B ──┼── Transit Gateway
        │
VPC C ──┘

A → B: ✅ Possible
B → C: ✅ Possible
A → C: ✅ Possible (via TGW)

2. Hub-Spoke Architecture

Centralized management reduces connection count and simplifies management.

Connection Count Comparison (10 VPCs):

VPC Peering (Full Mesh): 45 connections
Transit Gateway: 10 connections (each VPC → TGW)

3. Multiple Connection Types

Connection TypeDescription
VPC AttachmentVPC connections
VPN AttachmentSite-to-Site VPN
Direct ConnectDirect Connect Gateway
PeeringPeering with other Transit Gateways
ConnectSD-WAN appliance connections

4. Route Tables

Transit Gateway has its own route tables for fine-grained traffic control.

Transit Gateway Route Table:

Destination       → Target
10.0.0.0/16       → VPC A Attachment
10.1.0.0/16       → VPC B Attachment
10.2.0.0/16       → VPC C Attachment
0.0.0.0/0         → VPN Attachment (on-premises)

Advanced Transit Gateway Features

1. Routing Domain Isolation

Separate traffic with multiple route tables:

Route Table 1 (Production):
├── VPC Prod A
└── VPC Prod B

Route Table 2 (Development):
├── VPC Dev A
└── VPC Dev B

→ Production and development environments isolated

2. Multicast

Transit Gateway supports multicast traffic (VPC Peering does not).

3. Inter-Region Peering

Inter-Region Transit Gateway Peering:

Seoul Region TGW ←──────→ Virginia Region TGW
       │                        │
       ↓                        ↓
    VPC A, B                VPC C, D

→ Build global network

When to Use Transit Gateway

Use CaseReason
10+ VPC connectionsReduced management complexity
On-premises connectivity neededVPN/Direct Connect integration
Centralized managementSingle control point
Complex routing requirementsMultiple route tables
Future expansion plansEasy to add VPCs

Exam Tip

Exam Point: Transit Gateway supports transitive routing + on-premises (VPN/DX) connectivity

Cost Comparison

VPC Peering Cost

VPC Peering Cost Structure:

Attachment cost: Free
Data transfer:
├── Same AZ: $0.01/GB (both directions)
├── Different AZ: $0.01/GB (both directions)
└── Different Region: $0.02/GB (sender pays)

Transit Gateway Cost (Seoul Region)

Transit Gateway Cost Structure:

Attachment cost: $0.07/hour/attachment
├── 1 VPC attachment: $0.07 × 730 hours = $51.1/month
├── 5 VPC attachments: $51.1 × 5 = $255.5/month
└── 10 VPC attachments: $51.1 × 10 = $511/month

Data processing: $0.035/GB

Cost Scenario Comparison

Scenario: 5 VPCs, 1TB data transfer/month

VPC Peering (Full Mesh, 10 connections):
├── Attachment cost: $0
├── Data transfer: $0.01 × 1,024 = $10.24
└── Total: ~$10/month

Transit Gateway:
├── Attachment cost: $0.07 × 730 × 5 = $255.5
├── Data processing: $0.035 × 1,024 = $35.84
└── Total: ~$291/month

→ VPC Peering is cheaper for small scale
Scenario: 20 VPCs, 10TB data transfer/month

VPC Peering (Full Mesh, 190 connections):
├── Attachment cost: $0
├── Data transfer: $0.01 × 10,240 = $102.4
├── Management complexity: Very high (190 connections)
└── Total: ~$102/month + high operational cost

Transit Gateway:
├── Attachment cost: $0.07 × 730 × 20 = $1,022
├── Data processing: $0.035 × 10,240 = $358.4
├── Management complexity: Low (centralized)
└── Total: ~$1,380/month + low operational cost

→ Transit Gateway is more management-efficient for large scale

Selection Criteria Guide

Decision Flowchart

VPC Connectivity Option Selection:

Do you need on-premises connectivity?
       │
       ├── YES → Transit Gateway
       │
       └── NO → How many VPCs?
                    │
                    ├── 2-3 → VPC Peering
                    │
                    ├── 4-10 → Compare complexity/cost
                    │
                    └── 10+ → Transit Gateway

Detailed Selection Criteria

RequirementVPC PeeringTransit Gateway
2-3 VPC connections✅ RecommendedPossible
10+ VPCsComplex✅ Recommended
Lowest latency✅ OptimalSlightly higher
Cost minimization (small scale)✅ OptimalHigher
On-premises VPN/DX✅ Required
Transitive routing✅ Supported
Centralized management✅ Supported
Future expansionLimited✅ Flexible

Scenario-Based Solutions

Scenario 1: Dev-Prod VPC Connection

Requirements: 2 VPCs, simple connection
Choice: VPC Peering
Reason: $0 cost, simple setup, lowest latency

Scenario 2: Multi-Account Environment (10+ VPCs)

Requirements: 10+ VPCs, centralized management
Choice: Transit Gateway
Reason: Simplified management, transitive routing

Scenario 3: Hybrid Cloud

Requirements: VPC + on-premises data center connection
Choice: Transit Gateway + VPN or Direct Connect
Reason: VPC Peering cannot connect to on-premises

Scenario 4: Global Network

Requirements: Connect Seoul, Virginia, Frankfurt regions
Choice: Transit Gateway + Inter-Region Peering
Reason: Implement global hub-spoke architecture

Scenario 5: Environment Isolation (Dev/Staging/Prod)

Requirements: Environment isolation, shared services VPC access
Choice: Transit Gateway + Multiple Route Tables
Reason: Traffic separation with routing domains

SAA-C03 Exam Focus Points

  1. VPC Peering non-transitive: A-B-C connected but A-C cannot communicate
  2. Transit Gateway transitive: All connected networks can communicate
  3. No CIDR overlap: Both peering and TGW fail with overlapping CIDRs
  4. On-premises connectivity: Only Transit Gateway supports VPN/Direct Connect
  5. Cost: VPC Peering = data only, TGW = attachment + data
  6. Routing: Peering requires manual, TGW has central route tables

Exam Tip

Sample Exam Question: "A company operates 3 VPCs. VPC A and B are peered, VPC B and C are peered. How can an instance in VPC A access a database in VPC C?" → Answer: Add a direct peering connection between VPC A and C (VPC Peering doesn't support transitive routing)

Frequently Asked Questions

Q: Can I use VPC Peering and Transit Gateway together?

Yes, you can. If you need lowest latency between specific VPCs, peer them directly while connecting the rest via Transit Gateway—a hybrid configuration.

Q: How much does Transit Gateway increase latency?

Generally within a few milliseconds. Negligible for most workloads, but for ultra-low-latency requirements (high-frequency trading, etc.), VPC Peering may be more suitable.

Q: Why does my VPC Peering connection fail?

The most common cause is CIDR overlap. Also check route table configuration, security group/NACL blocks, and DNS resolution issues. Verify that the peering request was accepted.

Q: Can I block communication between specific VPCs in Transit Gateway?

Yes, control it with route tables. Create separate route tables with specific VPC associations, or add blackhole routes to drop traffic.

Q: Can I connect to VPCs in other AWS accounts?

Both options support it. VPC Peering requires sending a request that the other party must accept. Transit Gateway can be shared with other accounts using Resource Access Manager (RAM).

Q: How do I migrate from VPC Peering to Transit Gateway?

Gradual migration is recommended. Create the Transit Gateway, attach VPCs one by one, update route tables, and finally delete the existing peering connections.

References