VPC peering vs Transit Gateway architecture is a choice between a mesh and a hub. A peering connection joins two VPCs, and only those two. A Transit Gateway is a hub you attach VPCs, VPNs, and Direct Connect to, then steer with its own route tables. Both move private traffic. They fail in different places, and they bill different meters. Picking the hub because it looks like a data center, for three VPCs that only need one link, adds an attachment hour and a processing fee you did not need. Picking a mesh for thirty VPCs adds a route on every pair and still will not share a VPN.
Rutagon draws the graph before we add either one. Terraform multi-account architecture is where the accounts and the CIDRs get decided. This article is the link between the VPCs once those CIDRs exist.
VPC peering vs Transit Gateway architecture, mesh or hub
The VPC peering documentation describes a one-to-one relationship. You can peer one VPC to many others. You do not get a path through the middle. If VPC A is peered to VPC B and VPC A is peered to VPC C, B and C are not peered, and A cannot carry traffic between them. The page states that transitive peering is not supported. To let B reach C you create a peering connection between B and C, and you add routes on both sides. The count of connections in a full mesh is the count of pairs. Four VPCs that all talk are six peerings. Each peering needs a route to the other CIDR in the route tables that should use it. Security groups on both sides have to allow the flow. In the same Region you can reference a security group in the peer VPC.
Overlapping CIDR blocks cannot be peered. If any IPv4 or IPv6 CIDR overlaps, the peering cannot be created, even when you meant to use only the non-overlapping range. A request that nobody accepts expires after 7 days. There can be only one peering between two VPCs at a time. A peered VPC cannot borrow the other VPC's internet gateway, NAT device, VPN, Direct Connect, or gateway endpoint. For jumbo frames, same-Region peering has an MTU of 9001 bytes, and inter-Region peering has an MTU of 8500 bytes. In a shared VPC, only the VPC owner can create, accept, reject, or delete the peering. Participants cannot.
Transit Gateway is the hub the peering page points at when those limits are the design. A transit gateway route table holds the routes for the attachments you associate with it. VPC, VPN, VPN Concentrator, Client VPN, Direct Connect gateway, peering, and Connect attachments can associate and propagate. An attachment can propagate into more than one route table. Static routes cover the cases propagation does not, including a backup path. You isolate environments by giving them different route tables: production propagates to production, and a shared-services attachment propagates to both, without giving dev a route to prod.
peering: one connection per pair, routes on both VPCs, no transitive hop
mesh_of_4: 6 peerings, each with routes and security group rules
transit_gateway: attachments plus a route table you associate and propagate
shared_egress: a NAT, VPN, or Direct Connect lives on the hub, not through a peer
cidr: peering refuses an overlap, including a spare CIDR you do not plan to useThe operational difference is who edits the route when a fifth VPC arrives. In the mesh, every VPC that must reach the new one gets a new peering and a new route. In the hub, you attach the VPC and propagate it into the route tables that should see it. The blast radius moves the other way. A bad route on a Transit Gateway route table can blackhole every attachment associated with that table. A bad route on a peering affects that pair.
What the hub costs, and what the mesh costs
Peering across an Availability Zone has a published data-transfer price. The VPC pricing page says data sent over a peering connection that crosses an Availability Zone in the same Region is $0.01 per GB in the "in" direction and $0.01 per GB in the "out" direction. A gigabyte that crosses zones is priced on both sides of that sentence. Cross-Region peering uses the EC2 data transfer rates the page points to. We do not treat "peering is free" as a design rule. Same-VPC traffic that never crosses a zone is a different path. The charge we quote is the cross-zone one the page states.
The Transit Gateway pricing page adds an attachment hour and a processing fee. In the US East (Ohio) example, the rate is $0.10 per hour ($0.05 per VPC attachment), and 1 GB sent from a VPC into the gateway is $0.02 of data processing, charged to the VPC owner who sent it. Partial attachment hours bill as a full hour, from the moment the attachment is accepted until it is deleted. A peering attachment between two gateways does not add a processing charge on the gateway that receives bytes from that peering. The N. Virginia to Oregon example splits 1 GB into $0.02 of processing on the sender and $0.02 of outbound inter-Region transfer.
For two or three VPCs in the same Region, with no shared VPN and no shared NAT, the mesh is the smaller machine. You pay the cross-zone peering rate when traffic crosses zones, and you do not pay an attachment hour. For a growing account set, a Direct Connect, or one internet egress VPC, the hub is the machine that can hold those attachments. The processing fee is the cost of sending the byte to that hub. We keep bytes off it when a gateway endpoint or a same-VPC path will do. PrivateLink architecture is the pattern for reaching one service in another VPC without peering the whole network and without sending the packet through the hub.
Stacking both is the design we unwind. A mesh plus a Transit Gateway, with routes that sometimes use the peer and sometimes use the hub, fails in two consoles. We pick one transitive path. If the hub exists, new VPCs attach to it. Old peerings come out when their routes are covered. If the hub does not exist, we do not add it to avoid drawing six routes.
How we choose, and what we leave alone
The diagnostic is a list of VPCs, their CIDRs, the flows that must exist, and whether any flow is "use someone else's NAT, VPN, or Direct Connect." Overlap in the CIDR list ends the peering option for that pair. A shared egress or a shared inspection point ends the pure mesh. A participant account in a shared VPC cannot create the peering anyway. The owner has to, which is another reason a platform account with a Transit Gateway attachment is the cleaner ownership line: the shared subnet rules already say only the VPC owner can attach a transit gateway to a shared subnet.
We leave a peering in place when it is one pair, the CIDRs are disjoint, both sides can edit their own route table, and neither side needs the other's gateway. We leave a Transit Gateway in place when the route table is the product: segmentation, a firewall attachment, and on-premises in one place. Move a working pair onto the hub when the next VPC would otherwise add a new spoke to every existing peer.
DNS and security groups ride along. Peering can resolve a public DNS name to the private IP once you enable DNS resolution on the connection, and same-Region security group references work across the peer. Transit Gateway routing is CIDR routing. Referencing a security group across an attachment is not what the route table does. Applications that depend on cross-VPC security group IDs are voting for peering, or for a shared VPC, which is a different article. We write that requirement down before we delete the peer.
Rutagon runs this as an architecture diagnostic. We draw the pairs, we mark which flows are transitive, we price cross-zone peering at the $0.01 per GB each way from the VPC page, and we price the hub from the Transit Gateway example only after we name the Region. Then we keep the mesh or we keep the hub. The peering documentation is the source for the missing transitive hop. The route table documentation is the source for how the hub actually steers.
Frequently Asked Questions
Can one VPC peering carry traffic for a third VPC?
No. Peering is one-to-one. If A is peered with B and A is peered with C, B cannot reach C through A. You create a peering between B and C and add routes on both sides. That missing hop is the reason a mesh grows with every pair, and the reason a Transit Gateway route table exists.
When is a Transit Gateway the wrong hub?
Two or three VPCs that only need to reach each other, with no shared NAT, VPN, or Direct Connect, are a peering. The hub adds an attachment hour, $0.05 per VPC attachment in the US East (Ohio) example, and $0.02 of data processing per gigabyte sent into the gateway in that same example. Pay that when the route table or the shared attachment is doing work the mesh cannot do.
Does peering have a data charge?
Data that crosses an Availability Zone on a peering connection in the same Region is $0.01 per GB in and $0.01 per GB out on the VPC pricing page. Cross-Region peering follows EC2 data transfer rates. A Transit Gateway adds its own processing fee on bytes sent into the gateway, on top of those data transfer charges. Budget the rate the page prints.
What breaks the mesh before the route count does?
Peering cannot be created when any CIDR overlaps, even a range you do not intend to route. A pending request expires after 7 days. In a shared VPC only the owner can create or accept the peering, so a participant account cannot close the mesh itself. A fifth VPC that overlaps one existing CIDR stops that pair.
Can a peered VPC use the other VPC's NAT or VPN?
The peering documentation says no. Internet gateways, NAT devices, VPN connections, Direct Connect, and gateway endpoints stay in their own VPC. Traffic from the peer cannot walk out through them. A Transit Gateway attachment is how those edge connections become a shared next hop, with the processing fee on the bytes you send to the gateway.
Ask for an architecture diagnostic that chooses a mesh or a hub from the flows you actually have. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.