Transit gateway vs VPC peering

The short answer

A transit gateway is a regional router you attach VPCs and networks to. VPC peering is a private one to one link between two VPCs. The decision is less about features than about how many connections you will have, who owns them, and how much central control you need.

For two VPCs that need to talk, peering is usually the smallest, clearest option. For many VPCs across several accounts, a transit gateway removes the mesh of pair connections and gives you one place to set routing and inspection. Many teams start with peering and move to a transit gateway when route tables, not bandwidth, become the hard part.

How a transit gateway works

A transit gateway is a central hub. You create it in one region and attach VPCs, VPNs, Direct Connect gateways or other transit gateways to it. Each attachment can be associated with a transit gateway route table, and routes are propagated into that table. Traffic from one VPC follows the hub route table to another attachment, so the VPCs never need direct links.

The operational value comes from route table design. You can put production, development, and shared services in separate route tables to keep segments apart. You can send traffic through a security VPC for inspection, or add a blackhole route to drop traffic to a CIDR block. Accounts can share a transit gateway through AWS Resource Access Manager, so a central network account can own the hub while application teams own their VPCs.

There is a cost to that control. Traffic takes an extra hop. Attachments and data processing are billed separately from the VPCs, and the route tables need naming, documentation, and monitoring. The first design is rarely the last: expect to revise associations and propagations as accounts are added.

How VPC peering works

A VPC peering connection joins two VPCs and lets them route to each other using private IP addresses. One side requests, the other accepts, and both sides add a route in their route tables. Security groups and network ACLs still apply, so you open only the ports you need. The connection works across accounts and across regions when you set it up that way.

The important limit is that peering does not route transitively. If VPC A peers with B and B peers with C, A cannot reach C through B. Each pair needs its own peering connection and its own route entries. That is fine for a few pairs. It becomes a mesh as the number of VPCs grows, and a mesh is a set of links that every team must maintain.

Peering is simple to reason about because there is no hub. It also avoids an extra network hop. The risk is operational: a route that points to the wrong peering connection, a connection left open after a project ends, or two teams using overlapping CIDR blocks that cannot peer at all. Plan IP ranges before you create VPCs, not after.

When to choose a transit gateway

Choose a transit gateway when the number of VPCs and accounts makes pair connections hard to track. A shared services VPC for logging, DNS, or directory services is a common trigger. So is a central egress VPC for outbound traffic, or an inspection VPC that all spoke traffic must pass through. The hub gives you one routing policy instead of many pair policies.

A transit gateway also fits hybrid networks. You can attach a VPN or Direct Connect gateway once and let many VPCs use it, rather than building a VPN to each VPC. Segmentation is another reason: separate route tables let you keep production, partners, and sandbox traffic apart without separate physical links.

The trade-off is that you are building a network function that needs an owner. Someone must manage route tables, approve attachments, watch quotas, and review changes. If no team owns that work, the hub becomes a quiet source of outages.

When to choose VPC peering

Choose VPC peering when you have a small, stable set of VPCs and you want the least moving parts. Two VPCs in the same account, or a partner VPC that needs to reach one service, are good fits. Peering is also useful when you want to avoid a central hub for latency or failure domain reasons, or when the connection is temporary and easy to remove.

Peering works well when each team owns its own routes and the number of pairs stays low. It is a poor fit for a full mesh that keeps growing, for central inspection of all traffic, or for a network where many accounts need to reach many shared services. At that point the route tables become the source of truth, and they are spread across every VPC.

Watch for overlapping CIDR blocks, orphaned connections after a project ends, and route entries that are added by hand. Keep a simple register of peering connections, owners, and purposes. If you cannot list them on one page, you probably need a hub.

Costs and effort to consider

Both options have a cost model that follows the design, not just the number of VPCs. A transit gateway typically charges for attachments and for data processed, and you may pay for cross AZ or cross region traffic. VPC peering typically charges for data transfer, with different rates for same region, cross region, and cross AZ traffic. Compare the full path, including NAT gateways, VPNs, and inspection appliances, because the cheapest link can still sit behind an expensive path.

Effort matters more than the bill. A transit gateway needs IP address planning, route table design, account sharing, change control, and monitoring. VPC peering needs a connection register, route reviews, and a habit of cleaning up after projects. Both need clear ownership. A network account with no mandate is worse than a simple peering pair with a named owner.

Start with a diagram of every VPC, account, CIDR block, and traffic flow. Count the pairs. If the count is small and stable, peer them. If it grows with every new account, build the hub and staff it. If you want a second opinion before you commit, the Cloudverg Expert architecture session at $450 one time is one option: a 90 minute call with a senior architect, a pre read of your diagrams, and a written summary.

Frequently asked questions