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.
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
| Aspect | VPC Peering | Transit Gateway |
|---|---|---|
| Connection Type | 1:1 Point-to-Point | Hub-Spoke |
| Transitive Routing | Not supported | Supported |
| Max Connections | 125 per VPC | 5,000 VPCs |
| Latency | Lowest (direct) | Slightly higher (extra hop) |
| Management Complexity | Increases with VPC count | Centralized management |
| On-premises Connectivity | Not directly possible | VPN/Direct Connect supported |
| Cost | Data transfer only | Attachment + data processing |
| Cross-region | Supported | Supported |
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 Case | Reason |
|---|---|
| 2-3 VPC connections | Low management complexity |
| Lowest latency required | Direct connection, no extra hops |
| Cost minimization | No attachment fees |
| Simple architecture | No 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 Type | Description |
|---|---|
| VPC Attachment | VPC connections |
| VPN Attachment | Site-to-Site VPN |
| Direct Connect | Direct Connect Gateway |
| Peering | Peering with other Transit Gateways |
| Connect | SD-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 Case | Reason |
|---|---|
| 10+ VPC connections | Reduced management complexity |
| On-premises connectivity needed | VPN/Direct Connect integration |
| Centralized management | Single control point |
| Complex routing requirements | Multiple route tables |
| Future expansion plans | Easy 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
| Requirement | VPC Peering | Transit Gateway |
|---|---|---|
| 2-3 VPC connections | ✅ Recommended | Possible |
| 10+ VPCs | Complex | ✅ Recommended |
| Lowest latency | ✅ Optimal | Slightly higher |
| Cost minimization (small scale) | ✅ Optimal | Higher |
| On-premises VPN/DX | ❌ | ✅ Required |
| Transitive routing | ❌ | ✅ Supported |
| Centralized management | ❌ | ✅ Supported |
| Future expansion | Limited | ✅ 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
- ✅ VPC Peering non-transitive: A-B-C connected but A-C cannot communicate
- ✅ Transit Gateway transitive: All connected networks can communicate
- ✅ No CIDR overlap: Both peering and TGW fail with overlapping CIDRs
- ✅ On-premises connectivity: Only Transit Gateway supports VPN/Direct Connect
- ✅ Cost: VPC Peering = data only, TGW = attachment + data
- ✅ 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.
Related Posts
- VPC Basics: CIDR, Subnets, Route Tables
- NAT Gateway vs NAT Instance
- VPC Endpoints (Interface vs Gateway)