Business Challenge
A financial services company lands on AWS with five accounts: management, security, shared-services, prod, and dev. VPC peering works. Six months later they have 30 accounts — one per business unit, per environment, per compliance boundary. The network team is maintaining 435 peering connections manually, on-premises connectivity is wired into every account individually, and the security team has no central point to inspect east-west traffic between workloads.
The mathematical reality of VPC peering: n accounts need n×(n−1)÷2 peering connections. At 10 accounts that is 45. At 50 accounts it is 1,225. Worse — peering is non-transitive. VPC A peered with VPC B and VPC B peered with VPC C does not mean A can reach C. Every pair that needs to communicate needs its own connection.
The result is a topology that is expensive to reason about, impossible to audit, and impossible to add centralized inspection to after the fact.
Without a central transit layer, every compliance requirement that touches network traffic — logging egress, inspecting east-west, blocking lateral movement — must be implemented per-account. That multiplies audit scope and operational overhead by the number of accounts.
Architecture
The hub-and-spoke model places AWS Transit Gateway (TGW) in a dedicated networking account that no workloads run in. Every spoke VPC — prod, dev, shared-services, on-premises — attaches to the TGW. The TGW becomes the single routing fabric.
Account layout
Networking account (hub)
Owns the Transit Gateway. Hosts the centralized egress VPC (NAT Gateways, internet gateway). Optionally hosts an inspection VPC with AWS Network Firewall for east-west and north-south traffic control. No workloads run here.
Workload accounts (spokes)
Each account has one or more VPCs attached to the TGW via TGW attachments, shared through AWS Resource Access Manager (RAM). Workload VPCs have no internet gateway. All egress flows through the hub.
Security account
Attached as a spoke but with read access to TGW flow logs, VPC flow logs from all accounts, and Network Firewall alert logs — the vantage point for threat detection without being in the data path.
On-premises
Connected once — to the TGW via Direct Connect Gateway or Site-to-Site VPN. No per-account VPN tunnels. On-prem routes propagate into TGW route tables and are selectively shared to spoke VPCs.
TGW route table segmentation
Transit Gateway route tables are the enforcement boundary. A single TGW can have multiple route tables, and each attachment (VPC or VPN) is associated with exactly one route table and can propagate routes into one or more route tables. This lets you express network policy as routing policy:
Prod route table
Prod VPCs associate here. Routes: shared-services VPC (DNS, Active Directory, patch servers), on-premises (via DXGW propagation), egress VPC (default route 0.0.0.0/0). No routes to dev or staging — prod cannot reach non-prod.
Non-prod route table
Dev and staging VPCs associate here. Routes: shared-services, egress VPC. No on-premises routes by default — dev traffic does not traverse Direct Connect. Spoke-to-spoke within non-prod is permitted if the team explicitly adds routes.
Inspection route table
Used when an inspection VPC (Network Firewall) is in the path. East-west traffic routes: spoke → TGW → inspection VPC → TGW → destination spoke. The TGW route table hairpins traffic through the firewall before forwarding.
Centralized egress VPC
The egress VPC is the only VPC with an internet gateway. It contains NAT Gateways in each AZ. Spoke VPCs have a default route (0.0.0.0/0) pointing at the TGW; the TGW's egress-bound route table sends that traffic to the egress VPC's NAT Gateways. The outbound IP space is a small, auditable set of Elastic IPs you can add to allowlists at partners and SaaS vendors.
A fixed, known outbound IP address space across all accounts. Partners and SaaS vendors who require IP allowlisting get a handful of EIPs rather than a /16 per account.
Why This Architecture Works
Transitivity
The fundamental problem with VPC peering — non-transitivity — disappears. VPC A attached to TGW can reach VPC B attached to TGW as long as the route tables allow it. Adding a new account means one TGW attachment and one RAM share, not n new peering connections.
Single pane of glass for routing policy
The entire enterprise's routing policy lives in TGW route tables rather than being distributed across hundreds of VPC route tables and peering connection route propagations. A security team can audit "what can reach prod" by reading two TGW route tables.
On-premises connectivity once
Direct Connect Gateway attaches to the TGW once. Route propagation from on-prem pushes those prefixes into whichever TGW route tables you choose. Adding a new account to on-prem connectivity is a route table change, not a new VPN tunnel or BGP session.
Well-Architected alignment
Security: Network Firewall in the inspection VPC gives you centralized stateful inspection,
IDS/IPS rules, and domain-based egress filtering without deploying security appliances per account.
Operational Excellence: RAM-shared TGW means the networking team owns the transit layer;
workload teams attach VPCs without needing networking account access.
Reliability: TGW is a fully managed, multi-AZ regional service with 99.99% SLA. No BGP
sessions to babysit.
Key Design Decisions
Cloud WAN is the newer global network service that wraps TGW under a policy-based control plane and handles multi-region automatically. Choose TGW if you are single-region or already have a TGW-based network. Choose Cloud WAN for new greenfield multi-region networks or if your team wants a declarative network policy model. The two can coexist via TGW peering as a migration path.
Decision signalIf you have more than 3 AWS regions with spoke VPCs, Cloud WAN's global segments become materially simpler than managing inter-region TGW peering manually.
Centralized egress (one NAT Gateway per AZ in the networking account) eliminates per-account NAT Gateway costs and gives you a single IP address space. But every byte of internet-bound traffic crosses the TGW ($0.02/GB) and the centralized NAT Gateway ($0.045/GB). For workloads with high egress bandwidth, the math can favor distributed NAT Gateways per account, especially if those workloads are downloading large datasets from public S3 endpoints where VPC endpoints would eliminate the charge entirely.
Rule of thumbRun centralized egress for control plane traffic. Place S3 Gateway endpoints in every spoke VPC to keep S3 traffic off the TGW entirely — those are free and remove the single largest source of unexpected data transfer cost.
Routing east-west traffic through a Network Firewall inspection VPC adds latency (~1–2 ms per hop) and a processing cost ($0.065/GB for Network Firewall). For most enterprise workloads the latency is negligible. The real question is whether you need stateful east-west inspection at all — or whether TGW route table segmentation (prod cannot route to dev) is sufficient. Start with route table segmentation, add Network Firewall in the inspection VPC only for workloads with regulatory requirements for deep packet inspection or IDS/IPS.
Each VPC needs its own TGW attachment (not each account). An account with 3 VPCs has 3 attachments. Plan your account/VPC structure before assuming one attachment per account — accounts with multiple environment VPCs (dev + staging in the same account) pay per VPC, not per account. TGW also supports peering attachments for inter-region connectivity, counted separately.
Tradeoffs and Alternatives
| Approach | Works well when | Breaks down when |
|---|---|---|
| TGW hub-and-spoke | Single region, 5–200 accounts, need centralized egress or inspection | Multi-region at scale (TGW peering adds complexity); very high egress volumes where per-GB cost dominates |
| VPC peering | 2–5 VPCs, no transitive routing needed, lowest cost | >10 VPCs; any need for transitive routing; adding on-premises connectivity |
| AWS Cloud WAN | New multi-region network, want policy-as-code for network segmentation | Existing TGW investment; small single-region footprint where Cloud WAN's overhead isn't justified |
| AWS PrivateLink | Exposing a specific service from one account to others without full network connectivity | Workloads that need general-purpose connectivity, not service-specific access |
Closing Thought
The Transit Gateway hub-and-spoke pattern is not about Transit Gateway — it is about accepting that network topology is a policy document. Every route table entry is a statement about what can reach what. When that policy is scattered across hundreds of VPC route tables and peering connections, no one can audit it, and every compliance review becomes a detective exercise.
Centralizing the routing fabric does not mean centralizing the network team's bottleneck. With RAM sharing and TGW route tables, workload teams can request VPC attachment and get connectivity without touching the networking account. The networking team sets the policy once; workloads attach into it.
Start with TGW route table segmentation before you invest in Network Firewall. Routing policy alone — prod cannot reach non-prod, dev cannot reach on-premises — eliminates the most common lateral movement paths without adding inspection overhead. Add stateful inspection incrementally for the workloads that actually need it.
Identity & Access — how IAM Identity Center permission sets and attribute-based access control (ABAC) replace per-account IAM users across a 50-account organisation, and why the session tag model matters for auditability.
Official AWS Reference
AWS Documentation — Transit Gateway design best practices — covers route table segmentation, centralized egress patterns, on-premises connectivity, and the recommended account structure for a hub-and-spoke topology.
Comments