Updated October 25, 2026
· ~2 min read
Connecting VPCs used to mean peering or Transit Gateway. Now there are five options, and they work at different layers. Peering, Transit Gateway and Cloud WAN connect networks: anything can reach anything the route tables allow. PrivateLink and VPC Lattice connect services: a consumer reaches one service, and nothing else, even across overlapping IP ranges.
Most organizations past a handful of accounts use one network-layer option and one service-layer option.
Transit Gateway and Cloud WAN make networks reachable. Security then depends on route tables, security groups and network ACLs, and on IP ranges that do not overlap. That is the right model for shared infrastructure, on-premises connectivity and workloads that need many ports. PrivateLink and Lattice make one service reachable. The consumer never sees the provider's network, overlapping CIDRs do not matter, and in Lattice an auth policy can require a specific IAM role for a specific path. That is the right model for internal APIs between teams and for SaaS providers serving customers' VPCs. Lattice costs more per GB than Transit Gateway, so for high-volume flows such as replication or bulk data movement the network layer is cheaper.
Question 1 of 3
Do you need whole networks connected, or specific services?
**A few VPCs, simple needs:** peering. No hourly charge, but it does not scale past a small mesh and is not transitive. **Many VPCs, one or two Regions, on-premises links:** Transit Gateway. The standard hub, with route tables for segmentation. **A global network across many Regions with policy-defined segments:** Cloud WAN. More expensive per Region, much less to manage by hand. **Exposing one service to other accounts or customers:** PrivateLink. **Many services calling each other across accounts, with IAM authorization:** VPC Lattice.
AWS Landing Zone Foundation
Enterprise-grade AWS account structure designed for security, scalability, and compliance from day one.
Multi-Region Disaster Recovery
Implement a tested disaster recovery strategy that meets your RTO and RPO, before you need it.
AWS Architecture Review
A focused, senior-level review of your current AWS architecture, with a prioritized list of what to fix and why.
We work with startups and growing companies on AWS architecture decisions. Tell us about your situation and we will recommend the right approach.
As of October 25, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.