Building blocks
Design goal
Replace a growing mesh of point-to-point connections with a scalable routing hub that still preserves intentional reachability and security boundaries.
Success criteria
- Centralize transitive routing
- Segment environments with route tables
- Support multiple hybrid connections
- Create a clear path for inspection
Architecture
Attach VPCs and hybrid connections to Transit Gateway, then use separate route tables and optional inspection VPCs to control reachability.
Architecture flow
- On-premises sites connect through VPN or Direct Connect
- Transit Gateway provides the routing hub
- Route tables segment attachments
- Inspection services can sit on approved traffic paths
- Spoke VPCs host application workloads
Architecture decisions
Route tables define segmentation
WhyTreat Transit Gateway route tables as security/segmentation architecture, not only connectivity configuration.
Trade-offRoute-table segmentation is scalable and explicit, but poor propagation design can create hard-to-diagnose reachability or unintended transitive access.
Avoid unnecessary east-west transit
WhyOnly propagate or statically route prefixes required for application flows; broad any-to-any routing increases blast radius.
Trade-offRestricting routes reduces blast radius, but requires teams to document legitimate application dependencies before connectivity is enabled.
Networking
Make the traffic path explicit. Plan non-overlapping CIDRs, BGP/static routing, attachment associations/propagation, inspection symmetry, DNS, and failure behavior.
Security
Protect the control and data paths deliberately. Combine routing segmentation with workload security groups, network ACLs where useful, centralized inspection, and logging.
Availability
Design for the failure domain that must be survived. Design redundant hybrid connectivity and customer-premises devices where the on-premises side requires high availability.
Disaster recovery
Treat regional recovery as a separate operating state. Recovery-region network attachments, route tables, DNS, and hybrid paths should be preplanned where regional recovery is required.
Cost drivers
- Transit Gateway attachments
- Data processing through TGW
- VPN or Direct Connect
- Inspection appliances/services
- Inter-region data transfer if used
Design assumptions
- CIDR space can be centrally governed
- Route ownership and hybrid routing policy are documented
Implementation plan
- Define the CIDR plan, connectivity domains, and which networks are allowed to communicate before creating Transit Gateway routes.
- Create separate Transit Gateway route tables for segmentation domains rather than relying on one shared any-to-any routing table.
- Attach VPCs through dedicated attachment subnets and associate/propagate routes only to the tables that match the intended reachability.
- Attach Site-to-Site VPN or Direct Connect paths and define route preference and failure behavior for hybrid prefixes.
- Insert inspection only where required, account for symmetric routing, and validate reachability and failover from each routing domain.
Validate the design
- Verify each routing domain can reach only the prefixes explicitly intended for it.
- Fail a VPN tunnel or preferred hybrid path and confirm traffic uses the documented alternate route.
- Test inspected flows in both directions and confirm symmetric routing through the inspection path.
- Resolve representative private names across the hybrid boundary and confirm DNS follows the intended resolver path.