AWS Networking Decision Guide: Transit Gateway vs VPC Peering vs PrivateLink vs VPC Lattice vs Cloud WAN

AWS networking has five ways to connect VPCs and services. They're not interchangeable — each solves a different connectivity problem at a different cost point. Using Transit Gateway where VPC Peering suffices wastes money. Using VPC Peering where Transit Gateway is needed creates an unmanageable mesh.

This guide maps each connectivity option to its sweet spot, compares cost and complexity, and provides architecture patterns for real-world multi-account, multi-region deployments.

The Five Connectivity Options

┌──────────────────────────────────────────────────────────────────────┐
│                    AWS VPC CONNECTIVITY                                │
├──────────────┬──────────────┬───────────────┬──────────┬─────────────┤
│ VPC Peering  │Transit Gateway│  PrivateLink  │VPC Lattice│  Cloud WAN  │
│              │              │               │          │             │
│ Point-to-    │ Hub-and-     │ Service       │ Service  │ Global      │
│ point        │ spoke        │ endpoint      │ mesh     │ network     │
│              │              │               │          │             │
│ 2 VPCs       │ Many VPCs    │ Expose 1      │ Service- │ Multi-region│
│ directly     │ via hub      │ service       │ to-svc   │ backbone    │
│              │              │ privately     │ (L7+IAM) │             │
└──────────────┴──────────────┴───────────────┴──────────┴─────────────┘

Quick Decision Matrix

VPC Peering: Direct Point-to-Point

What it is: A direct, private network link between two VPCs. Traffic uses AWS backbone — no internet, no gateway devices.

Characteristics

When to Use VPC Peering

• 2-3 VPCs that need full network connectivity
• Lowest latency requirement (no intermediate router)
• Cost-sensitive with high data transfer (no per-hour charge)
• Simple topology that won't grow beyond ~5 connections

When NOT to Use VPC Peering

• 5+ VPCs (creates N×(N-1)/2 peering connections — unmanageable mesh)
• Need transitive routing (VPC A talking to VPC C through VPC B)
• Need centralized inspection/firewall
• Need on-premises connectivity through a single point

Architecture: VPC Peering Mesh

     VPC-A ←──── peer ────→ VPC-B
       ↑                       ↑
       │                       │
     peer                    peer
       │                       │
       ↓                       ↓
     VPC-C ←──── peer ────→ VPC-D

4 VPCs = 6 peering connections
10 VPCs = 45 peering connections ← don't do this

Transit Gateway: The Hub Router

What it is: A regional network hub that connects VPCs, VPN connections, and Direct Connect gateways through a single gateway. Think of it as a cloud router.

Characteristics

When to Use Transit Gateway

• 5+ VPCs needing connectivity
• Hub-and-spoke topology (centralized networking)
• On-premises connectivity (VPN or Direct Connect terminates at TGW)
• Network segmentation via multiple route tables
• Centralized egress (inspection VPC with Network Firewall)
• Multi-account landing zone networking

Transit Gateway Architecture: Segmented Network

                    ┌─────────────────────────┐
                    │     Transit Gateway      │
                    │                         │
                    │  Route Table: Prod      │
                    │  Route Table: Non-Prod  │
                    │  Route Table: Shared    │
                    └────┬───────┬───────┬────┘
                         │       │       │
              ┌──────────┤       │       ├──────────┐
              │          │       │       │          │
              ▼          ▼       ▼       ▼          ▼
         ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
         │Prod VPC│ │Dev VPC │ │Shared  │ │Inspect │
         │        │ │        │ │Services│ │VPC     │
         └────────┘ └────────┘ └────────┘ └────────┘

Segmentation: Prod route table only has routes to Shared Services and Inspection VPC. Dev cannot reach Prod directly.

TGW Route Table Segmentation

PrivateLink: Service Exposure Without Network Joining

What it is: Exposes a specific service (behind NLB) to other VPCs via an interface endpoint. Consumer VPC gets an ENI in their subnet that routes to the provider's service. Networks don't join — only that one service is accessible.

Characteristics

When to Use PrivateLink

• Expose ONE service to other VPCs without sharing entire network
• SaaS provider offering private connectivity to customers
• Shared services (API, database proxy) accessible across accounts
• Third-party vendor integration (many AWS Marketplace products use PrivateLink)
• Security: consumer cannot scan/discover other resources in provider VPC

Architecture: Shared Service via PrivateLink

Provider Account                    Consumer Account
┌──────────────────┐               ┌──────────────────┐
│  Service (EC2/ECS)│               │                  │
│       ↓          │               │   App Server     │
│     [NLB]        │               │       ↓          │
│       ↓          │               │  VPC Endpoint    │
│  Endpoint Service │◄─────────────│  (ENI in subnet) │
└──────────────────┘  PrivateLink  └──────────────────┘

Consumer's app calls the endpoint ENI's DNS → traffic flows privately to provider's NLB → reaches service. No internet, no peering, no TGW needed.

VPC Lattice: Service-to-Service (L7 + IAM)

What it is: Application-layer service mesh that provides service discovery, traffic management, and IAM-based authentication between services — across VPCs and accounts.

Characteristics

When to Use VPC Lattice

• Service-to-service communication with IAM auth (Zero Trust)
• Cross-account service discovery without network plumbing
• Weighted traffic routing between service versions (canary)
• Don't want to manage TGW/peering for service connectivity
• Need L7 visibility (HTTP method, path, status code in access logs)

VPC Lattice vs PrivateLink

VPC Lattice vs Transit Gateway

Rule: Use TGW when you need network-level connectivity (SSH, database ports, broad access). Use VPC Lattice when you need application-level service communication with identity auth.

Cloud WAN: Global Network Fabric

What it is: A managed global network that connects VPCs across regions and on-premises sites with centralized policy. Think of it as a multi-region Transit Gateway with global policy control.

Characteristics

When to Use Cloud WAN vs Transit Gateway

Cost Comparison

Cost impact at scale:

10 VPCs connected via TGW: $0.05 × 10 attachments × 730 hours = $365/month (before data transfer)

Same 10 VPCs via VPC Peering: 45 peering connections × $0/month (peering is free, but management overhead is high)

Architecture Patterns

Pattern 1: Multi-Account Landing Zone (Most Common)

Transit Gateway (centralized)
├── Shared Services VPC (AD, CI/CD, DNS)
├── Inspection VPC (Network Firewall, egress)
├── Production VPC (workloads)
├── Staging VPC (workloads)
├── Development VPC (workloads)
└── On-Premises (via Direct Connect / VPN)

+ PrivateLink for specific shared services (database proxy, API gateway)
+ VPC Lattice for microservice-to-microservice auth

Pattern 2: Hybrid Cloud (On-Premises + AWS)

On-Premises Data Center
      │
   Direct Connect (or VPN)
      │
      ▼
Transit Gateway
├── VPC: Production workloads
├── VPC: DR (disaster recovery)
└── VPC: Shared Services (DNS resolver, AD connector)

Pattern 3: SaaS Multi-Tenant (Provider)

SaaS Provider VPC
├── Service behind NLB
└── PrivateLink Endpoint Service
      │
      ├── Customer A VPC (endpoint) 
      ├── Customer B VPC (endpoint)
      └── Customer C VPC (endpoint)

Each customer has private access. Networks never join.

Common Networking Mistakes

Summary

AWS VPC connectivity comes down to what you're connecting and why:

The 2026 pattern for most enterprises: Transit Gateway for network backbone + VPC Lattice for service mesh + PrivateLink for external/vendor services + VPC Peering for the occasional simple 2-VPC connection.

Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS networking and cloud infrastructure automation. Connect on LinkedIn.