VPC Peering vs Transit Gateway: Choosing the Right VPC Connectivity Pattern#
When you start building on AWS with multiple virtual private clouds, you’ll quickly face a fundamental architectural question: how do you connect them? The answer determines not just your network topology, but your operational complexity, costs, and ability to scale. The two primary solutions—VPC Peering and AWS Transit Gateway—take fundamentally different approaches, and choosing between them requires understanding their tradeoffs.
Let’s start with the uncomfortable truth: many teams pick wrong initially, then spend months untangling a brittle mesh of peering connections or overengineering a Transit Gateway for what should have been a simple setup. By the end of this article, you’ll understand when each makes sense and why.
Understanding VPC Peering: The Direct Connection Model#
VPC Peering is the simpler option conceptually. It’s a direct, one-to-one connection between two VPCs that allows them to communicate as if they were on the same network. You create a peering connection, accept it (if it’s cross-account), update route tables, and traffic flows.
The beauty of VPC Peering is its simplicity and cost-effectiveness. You pay only for the data that crosses the peering connection—no hourly charges, no attachment fees. If you’re running workloads that rarely traverse your peering connections, this pricing model is hard to beat. There’s also minimal operational overhead; a peering connection has no management plane to worry about.
But here’s where things get interesting: VPC Peering is non-transitive. This phrase matters enough that it deserves emphasis: if VPC A peers with VPC B, and VPC B peers with VPC C, traffic cannot flow from A to C through B. Each peering connection is its own isolated tunnel. Your instances in VPC A cannot reach instances in VPC C unless you create an explicit peering connection between A and C.
This non-transitivity seems like an odd design choice until you consider it from a security perspective. Each peering connection is independently controlled. VPC B’s administrators cannot accidentally expose traffic from A to C without explicitly allowing it. The blast radius of any misconfiguration is limited to the two VPCs directly involved.
The Mesh Problem at Scale#
Now imagine you have ten VPCs. How many peering connections do you need if every VPC needs to talk to every other VPC?
The formula is N*(N-1)/2, where N is the number of VPCs. With ten VPCs, that’s 45 separate peering connections. With twenty VPCs, you’re at 190 connections. Suddenly, what seemed manageable has become an operational nightmare.
Each peering connection needs its own route table entries across both sides. Each connection is a separate entity that needs monitoring, troubleshooting, and maintenance. If a peering connection between VPC 5 and VPC 12 fails, you’ll spend time investigating whether it’s a route table problem, a network ACL issue, a security group misconfiguration, or something else entirely. At scale, this becomes genuinely difficult to manage.
Consider a realistic scenario: you have three application tiers (frontend, middleware, backend) with multiple VPCs per tier for isolation or regional distribution. With VPC Peering, every tier needs to talk to every other tier. You’re managing potentially dozens of connections. Adding a new VPC means creating and configuring peering connections to every VPC it needs to reach. Removing a VPC requires careful cleanup of multiple connections.
Transit Gateway: The Hub-and-Spoke Revolution#
AWS Transit Gateway takes a radically different architectural approach. Instead of mesh-style connections, you have a central hub (the Transit Gateway itself) that sits in the middle. Each VPC attaches to this hub with a single Transit Gateway attachment. Traffic that needs to cross from one VPC to another flows through the gateway.
This immediately solves the mathematical problem. Instead of N*(N-1)/2 connections, you need N+1: one connection per VPC to the gateway, plus the gateway itself. With twenty VPCs, you’re managing 21 attachments instead of 190 connections. The difference isn’t just numerical; it’s architectural simplicity.
Transit Gateway is also transitive. If VPC A attaches to TGW, and VPC B attaches to TGW, then A can reach B through the gateway. This makes sense: you’re routing through a central point, so of course transitivity applies. You can control which VPCs can reach which other VPCs using route tables and security groups—but you don’t need to create separate connections for each pair.
Routing Complexity and Control#
VPC Peering routing is straightforward at small scales. Each VPC maintains its own route tables. To allow VPC A to reach VPC B, you add a route in VPC A pointing to the peering connection, and vice versa. With two VPCs, this is trivial. With five VPCs needing full mesh connectivity, you’re managing route table entries across all of them.
Transit Gateway introduces centralized routing. The gateway has its own route table (or route tables, if you use multiple route domains). You define which attachments can reach which prefixes. This centralization is powerful: you can see your entire connectivity model in one place. Changing a routing policy doesn’t require touching multiple VPCs’ route tables—you modify the Transit Gateway’s routing, and the change propagates.
This centralization also enables more sophisticated routing. You can selectively allow certain traffic while blocking other traffic. You can implement different routing policies for different destinations. For example, you might route all production traffic through your Transit Gateway while allowing development VPCs to peer directly with each other.
Cross-Region and Hybrid Connectivity#
VPC Peering works within a region or across regions, but there are important limitations. Cross-region peering requires explicit setup. More importantly, if you later need to connect on-premises systems to your VPCs, you can’t easily route that traffic through peering connections. Each VPC that needs on-premises access must establish its own VPN connection or Direct Connect connection.
Transit Gateway shines here. You attach your VPN or Direct Connect connection to the Transit Gateway itself, not to individual VPCs. Now all VPCs that attach to that gateway can reach your on-premises network without individual connections. Better yet, you can enable peering between Transit Gateways across regions, allowing you to build a global network hub-and-spoke topology.
Imagine you have VPCs in us-east-1, us-west-2, and eu-west-1, and your data center connects via Direct Connect to us-east-1. With VPC Peering, each VPC in the other regions needs to route through the us-east-1 VPC (and you’d need to enable transit between them). With Transit Gateway, you simply peer the gateways across regions, and all attached VPCs can reach the data center and each other seamlessly.
Pricing: The Cost Calculus#
Here’s where your architectural choice directly impacts your bill.
VPC Peering charges only for data transfer: $0.01 per GB per direction (prices vary by region). If you’re not moving much data through peering, your costs are minimal. This makes VPC Peering ideal for occasional inter-VPC communication.
Transit Gateway has a different cost structure: you pay an hourly charge for each attachment (roughly $0.05/hour per attachment depending on region), plus a per-GB charge for traffic processing (roughly $0.02/GB in each direction). With ten VPCs, that’s $0.50/hour just for the attachments, or about $370/month—even with zero data transfer. Add in on-premises connectivity, and the hourly charges accumulate quickly.
However, Transit Gateway’s per-GB charges are often lower than peering once you account for the math at scale. If you’re running a full mesh of twenty VPCs with moderate traffic, the Transit Gateway’s per-GB charges on a single path through the gateway are often cheaper than maintaining 190 peering connections’ worth of per-GB charges.
The break-even point depends on your traffic patterns. If you have moderate data flow crossing VPC boundaries and you have more than a handful of VPCs, Transit Gateway is likely cheaper. If you have few VPCs with minimal cross-VPC communication, peering wins on cost.
Security and Compliance Considerations#
Security in multi-VPC environments requires thinking about isolation and control. VPC Peering’s non-transitive nature provides natural blast radius limitation. If VPC A is compromised, the attacker cannot leverage VPC B’s peering connections to reach VPC C unless they somehow gain control of VPC B itself.
Transit Gateway, being a central chokepoint, requires careful security design. All traffic flows through it, which means a misconfigured Transit Gateway route table or security group setting could affect all attached VPCs. This is actually a feature—centralized control means you can implement network policies consistently across all your VPCs. But it requires discipline.
Both options support security groups and network ACLs to control traffic at the instance or subnet level. The key difference is that Transit Gateway enables network policy as code, allowing you to define and audit your entire connectivity model centrally. For organizations with strict compliance requirements, this centralized auditability is often a significant advantage.
When to Choose VPC Peering#
VPC Peering makes sense when you have a small number of VPCs that need selective connectivity. If you have three or four VPCs and they don’t all need to talk to each other, the simplicity and cost of peering wins. You avoid the operational overhead and the hourly attachment costs.
Use peering when your VPCs have distinct security boundaries and you want to maintain that separation explicitly. Each peering connection can be treated as a distinct trust boundary, making authorization and auditing straightforward.
Peering is also appropriate for temporary connections. Need two teams’ VPCs to talk for a few months while a migration happens? Create a peering connection, remove it when you’re done. No ongoing charges beyond data transfer.
When to Choose Transit Gateway#
Transit Gateway becomes the clear choice as you scale. If you have more than five or six VPCs that need to communicate, the operational simplicity of a hub-and-spoke topology outweighs the additional costs. You’re managing fewer connections, clearer routing, and simpler troubleshooting.
Choose Transit Gateway if you need hybrid connectivity to on-premises networks. The ability to attach a single VPN or Direct Connect connection to the gateway and have all VPCs access it is powerful and cost-effective compared to individual VPC connections.
Transit Gateway is also the right choice for multi-region architectures. Peering across regions works, but managing it at scale is complex. Transit Gateway peering between regions provides clean, maintainable global connectivity.
Finally, consider Transit Gateway if you want to implement sophisticated network policies or require centralized security controls. The ability to define routing and access policies in one place, with full auditability, is valuable for enterprises and regulated industries.
Hybrid Approaches#
In practice, many sophisticated architectures use both. You might use Transit Gateway as your main hub for all inter-VPC and on-premises connectivity, but allow specific VPCs to establish direct peering connections for high-bandwidth, low-latency communication.
For example, imagine a primary VPC that hosts your Transit Gateway and serves as a hub, with secondary VPCs that attach to it for general connectivity. But you also have two specialized VPCs that move enormous amounts of data between them. You might add a direct peering connection between those two, bypassing the gateway entirely, to optimize for throughput and latency while keeping the general connectivity model centralized.
This hybrid approach requires careful planning to avoid confusion, but it can be optimal when different parts of your infrastructure have different requirements.
Practical Decision Framework#
When you’re designing multi-VPC architecture, start by asking these questions:
How many VPCs do you have now, and how many will you have in 12 months? If you’re at two or three and staying there, peering works fine. If you’re at ten or heading there, Transit Gateway is probably right.
Do you need to connect on-premises networks or use managed connectivity services? If yes, Transit Gateway is strongly preferred.
What are your data transfer patterns? If VPCs rarely talk to each other, peering is cheap. If they’re constantly communicating, Transit Gateway’s fixed costs amortize well.
How much operational complexity can you tolerate? Simple environments favor peering; complex, regulated environments favor Transit Gateway’s centralized control.
Do you need multi-region connectivity? Transit Gateway peering between regions is cleaner than managing cross-region peering connections.
Conclusion#
VPC Peering and Transit Gateway aren’t really competing solutions—they’re tools for different problems. VPC Peering excels at simplicity and cost for small-scale, selective connectivity. Transit Gateway is the foundation for scalable, manageable multi-VPC environments, especially those with hybrid or global requirements.
The mistake many teams make is choosing based on initial simplicity without considering their trajectory. If you’re starting with two VPCs using peering but planning to grow to fifteen VPCs, you’ll eventually face painful refactoring. Conversely, building Transit Gateway for a setup that only needs two VPCs is overengineering.
The best approach is to honestly assess your current and foreseeable networking requirements. If you’re uncertain, remember that migrating from peering to Transit Gateway is tedious but straightforward—you can start with peering and graduate to a gateway as your infrastructure grows. What you cannot easily do is go backward.