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
| If you need to... | Use... |
|---|---|
| Connect 2-3 VPCs directly (simple) | VPC Peering |
| Connect 5+ VPCs through a central hub | Transit Gateway |
| Expose a service to other VPCs without network joining | PrivateLink |
| Service-to-service auth (IAM) across VPCs/accounts | VPC Lattice |
| Global multi-region network with policy | Cloud WAN |
| Connect on-premises to AWS | Transit Gateway + VPN/Direct Connect |
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
| Property | Detail |
|---|---|
| Topology | Point-to-point (1 peering = 2 VPCs) |
| Transitive | ❌ No (A↔B and B↔C doesn't give A↔C) |
| Cross-account | ✅ Yes |
| Cross-region | ✅ Yes (inter-region peering) |
| Bandwidth | No limit (same as within VPC) |
| Latency | Lowest (no intermediate hop) |
| Cost | Free (same-AZ), $0.01/GB (cross-AZ/region) |
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
| Property | Detail |
|---|---|
| Topology | Hub-and-spoke (star) |
| Transitive | ✅ Yes (all attachments can reach each other via route tables) |
| Cross-account | ✅ Yes (share via RAM) |
| Cross-region | ✅ Yes (TGW peering between regions) |
| Bandwidth | 50 Gbps per VPC attachment |
| Max attachments | 5,000 per TGW |
| Route tables | Multiple (enables segmentation) |
| Cost | $0.05/hr per attachment + $0.02/GB processed |
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
| Route Table | Can Reach | Cannot Reach |
|---|---|---|
| Production | Shared Services, Inspection, On-Premises | Development, Sandbox |
| Development | Shared Services, Inspection | Production |
| Shared Services | Production, Development | Direct internet |
| On-Premises | Production, Shared Services | Development |
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
| Property | Detail |
|---|---|
| Topology | Provider → Consumer (one-directional) |
| Network joining | ❌ No (only specific service is exposed) |
| Cross-account | ✅ Yes |
| Cross-region | ✅ Yes (since 2023) |
| Protocol | TCP (NLB-based) |
| Cost | $0.01/hr per endpoint + $0.01/GB processed |
| Security | Consumer only sees the endpoint ENI, not provider's network |
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
| Property | Detail |
|---|---|
| Layer | L7 (HTTP/HTTPS/gRPC) + TCP |
| Auth model | IAM (SigV4) — identity-based, not network-based |
| Cross-account | ✅ Native (service networks) |
| Cross-VPC | ✅ No peering/TGW needed |
| Service discovery | Built-in (DNS-based) |
| Traffic management | Weighted routing, health checks |
| Observability | Built-in access logs |
| Cost | Per request + per GB |
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
| Criteria | PrivateLink | VPC Lattice |
|---|---|---|
| Layer | L4 (TCP via NLB) | L7 (HTTP/gRPC + TCP) |
| Auth | Network-level only | IAM (SigV4) per request |
| Discovery | Manual DNS config | Built-in service discovery |
| Traffic mgmt | None | Weighted routing |
| Direction | One-way (provider → consumer) | Bidirectional |
| Best for | Exposing services to external consumers | Internal service mesh |
VPC Lattice vs Transit Gateway
| Criteria | Transit Gateway | VPC Lattice |
|---|---|---|
| Layer | L3/L4 (network routing) | L7 (application routing) |
| Joins networks? | Yes (full network reachability) | No (only specific services) |
| Auth | Security groups / NACLs | IAM per request |
| Use case | Full network connectivity | Service-to-service only |
| Cost model | Per attachment-hour + GB | Per request + GB |
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
| Property | Detail |
|---|---|
| Scope | Multi-region, global |
| Policy | Centralized network policy (segments, sharing, inspection) |
| On-premises | Direct Connect, Site-to-Site VPN |
| Segmentation | Network segments (like TGW route tables, but global) |
| Cost | Core network edge per hour + per GB |
| Best for | Large enterprises with 10+ regions and complex segmentation |
When to Use Cloud WAN vs Transit Gateway
| Criteria | Transit Gateway | Cloud WAN |
|---|---|---|
| Scope | Single region | Global (multi-region) |
| Cross-region | TGW peering (manual per region pair) | Automatic (policy-driven) |
| Policy | Route tables per TGW | Global segment policy |
| Complexity | Medium | High (enterprise-grade) |
| Cost | Lower | Higher |
| Best for | Single-region or 2-3 regions | 5+ regions with consistent policy |
Cost Comparison
| Service | Hourly Cost | Data Processing |
|---|---|---|
| VPC Peering | Free | $0.01/GB (cross-AZ/region) |
| Transit Gateway | $0.05/hr per attachment | $0.02/GB |
| PrivateLink | $0.01/hr per endpoint | $0.01/GB |
| VPC Lattice | No hourly | $0.025/GB + $0.10/million requests |
| Cloud WAN | $0.05/hr per attachment + core edge | $0.02/GB |
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
| Mistake | Problem | Fix |
|---|---|---|
| VPC Peering mesh with 10+ VPCs | Unmanageable, no transitive routing | Transit Gateway |
| TGW for 2-3 VPCs | Over-engineered, unnecessary cost | VPC Peering |
| All traffic through TGW (including AWS API calls) | High data processing charges | VPC endpoints for S3, DynamoDB (free gateway endpoints) |
| No network segmentation on TGW | Dev can reach prod | Multiple TGW route tables |
| PrivateLink when you need bidirectional | PrivateLink is one-way | VPC Lattice or TGW |
| Overlapping CIDRs between VPCs | Can't peer or TGW connect | Plan CIDR with IPAM from day one |
| Single AZ for NAT Gateway | AZ failure = no egress | NAT GW per AZ |
Summary
AWS VPC connectivity comes down to what you're connecting and why:
| Need | Service | Cost |
|---|---|---|
| 2-3 VPCs, full connectivity, lowest cost | VPC Peering | Free (hourly) |
| 5+ VPCs, hub-and-spoke, centralized routing | Transit Gateway | $$ |
| Expose one service privately, no network joining | PrivateLink | $ |
| Service-to-service with IAM auth, no network plumbing | VPC Lattice | $$ |
| Global multi-region with policy-driven segmentation | Cloud WAN | $$$ |
| On-premises to AWS | TGW + Direct Connect/VPN | $$-$$$ |
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.
Top comments (0)