Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

Connecting VPCs

Two mechanisms join VPCs on the AWS network: VPC peering and AWS Transit Gateway. Both keep traffic off the public internet. The choice is about how many VPCs there are and whether traffic needs to pass through one connection to reach another.

VPC peering

Section titled “VPC peering”

A peering connection is a direct route between exactly two VPCs.

  • Works across accounts and across Regions.
  • Instances behave as though they were on the same private network, addressing each other by private IP.
  • Implemented in the AWS network fabric, not by an appliance: there is no gateway, no bandwidth tier and no single point of failure to size. It appears in route tables as a pcx-… target.
  • Non-transitive. If A is peered with B and with C, B and C still cannot reach each other. A cannot route between them.
  • CIDR blocks must not overlap. A peering connection between VPCs with overlapping ranges cannot be created.
  • Each connection needs route table entries and security group rules on both sides.

The shape is a star, not a mesh: one central VPC peered with four others gives five VPCs that can each reach the centre, and no path between the outer four. Building a full mesh instead needs n(n−1)/2 connections — 45 of them for ten VPCs — which is the point at which peering stops scaling.

Peering suits a small, stable set of connections: a shared-services VPC and a handful of consumers, or two VPCs that must exchange data and nothing more.

Transit gateway

Section titled “Transit gateway”

A transit gateway is a regional hub. Each VPC attaches once and the hub routes between attachments.

  • Transitive: attachments can reach each other, subject to the transit gateway route tables.
  • Scales to thousands of attachments — the default quota is 5,000 per transit gateway.
  • Shareable across accounts with AWS Resource Access Manager.
  • Also terminates Site-to-Site VPN and Direct Connect, so on-premises networks join the same hub.
  • Route tables give segmentation: separate tables can keep development attachments from reaching production ones.
  • Several transit gateways per Region are permitted — the default quota is 5 per account per Region, and a VPC can attach to up to 5 of them.

See Transit Gateway for quotas and detail.

Attachment rules

Section titled “Attachment rules”
  • An attachment needs one subnet in each Availability Zone where traffic should enter or leave the transit gateway. Other subnets in the same zone route through that attachment.
  • If a zone has no attachment subnet, resources in that zone cannot use the transit gateway. This is the most common cause of “it works from one subnet but not another”.
  • A dedicated small subnet per zone for attachments, separate from workload subnets, keeps this tidy.

Common arrangements

Section titled “Common arrangements”

Cross-Region. One transit gateway per Region, joined by peering attachments. Routes for the remote CIDR blocks go in both Regions’ transit gateway route tables and in the VPC route tables.

Cross-account. One transit gateway shared through Resource Access Manager. Each account attaches its own VPCs. All the VPCs on a single transit gateway are in the same Region; other Regions need their own gateway and a peering attachment.

Hybrid. Site-to-Site VPN and Direct Connect attach to the same transit gateway, so on-premises networks and every VPC share one routing domain.

Address planning

Section titled “Address planning”

Both mechanisms depend on non-overlapping address space, and neither can be retrofitted around an overlap.

  • A CIDR block is an address plus a prefix length; AWS supports /16 to /28 for VPCs and subnets.
  • AWS reserves five addresses in every subnet, so a /28 yields 11 usable addresses and a /24 yields 251.
  • Each halving of the prefix length doubles the address count: /28 is 16 addresses, /27 is 32, and so on to /16 at 65,536.

Allocate one non-overlapping block per account, environment and Region before the first VPC exists, leave headroom, and record it. See private IPv4 address planning.

Choosing

Section titled “Choosing”
VPC peeringTransit gateway
Number of VPCsA few, stableMany, growing
Transitive routingNoYes
Cross-RegionYes, directlyYes, via peering attachments
Hybrid connectivityNoYes
ChargesData transfer onlyAttachment-hours plus data processed
Operational overheadRoute entries per connection pairCentralised route tables

Peering costs less and is simpler for a handful of links. A transit gateway costs more per attachment but stops the route-table bookkeeping growing quadratically, and is the only option once on-premises connectivity or transitive routing is in scope.

Section titled “Related pages”