Definition
- Transit Gateway – a regional network transit hub that connects many VPCs and on-premises networks through a single, centrally-managed gateway with transitive routing.
- VPC peering – a point-to-point, non-transitive connection between two VPCs; traffic cannot flow through an intermediate VPC, so full mesh requires N-squared connections.
- Attachment – a VPC, VPN, or Direct Connect connects to the Transit Gateway once via an attachment.
- Transit Gateway route table – controls which attachments can see which routes, enabling isolation between environments.
- Inter-region peering – connects Transit Gateways in different Regions for a global network.
Imagine National Bank of India has twenty buildings that all need to reach each other. Peering is like building a private bridge between every pair -- with twenty buildings that is around a hundred and ninety bridges, impossible to manage. A Transit Gateway is a central metro station: each building builds just one connection to the station, and the station routes people between any two buildings. Add a new building, and it only needs one connection to the station, not a bridge to every other building.
Understanding the Concepts
What is the problem with VPC peering at scale?
VPC peering is point-to-point and non-transitive. To fully connect N VPCs you need N times (N minus 1) divided by 2 peering connections, and traffic cannot flow through an intermediate VPC. For three or four VPCs that is fine; for twenty it is a nightmare of connections and route tables, and it cannot include on-premises networks cleanly.
// Calculating peering connections for N VPCs
package com.bank.infrastructure;
public class PeeringScaleCalculator {
public static int requiredPeerings(int vpcCount) {
return vpcCount * (vpcCount - 1) / 2;
}
public static void main(String[] args) {
System.out.println("3 VPCs: " + requiredPeerings(3) + " peerings");
System.out.println("10 VPCs: " + requiredPeerings(10) + " peerings");
System.out.println("20 VPCs: " + requiredPeerings(20) + " peerings");
}
}
3 VPCs: 3 peerings
10 VPCs: 45 peerings
20 VPCs: 190 peerings
What is a Transit Gateway?
A Transit Gateway is a regional hub. Each VPC creates one attachment to the Transit Gateway, and on-premises networks attach through a VPN or Direct Connect. The Transit Gateway then routes between all of them transitively -- VPC A can reach VPC C through the gateway even though they are not directly peered. Adding a new VPC means one new attachment and a route update, not a new connection to every existing VPC.
// Transit Gateway as a central hub
package com.bank.infrastructure;
import java.util.List;
public class TransitGatewayHub {
private final String tgwId = "tgw-0hub";
private final List<String> attachments = List.of(
"attach-prod (10.1.0.0/16)",
"attach-staging (10.2.0.0/16)",
"attach-shared (10.3.0.0/16)",
"attach-onprem (172.16.0.0/16 via VPN)"
);
public void printTopology() {
System.out.println("Transit Gateway: " + tgwId);
attachments.forEach(a -> System.out.println(" Attachment: " + a));
System.out.println(" All can reach each other transitively through the hub.");
}
}
How do Transit Gateway route tables work?
The Transit Gateway has its own route tables, which is what makes it powerful. You associate attachments with a route table and propagate routes into it. This controls which attachments can see which routes, enabling isolation between environments. Production can see shared-services but not staging, while staging can see shared-services but not production.
# Transit Gateway route tables
RT-prod (associated with: attach-prod)
10.3.0.0/16 -> attach-shared (propagated)
172.16.0.0/16 -> attach-onprem (propagated)
# No route to staging -> production cannot reach staging
RT-staging (associated with: attach-staging)
10.3.0.0/16 -> attach-shared (propagated)
# No route to prod or on-prem -> staging is isolated
// Route table isolation concept
package com.bank.infrastructure;
import java.util.Map;
public class TgwRouteTableIsolation {
public static Map<String, Boolean> canReach(String source) {
return switch (source) {
case "prod" -> Map.of("shared", true, "staging", false, "onprem", true);
case "staging" -> Map.of("shared", true, "prod", false, "onprem", false);
default -> Map.of();
};
}
}
How do you add a new VPC?
With peering, adding a new VPC to a mesh of twenty requires twenty new peering connections and forty route table updates. With a Transit Gateway, you create one attachment and propagate the new route. The existing route tables either include it or not based on the association, and nothing else changes.
// Adding a new VPC to the Transit Gateway
package com.bank.infrastructure;
public class AddVpcToTgw {
public static void main(String[] args) {
System.out.println("Adding new analytics VPC to Transit Gateway:");
System.out.println(" 1. Create TGW attachment for analytics VPC");
System.out.println(" 2. Associate with RT-staging (or a new route table)");
System.out.println(" 3. Propagate analytics CIDR into relevant route tables");
System.out.println(" Done. No changes to any existing VPC's peering.");
}
}
How does on-premises connectivity work?
On-premises networks attach to the Transit Gateway through a VPN connection or a Direct Connect gateway. Once attached, the on-prem routes propagate into the Transit Gateway route tables just like VPC routes, and VPCs can reach on-prem and vice versa through the same hub. This replaces the old model of having each VPC maintain its own VPN to the data center.
// On-prem connectivity through Transit Gateway
package com.bank.infrastructure;
public class OnPremConnectivity {
public static void main(String[] args) {
System.out.println("On-premises (172.16.0.0/16) connects via VPN to TGW.");
System.out.println("TGW route table propagates 172.16.0.0/16.");
System.out.println("Any VPC associated with that route table can reach on-prem.");
System.out.println("On-prem route table has return routes to VPC CIDRs via VPN.");
}
}
How does inter-region peering work?
Transit Gateways are regional, but you can peer them across Regions. A Transit Gateway in ap-south-1 (Mumbai) peers with one in eu-west-1 (Dublin), and routes can propagate between them, giving a global bank network where VPCs in Mumbai can reach VPCs in Dublin through two connected hubs.
// Inter-region Transit Gateway peering
package com.bank.infrastructure;
public class InterRegionPeering {
public static void main(String[] args) {
System.out.println("TGW in ap-south-1 (Mumbai) peers with TGW in eu-west-1 (Dublin)");
System.out.println("Mumbai VPCs -> Mumbai TGW -> Peering -> Dublin TGW -> Dublin VPCs");
System.out.println("Global bank network with centralized routing in each region.");
}
}
When should you use peering instead of Transit Gateway?
Transit Gateway has a per-attachment and per-gigabyte cost, so for just two or three VPCs that will never grow, plain peering is cheaper and has slightly lower latency because there is no hub hop. The hub-and-spoke pays off at scale and when you need on-premises connectivity and centralized control.
// Decision: peering vs Transit Gateway
package com.bank.infrastructure;
public class PeeringVsTgwDecision {
public static String recommend(int vpcCount, boolean needsOnPrem) {
if (vpcCount <= 3 && !needsOnPrem) {
return "VPC Peering (cheaper, lower latency for small networks)";
}
return "Transit Gateway (scalable, centralized, transitive routing)";
}
}
What should a senior engineer know?
The Transit Gateway is regional and scales to thousands of attachments. Routing through the hub adds a small latency hop compared to direct peering, which for most banking workloads is negligible. When multiple accounts are involved, attachments can come from different accounts via AWS Resource Access Manager (RAM). The most common operational issue is a missing route in a Transit Gateway route table, which is discussed in the troubleshooting question.
Visual Overview
VPC Peering (Full Mesh) Transit Gateway (Hub-and-Spoke)
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│Prod │───│Stag │───│Share│ │Prod │ │Stag │ │Share│
│ │ │ │ │ │ │ │ │ │ │ │
└──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘
│ │ │ │ │ │
└─────────┘ │ │ one attachment each
│ │ │ │ │
└───────────────────┘ ▼ ▼ ▼
┌─────────────────────────┐
N VPCs = N(N-1)/2 peerings │ Transit Gateway │
Non-transitive │ (central hub) │
No on-prem integration │ │
│ Transitive routing │
│ Route table isolation │
└────────────┬────────────┘
│
▼
┌──────────────┐
│ On-Premises │
│ (VPN / DX) │
└──────────────┘
Key Takeaway
AWS Transit Gateway is a regional network transit hub that connects many VPCs and on-premises networks through one centrally-managed gateway. Each VPC attaches once, on-premises networks attach through a VPN or Direct Connect, and the gateway provides transitive routing between every attachment. That transitivity is the key difference from peering, because VPC peering is point-to-point and non-transitive, so traffic cannot flow through an intermediate VPC.
The problem it solves is scale. To fully connect N VPCs with peering you need roughly N-squared-over-two connections -- for twenty VPCs that is around a hundred and ninety peerings, each with routes on both sides. A Transit Gateway turns that into a hub-and-spoke: each network has a single attachment, and the hub routes between all of them. Adding a new VPC means one attachment, not twenty new connections.
What makes Transit Gateway especially powerful is that it has its own route tables. By associating attachments with specific route tables and controlling which routes propagate, I can isolate environments so production cannot reach staging through the hub. It is regional, scales to thousands of attachments, and peers with Transit Gateways in other Regions for a global bank network.
At National Bank of India we moved from a tangle of peerings to a Transit Gateway once we had production, staging, shared-services, and the on-premises data center all needing to communicate. Each attaches once, and the on-prem connection comes in via VPN to the same hub. The senior point is that this is a scale and control decision: for two or three VPCs that will never grow, plain peering is cheaper and lower-latency because the hub adds one routing hop.
Remember one sentence: Transit Gateway is a central hub that replaces the unscalable N-squared mesh of VPC peerings with a single attachment per network and transitive, centrally-managed routing.
---