Amazon VPC peering and Transit Gateway are the two primary mechanisms for connecting multiple virtual private clouds within an AWS region. Both provide layer-3 connectivity, but they differ fundamentally in transitivity, scalability, operational model, and cost structure. Architects who choose peering for a five-VPC deployment may celebrate simplicity; the same choice at fifty VPCs creates a full-mesh routing nightmare. Understanding when each pattern applies prevents costly redesigns after a cloud landing zone grows beyond its initial footprint.
VPC peering creates a direct network path between two VPCs. Routes in each VPC's route tables must explicitly point destination prefixes to the peering connection. Security groups and network ACLs filter traffic independently in each VPC — peering provides reachability, not permission. Peering works within a region, across regions through inter-region peering, and even across accounts with appropriate acceptance workflows. It does not support transitive routing, overlapping CIDR blocks, or edge-to-edge encryption within the peering connection itself.
VPC Peering Mechanics
Establishing peering requires creating a peering connection request from one VPC and accepting it from the other side — same account or cross-account. Both VPCs must have non-overlapping CIDR ranges, though multiple CIDR blocks per VPC are supported. Update route tables in every subnet that needs reachability, pointing remote VPC CIDRs to the peering connection ID. Security group rules must allow the desired traffic — a common oversight is adding routes but forgetting to open security groups, producing asymmetric blackholes where ICMP works but application ports do not.
DNS resolution across peering is not automatic. Enable DNS resolution on the peering connection and configure private hosted zone associations or Route 53 resolver rules so instances resolve private hostnames in peer VPCs. Cross-account peering for DNS additionally requires resource sharing through RAM for private hosted zones. Peering charges apply only to data transfer — there is no hourly fee for the peering connection itself, making it cost-effective for steady moderate traffic between two VPCs.
Transit Gateway Architecture
Transit Gateway acts as a regional hub connecting VPCs, VPN attachments, Direct Connect gateway attachments, and peering attachments to other Transit Gateways. Each attachment associates with a route table on the TGW that controls which destinations are reachable through which attachments. This hub-and-spoke model scales to thousands of attachments without full-mesh peering between every pair. Centralized inspection VPC designs route all inter-VPC and egress traffic through firewall appliances attached to the TGW.
TGW introduces hourly charges per attachment plus per-gigabyte data processing fees. At scale, these costs exceed peering data transfer alone but buy operational simplicity — adding a new VPC means one attachment and route table updates rather than peering with every existing VPC. Transit Gateway Network Manager provides visualization and monitoring across the attachment topology. For multi-region architectures, inter-region TGW peering connects regional hubs while maintaining separate route domains per region.
Decision Framework
Use VPC peering when connecting two or three VPCs with straightforward routing, especially for high-throughput east-west traffic where avoiding TGW processing charges matters. Peering suits shared services VPCs with a handful of workload VPCs where the shared VPC peers individually with each consumer. Choose Transit Gateway when the VPC count exceeds single digits, when you need centralized egress through a NAT gateway or firewall VPC, or when aggregating site-to-site VPN and Direct Connect connectivity alongside VPC attachments.
Hybrid designs are common: TGW as the regional hub with peering between specific high-traffic VPC pairs that would otherwise hairpin through the TGW — though this adds routing complexity that must be carefully documented. Evaluate total cost of ownership including engineering time spent managing peering mesh growth versus TGW attachment fees. A rule of thumb: if your peering connection diagram looks like a complete graph, migrate to Transit Gateway before the next major VPC addition.
Inspection and Security VPCs
Centralized inspection routes traffic through firewall or IDS appliances before delivery to destination VPCs. Configure TGW route tables so spoke VPC attachments propagate routes to the inspection VPC attachment, and the inspection VPC return routes point back through appliance subnets that perform SNAT or transparent forwarding. Appliance scaling and high availability within the inspection VPC are critical — a firewall cluster failure affects all inter-VPC traffic.
Gateway load balancer integration with TGW simplifies deploying scalable inspection fleets. Traffic destined for inspection is steered to GWLB endpoints that distribute flows across appliance instances. This pattern supports vendor firewalls and open-source IDS platforms with horizontal scaling. Test asymmetric routing carefully — appliances must see both directions of a flow or stateful inspection fails silently.
Hybrid Connectivity Integration
Transit Gateway aggregates on-premises connectivity through site-to-site VPN and Direct Connect gateway attachments alongside VPC spokes. Route propagation from on-premises BGP sessions advertises corporate prefixes to the TGW route table, which distributes them to attached VPCs. This replaces legacy hub VPC designs that terminated VPN on a single VPC and peered to others. Direct Connect with TGW provides consistent hybrid routing with predictable latency compared to internet VPN backup paths.
Plan CIDR allocation before deploying either pattern. Overlapping VPC CIDRs with on-premises networks require NAT during migration or renumbering — neither peering nor TGW resolves address conflicts. Use IPAM tools and enforce allocation policies through AWS Organizations Service Control Policies that prevent VPC creation with unapproved CIDR ranges. AWS VPC connectivity choices made during initial landing zone deployment echo through years of cloud growth — invest design time upfront to select the pattern that matches your projected scale and operational model.
IPv6 and Multi-Region Considerations
VPC peering supports IPv6 with separate route table entries for IPv6 CIDR blocks. Dual-stack VPC designs require both address families in peering route tables and security group rules. Transit Gateway supports IPv6 attachments with similar hub-and-spoke routing patterns as IPv4, enabling centralized inspection of both families through firewall appliances configured for dual-stack.
Inter-region peering and Transit Gateway peering connect regional hubs for global architectures. Latency between regions is physics-limited — design applications to prefer regional resources rather than crossing continents for routine traffic. Data residency requirements may prohibit cross-region peering for certain data classifications; enforce with SCPs preventing peering connections between specific regional accounts.
IPv4 address conservation through peering differs from NAT gateway usage — peering provides direct routing without NAT, requiring non-overlapping CIDR planning. When overlapping CIDRs exist between acquired companies, NAT gateways or NAT instances at peering boundaries translate addresses at the cost of operational complexity. Plan address remediation during acquisition integration rather than permanent NAT at peering as a long-term solution.