Transit Gateway

Connect three networks and you need three connections. Connect ten and you need forty-five. Connect a hundred and you need nearly five thousand.

This is the problem Transit Gateway solves. Not by being clever about connections, but by changing the question entirely.

The Combinatorial Trap

Without a Transit Gateway, connecting multiple VPCs requires mesh peering. Every VPC needs a direct connection to every other VPC it wants to reach.

The math is unforgiving. Connecting n networks requires n(n-1)/2 connections:

• 5 VPCs: 10 connections
• 10 VPCs: 45 connections
• 20 VPCs: 190 connections
• 50 VPCs: 1,225 connections

Every new connection in a mesh doesn't just add one relationship—it adds a relationship with everything that already exists. This is why network teams dread adding new VPCs. It's not the single connection that hurts. It's the cascade.

Hub-and-Spoke: A Different Question

Transit Gateway implements hub-and-spoke topology. Instead of asking "how do I connect this network to all the others," you ask "how do I connect this network to the hub."

Every VPC connects once to the Transit Gateway. The gateway handles routing between them. Adding a new VPC? One attachment. Whether you have 5 VPCs or 500, adding one more is the same amount of work.

The complexity becomes linear instead of quadratic. That's not an optimization—it's a fundamental change in how scaling works.

Transitive Routing

VPC peering is non-transitive. If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot reach VPC C. The relationship doesn't flow through.

Transit Gateway enables transitive routing. Attach VPCs A, B, and C to the same gateway, and they can all communicate. The gateway routes traffic between any attached networks without requiring direct connections between them.

This transitivity extends beyond VPCs. VPN connections from branch offices, Direct Connect links from data centers, Transit Gateways in other regions—they all become part of the same routing domain. A packet from your headquarters can reach a VPC through the gateway without the VPC knowing or caring where the packet originated.

Attachment Types

VPC attachments connect cloud networks to the gateway. Each VPC can have one attachment per Transit Gateway, placed in specific subnets that handle the routing.

VPN attachments create encrypted tunnels from remote sites. Branch offices, partner networks, home offices—anything that can establish an IPsec tunnel can attach.

Direct Connect attachments provide private, dedicated connectivity from on-premises data centers. No public Internet involved.

Peering attachments connect Transit Gateways across regions. Your us-east-1 gateway can peer with your eu-west-1 gateway, extending the routing domain globally.

Each attachment type brings different networks into the same routing domain. A packet entering through a VPN attachment can exit through a VPC attachment without special configuration.

Route Tables and Segmentation

Transit Gateways use route tables to control traffic flow. Each attachment associates with a route table that determines where its traffic can go.

This creates network segmentation without physical separation:

Environment isolation: Production VPCs associate with one route table, development VPCs with another. They share the same Transit Gateway but cannot reach each other.

Multi-tenant architectures: Each tenant gets a route table. Tenant A's traffic stays in Tenant A's routing domain. The infrastructure is shared; the routing is isolated.

Selective connectivity: A shared services VPC (logging, monitoring, authentication) can appear in multiple route tables, accessible from both production and development while those environments remain isolated from each other.

The power here is flexibility. You're not choosing between "everything can talk to everything" and "nothing can talk to anything." You're drawing precise boundaries.

The Performance Reality

Transit Gateway adds a hop. Traffic between two VPCs that could peer directly now routes through the gateway. This has implications:

Latency: Slightly higher than direct peering. For most applications, imperceptible. For latency-critical workloads, measurable.

Throughput: AWS caps VPC attachments at 50 Gbps (bursting to 100 Gbps). Direct peering has no such limit. If you're moving massive data volumes between two specific VPCs constantly, direct peering between those two might make sense alongside Transit Gateway for everything else.

Availability: Transit Gateway is a managed service with high availability built in. You're not managing gateway instances or worrying about failover. The tradeoff is you're trusting the cloud provider's infrastructure.

Cost Structure

Transit Gateway costs come in three forms:

Hourly charges for the gateway itself, running whether traffic flows or not.

Data processing fees per gigabyte through the gateway. This is often the largest cost for high-traffic architectures.

Attachment fees for each connected VPC, VPN, or Direct Connect.

For two VPCs that need to communicate, direct peering is cheaper. For twenty VPCs that all need to communicate, Transit Gateway is cheaper—not in raw data costs, but in operational overhead, reduced configuration errors, and faster changes.

The breakeven point depends on your architecture. Simple rule: if you're spending significant time managing peering connections, Transit Gateway probably pays for itself.

DNS Across the Gateway

Networks can route to each other through Transit Gateway, but DNS resolution requires separate configuration. A server in VPC A can reach an IP in VPC B, but resolving database.internal.vpc-b to that IP needs DNS infrastructure.

Route 53 Resolver endpoints (in AWS) or equivalent services bridge this gap. Inbound endpoints let on-premises DNS servers forward queries into your VPC DNS. Outbound endpoints let VPC resources resolve on-premises domains.

This is often the forgotten piece. The network works, but applications fail because they can't resolve names. Plan DNS alongside routing.

Observability

Transit Gateway provides metrics on bytes and packets per attachment, active connections, and packet drops. Flow logs capture traffic metadata—source, destination, ports, action taken.

Network Manager (AWS) or equivalent tools provide topology visualization. When something breaks, seeing the actual path traffic takes—or should take—is invaluable.

The operational value of centralized visibility often exceeds the routing benefits. One place to look, one set of logs, one topology to understand.

Migration Path

Moving from mesh peering to Transit Gateway follows a pattern:

1. Create the Transit Gateway and attach VPCs incrementally
2. Update route tables to prefer Transit Gateway routes
3. Verify connectivity through the gateway
4. Remove old peering connections

The transition can be gradual. Both paths can exist simultaneously during migration. But plan for brief connectivity disruptions as route tables update—routing changes aren't instantaneous.

The Fundamental Shift

Transit Gateway isn't just a different way to connect networks. It's a different mental model.

With mesh peering, you think about relationships between specific networks. "Does VPC A need to talk to VPC B?" You're managing edges in a graph that grows quadratically.

With Transit Gateway, you think about membership and policy. "Which routing domain does this VPC belong to? What can that domain reach?" You're managing nodes and tables that grow linearly.

The first model works fine at small scale. The second model is the only one that works at large scale. Knowing when to make the shift—before the combinatorial trap closes—is the real skill.