Super Powered, Super Sharp, Super Router!

What’s up world?!

Welcome back for moar spicy cloud networking Terraform takes because we servin’ them HOT over here so let’s dig in!

This is a follow up to the generating routes blog post.

TNT Architecture Recap

The Terraform Networking Trifecta project demonstrated the ability to “scale” AWS VPCs in Terraform code by adding VPC objects to a list.

Example VPC architecture but with ephemeral subnets: vpc-ng

With Tiered VPCs we can narrow down the context (ie app, cicd, general) and maximize the use of smaller network sizes.

Then routing between them by passing a map of Tiered VPC-NG modules to the Centralized Router module which will attach the VPCs to a Transit Gateway with the proper peering and routing.

Example TNT Architecture (zoom out): tnt

Super Router

The Super Router module now provides both intra-region and cross-region peering and routing for Centralized Routers and Tiered VPCs.

We can now “scale” TGW architecture by adding them to their relative provider’s region list of Centralized Routers (ie aws.local -> local_centralized_routers or aws.peer -> peer_centralized_routers) to enable routing across TGWs and VPCs (same AWS account only, no cross account).

module "tgw_super_router_usw2_to_use1" {
  source = ""

  providers = {
    aws.local = aws.usw2 # super router will be built in the aws.local provider region
    aws.peer  = aws.use1

  env_prefix                = var.env_prefix
  region_az_labels          = var.region_az_labels
  local_amazon_side_asn     = 64521
  local_centralized_routers = [module.tgw_centralized_router_usw2, module.tgw_centralized_router_usw2_another] # local list must be all same region as each other in aws.local provider.
  peer_centralized_routers  = [module.tgw_centralized_router_use1, module.tgw_centralized_router_use1_another] # peer list must all be same region as each other in aws.peer provider.

The Super Router Demo will build the following architecture: super-router

It can be validated with AWS Route Analyzer and it’s free to use, tiiiight!


The caveat to the module design is that the peer TGWs will have to go through the super router’s local provider region to get to other peer TGWs.

For instance, in the Super Router demo, TGWs in us-east-1 will have to route through the Super Router TGW in us-west-2 to get to other TGWs in us-east-1.

This wasn’t intended but it’s how the design played out leading to an interesting consequence.

Maybe the peer regions can be used for failover regions for disaster recovery or workers only?

Seems like Super Router would need to be 2 or more separate TGW routers, 1 for each region, instead of 1 to eliminate that peer cross region journey to other peers.

It would make for better TGW redundancy and would be a nice next iteration.

Definitely a bigger lift to refactor but I think it can be done.


It’s cool that we can have network communication working cross-region but ideally we want to enable muliple cross region communication for each environment.

However, the routing could get complicated quickly by adding more aliased providers to the Super Router module.

After glancing at some of the docs for the new AWS Cloud WAN service, it seems possible to create a Cloud WAN Terraform module to tie multiple Super Router modules together (or just TGW Centralized Routers?) to get a decent global routing architecture between multiple regions without having to do more route generation ourselves.

But that’s just an initial assumption.

There are some obvious features that can be added like more CIDR and ASN validations across Centralized Routers (etc).

Either way I’m hoping you take the time to try out the Super Router Demo because I’d love to hear people’s feedback.


Lots of lessons learned but the saga continues… “I said one two, three and to the four, I glide like there’s simply no traction on the floor.” - Rebel INS

~jq1 #StayUp #KeepBuilding #AoD


What did you think about this post?