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 auto named subnets:
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 vpc attachments and routing.
Example TNT Architecture (zoom out):
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 = "git@github.com:JudeQuintana/terraform-modules.git//networking/tgw_super_router_for_tgw_centralized_router?ref=v1.4.4"
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:
It can be validated with AWS Route Analyzer and it’s free to use, tiiiight!
Caveats
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.
Future
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.
Links:
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
Update: Super Router has been super refactored.