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 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 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 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 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) Pattern 2: Hybrid Cloud (On-Premises + AWS) Pattern 3: SaaS Multi-Tenant (Provider) Common Networking Mistakes Mistake Problem Fix VPC Peering mesh with 10+ VPCs Unmanageable, no transitive routing Transit Gateway TGW for 2-3 VPCs Over-engineer