How to Centralize Routing Across Hundreds of AWS Accounts Using Transit Gateway #
Exam Context: AWS SAP-C02
Scenario Category: Networking
Decision Focus: Centralizing multi-account routing with Transit Gateway while enforcing isolation and minimizing operational overhead
While preparing for the AWS SAP-C02, many candidates get confused by multi-account VPC connectivity patterns. In the real world, this is fundamentally a decision about centralized routing control vs. operational overhead at scale. Let’s drill into a simulated scenario.
The Scenario #
GlobalRetail Inc., a Fortune 500 e-commerce platform, operates a hybrid infrastructure model. They run critical legacy ERP systems on-premises in their Atlanta data center, while their microservices platform spans 427 VPCs distributed across 34 AWS accounts within an AWS Organizations structure. Each business unit owns multiple AWS accounts for environment isolation (dev, staging, prod).
The network team has established a Site-to-Site VPN connection from their on-premises router to a single AWS account (the “Network Hub” account). However, they’re facing two critical challenges:
- Selective Connectivity: Not all VPCs should communicate freely—PCI-compliant payment VPCs must remain isolated from dev environments
- Operational Chaos: Managing hundreds of individual VPN connections or VPC peering relationships is unsustainable
The CTO has mandated a solution that provides centralized routing governance with minimal ongoing operational burden.
Key Requirements #
Design a network architecture that:
- Connects the on-premises network to AWS
- Enables selective VPC-to-VPC communication across accounts
- Minimizes operational overhead for a 5-person network team
- Maintains compliance boundaries
The Options #
Select THREE:
- A) Create a Transit Gateway in the Network Hub account; share it across accounts using AWS Resource Access Manager (AWS RAM)
- B) Configure attachments to all VPCs and the VPN connection
- C) Set up Transit Gateway route tables; associate VPCs and VPN with specific route tables based on isolation requirements
- D) Configure VPC peering connections between all VPCs
- E) Configure attachments between VPCs and the VPN connection only (not all VPCs)
- F) Set up route tables on individual VPCs and VPN endpoints
Correct Answer #
Options A, B, and C form the complete Transit Gateway hub-and-spoke architecture.
Step-by-Step Winning Logic #
This solution delivers centralized routing governance at scale through three architectural pillars:
-
Cross-Account Resource Sharing (A): AWS RAM eliminates the need to recreate Transit Gateways in each account. A single TGW in the Network Hub account can be attached to VPCs in any member account, reducing management overhead by 97% compared to per-account deployment.
-
Universal Connectivity Plane (B): Attaching ALL VPCs and the VPN to the TGW creates a single pane of glass for network visibility. This is critical for security audits and troubleshooting—the network team can trace all traffic flows from one console.
-
Policy-Based Segmentation (C): Multiple route tables on the TGW (e.g., “Production”, “Dev”, “PCI-DMZ”) enable zero-trust network segmentation. A VPC’s attachment to a specific route table determines its reachability—no need for 427 separate security group configurations.
Why this scales: Adding VPC #428 requires:
- 1 RAM share acceptance (if new account)
- 1 TGW attachment creation
- 1 route table association
Total time: ~5 minutes. Compare this to VPC peering, which would require 427 new peering connections.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
-
Why not D (VPC Peering)?
- Operational Death Spiral: Full-mesh peering for 427 VPCs = 91,026 connections. AWS limits you to 125 peering connections per VPC, making this physically impossible.
- No Transitive Routing: VPC-A ↔ VPC-B and VPC-B ↔ On-Prem does NOT mean VPC-A can reach on-prem. You’d need direct connections from ALL VPCs to the VPN VPC.
- Compliance Nightmare: No centralized policy enforcement—each peering is an independent allow/deny decision.
-
Why not E (Selective Attachments)?
- Breaks the Hub Model: Only attaching some VPCs defeats the purpose of centralized routing. You’d still need peering or additional VPNs for unattached VPCs.
- False Economy: You save ~$36/month per unattached VPC but inherit exponential complexity costs.
-
Why not F (Individual VPC Route Tables)?
- Distributed State Problem: With 427 VPCs, route table updates become a distributed systems challenge. A single on-prem CIDR change requires 427 route table updates.
- Incomplete Solution: VPC route tables don’t provide VPC-to-VPC isolation controls—you still need something like Transit Gateway or peering.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TB
OnPrem[On-Premises Data Center
10.0.0.0/8]
VPN[Site-to-Site VPN
Network Hub Account]
TGW[Transit Gateway
Shared via RAM]
RT_Prod[TGW Route Table: Production
Isolated]
RT_Dev[TGW Route Table: Dev/Test
Open]
RT_PCI[TGW Route Table: PCI-DMZ
Strict ACLs]
VPC_Prod1[VPC: Prod-Payments
Account A]
VPC_Prod2[VPC: Prod-Inventory
Account B]
VPC_Dev1[VPC: Dev-Testing
Account C]
VPC_PCI[VPC: PCI-Cardholder
Account D]
OnPrem -->|VPN Attachment| VPN
VPN -->|Attachment| TGW
TGW --> RT_Prod
TGW --> RT_Dev
TGW --> RT_PCI
RT_Prod -->|Association| VPC_Prod1
RT_Prod -->|Association| VPC_Prod2
RT_Dev -->|Association| VPC_Dev1
RT_PCI -->|Association| VPC_PCI
RT_Prod -.->|Routes to| OnPrem
RT_PCI -.->|Routes to| OnPrem
RT_Dev -.->|No Route| VPC_PCI
style TGW fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#FFF
style RT_PCI fill:#D13212,stroke:#232F3E,stroke-width:2px,color:#FFF
style VPC_PCI fill:#D13212,stroke:#232F3E,stroke-width:2px,color:#FFF
Diagram Note: The Transit Gateway acts as a regional network hub with route tables enforcing segmentation—PCI VPCs cannot communicate with Dev environments despite sharing the same TGW infrastructure.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost (427 VPCs) | Pros | Cons |
|---|---|---|---|---|
| A+B+C (Transit Gateway) | Medium (Initial setup: 2-3 days, ongoing: 10 min/new VPC) | $1,850 base ($0.05/hr × 428 attachments) + $0.02/GB data transfer ( |
✅ Centralized routing policy ✅ Scales to 5,000 attachments ✅ Transitive routing ✅ Multi-region peering ready ✅ CloudWatch flow logs |
❌ Data processing fees ❌ 50 Gbps per-VPC bandwidth limit ❌ Learning curve for route table design |
| D (Full Mesh VPC Peering) | Impossible (Exceeds AWS limits) | $0 (no per-connection fees) + $0.01/GB intra-region transfer = ~$1,600/mo (if it worked) | ✅ Lowest data transfer cost ✅ No processing fees ✅ Simple for small deployments |
❌ 91,000+ connections required ❌ 125 peering limit per VPC ❌ No transitive routing ❌ No centralized policy |
| D+F (Partial Peering + Manual Routing) | Very High (100+ hours/month maintenance) | ~$2,400/mo (labor cost for 60 hrs @ $40/hr) + transfer fees | ✅ Granular control | ❌ Human error prone ❌ Audit failures ❌ Doesn’t scale ❌ No on-prem connectivity solution |
| Multiple VPNs | High (1 VPN per VPC = 427 VPNs) | ~$30,780/mo ($0.05/hr × 2 tunnels × 427 VPCs) + $0.09/GB VPN transfer | ✅ Direct on-prem access per VPC | ❌ 512x cost vs TGW ❌ On-prem router limitations ❌ No VPC-to-VPC routing |
FinOps Verdict: Transit Gateway costs 3.2x more than theoretical full-mesh peering for data transfer, but delivers 97% operational cost reduction. At 427 VPCs, the break-even point is ~15 network engineer hours saved per month—easily achieved given peering’s impossibility at this scale.
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
For the SAP-C02 exam, when you see:
- “Hundreds of VPCs” + “Across accounts” → Transit Gateway
- “Least operational overhead” + “Centralized control” → Transit Gateway Route Tables
- “Share across accounts” → AWS RAM
Always select the TGW + RAM + Route Table trifecta for multi-account scenarios.
Real World #
In production, I’ve implemented this pattern for clients, but with critical additions:
-
Hybrid DNS Strategy: The exam doesn’t mention it, but you’d deploy Route 53 Resolver endpoints in the TGW hub account for centralized DNS resolution between on-prem and AWS.
-
Cost Optimization Tweaks:
- Use VPC Peering for high-bandwidth pairs (e.g., if two VPCs exchange 50TB/month, peering saves $800/mo vs TGW processing fees)
- Enable TGW Flow Logs only on production route tables (dev environments don’t need the extra $0.50/GB logging cost)
-
The “Goldilocks” Route Table Strategy: Don’t create 427 route tables (one per VPC). Group VPCs into 8-12 logical zones (Production-Web, Production-Data, Dev, PCI, etc.). More than 20 route tables becomes operationally burdensome.
-
Site-to-Site VPN is a Trap: For production workloads, I’d recommend:
- AWS Direct Connect (1 Gbps dedicated) for $0.03/GB vs VPN’s $0.09/GB
- Or AWS Cloud WAN if multi-region (includes TGW and global network management)
-
The Hidden Cost: Transit Gateway Network Manager ($1/month per device + $0.30/GB telemetry) adds visibility but isn’t mentioned in the exam—real budgets must account for observability.