Hybrid and global networks fail in expensive, hard-to-debug ways: an overlapping CIDR discovered the day two companies merge, a Direct Connect cut with no backup, a flat Transit Gateway that lets a compromised dev VPC reach production, a cross-region link that shows available but routes nothing.
Walk this list before you ship code that touches Direct Connect, Transit Gateway, or Site-to-Site VPN, and use it as a review checklist afterward. Each item is a rule with a one-line rationale.
Plan one non-overlapping CIDR scheme across all regions and accounts. Transit Gateway and Direct Connect cannot route between overlapping ranges, and re-addressing a live network is brutal. Allocate distinct blocks per region and environment before you need them.
Reserve room per region. Carve a large aggregate (for example a /8 split into per-region /12s) so a region can grow and its prefixes still summarize cleanly in BGP.
Document which CIDR lives where. Cross-region peering needs static routes; a maintained map of prefix-to-region is what your automation scripts those routes from.
Keep on-premises prefixes distinct from every VPC CIDR. Overlap between the data center and a VPC breaks hybrid routing exactly like VPC-to-VPC overlap does.
Never depend on a single Direct Connect connection. One link is a single point of failure. Add a second connection, ideally at a different Direct Connect location, for site-level resilience.
Back every Direct Connect link with a dynamic VPN. A Site-to-Site VPN on the same Transit Gateway is cheap insurance that fails over automatically when DX drops.
Bring up both VPN tunnels. AWS provisions two tunnels per VPN connection; configure both on your router so the backup is itself redundant.
Do not treat a LAG as site redundancy. A link aggregation group bundles links at one location - a facility outage takes them all. Real redundancy needs a second location.
Attach the VPN backup to the same hub as Direct Connect so both advertise the same prefixes.
Use BGP (dynamic) routing everywhere you can. Dynamic routes withdraw on failure, which is what makes Direct Connect-to-VPN failover automatic. Static routes do not.
Remember cross-region peering does not propagate. Every route across a Transit Gateway peering attachment is static - add them explicitly on both regions' route tables.
Route both sides of every link. DX-plus-VPN, cross-region peering, and cross-account attachments all need routes on both ends, or replies black-hole.
Do not forget the VPC-side routes. The Transit Gateway route table is only half the path; each VPC subnet route table still needs a route to the remote CIDR via the attachment.
Let Direct Connect win by default. When DX and VPN advertise the same prefixes, the hub prefers DX. Do not add static overrides that defeat that automatic preference.
Verify a cross-region route actually landed rather than trusting available status.
# --- Python (boto3) ---resp = ec2.search_transit_gateway_routes( TransitGatewayRouteTableId="tgw-rtb-east", Filters=[{"Name": "route-search.subnet-of-match", "Values": ["10.20.0.0/16"]}],)for r in resp["Routes"]: print(r["DestinationCidrBlock"], r["State"], r["Type"])
Disable default association and propagation on the Transit Gateway. Turn them off so attachments reach nothing until you explicitly wire them - segmentation by default, not by exception.
Use dedicated route tables per environment. Separate prod, dev, and shared-services tables so you control reachability by what you propagate, not by deny rules.
Keep environments from reaching each other. Never propagate dev's routes into prod's table or vice versa; let both reach shared services only.
Steer egress through inspection with a static default route. Point 0.0.0.0/0 at a firewall/inspection VPC attachment when you need centralized traffic inspection.
Restrict which prefixes on-premises may advertise. Set allowedPrefixesToDirectConnectGateway on the Direct Connect gateway association so on-prem cannot inject arbitrary routes.
Build segmentation by leaving propagation out, not by adding blocks.
# --- Python (boto3) ---# prod reaches shared services, but dev's routes are never propagated into prodec2.associate_transit_gateway_route_table( TransitGatewayRouteTableId="tgw-rtb-prod", TransitGatewayAttachmentId="tgw-attach-prod")ec2.enable_transit_gateway_route_table_propagation( TransitGatewayRouteTableId="tgw-rtb-prod", TransitGatewayAttachmentId="tgw-attach-shared")
// --- TypeScript (AWS SDK v3) ---import { AssociateTransitGatewayRouteTableCommand, EnableTransitGatewayRouteTablePropagationCommand,} from "@aws-sdk/client-ec2";// prod reaches shared services, but dev's routes are never propagated into prodawait ec2.send(new AssociateTransitGatewayRouteTableCommand({ TransitGatewayRouteTableId: "tgw-rtb-prod", TransitGatewayAttachmentId: "tgw-attach-prod",}));await ec2.send(new EnableTransitGatewayRouteTablePropagationCommand({ TransitGatewayRouteTableId: "tgw-rtb-prod", TransitGatewayAttachmentId: "tgw-attach-shared",}));
Watch Transit Gateway per-attachment and per-GB charges. Every attachment bills hourly and every gigabyte processed bills too; a chatty cross-account mesh adds up fast.
Mind cross-region and cross-AZ data transfer. Peering traffic between regions is billed per GB on both sides; keep chatty workloads region-local where you can.
Alarm on link and tunnel state, do not just poll. Use CloudWatch metrics like Direct Connect ConnectionState and VPN TunnelState/VgwTelemetry so an outage pages you before users notice.
Confirm the backup actually works. Periodically verify both VPN tunnels are UP while idle, so the failover path is proven before you need it.
Tag every hybrid resource. Connections, VIFs, gateways, attachments, and VPNs all take tags; untagged hybrid networking is the hardest to cost-attribute and clean up.
Clean up idle attachments and connections. An unused Transit Gateway attachment or an orphaned Direct Connect gateway association keeps billing until removed.
Because Transit Gateway and Direct Connect cannot route between overlapping ranges, and re-addressing a live network is extremely disruptive. A single non-overlapping scheme across regions and accounts keeps all future connectivity possible.
Is one Direct Connect connection ever enough?
Not for anything you cannot afford to lose. A single link is a single point of failure. Add a second connection at another location, or at minimum a dynamic-routing VPN backup on the same hub.
Why does static routing break failover?
Static routes do not withdraw when a link goes down, so the Transit Gateway keeps sending traffic into a dead path. BGP routes withdraw on failure, which is what shifts traffic to the backup automatically.
Why doesn't my cross-region peering route anything?
Cross-region Transit Gateway peering does not propagate routes. Every route across the peering attachment must be added statically on both regions' route tables, even though the attachment shows available.
How do I stop dev from reaching production through the hub?
Disable default association/propagation, give each environment its own route table, and never propagate dev's routes into prod's table (or vice versa). Both can still reach a shared-services table. Isolation comes from omitting propagation.
What are the main hybrid networking cost drivers?
Transit Gateway per-attachment hourly charges and per-GB data processing, cross-region peering data transfer billed on both sides, and Direct Connect port and data-transfer-out charges. Tag resources and keep chatty traffic region-local.
How should I monitor hybrid links?
Alarm on CloudWatch metrics - Direct Connect ConnectionState, VPN tunnel state and VgwTelemetry - rather than polling. And periodically confirm both VPN tunnels are UP so the backup is proven before an outage.
Should I restrict what on-premises can advertise?
Yes. Set allowedPrefixesToDirectConnectGateway on the Direct Connect gateway association so on-premises can only advertise expected prefixes, preventing accidental or malicious route injection.
What is the safe way to grant cross-account access to the hub?
Share the Transit Gateway via AWS RAM, let spoke accounts create attachments that land in pendingAcceptance, and have the network account accept and control association/propagation - keeping routing authority central.
Do I need routes inside each VPC too?
Yes. The Transit Gateway route tables are only half the path. Each VPC subnet route table needs a route sending remote CIDRs to the Transit Gateway attachment, or traffic never leaves the VPC.