Terraform provides a declarative, open-source Infrastructure as Code workflow for provisioning AWS Transit Gateway resources. The combination enables repeatable creation of a network transit hub that connects multiple Amazon Virtual Private Clouds, VPN connections, Direct Connect gateways, and on-premises networks under centralized routing control. This article covers the core concepts, module design, attachment patterns, and Terraform configuration patterns for building a hub-and-spoke network with Transit Gateway.
What Terraform and AWS Transit Gateway Are
Terraform is an open-source Infrastructure as Code software tool where you define and create resources using providers in a declarative configuration language example JSON. With Terraform, you can package and reuse code in the form of modules. It supports a number of cloud infrastructure providers such as AWS, Azure, GCP, IBM Cloud, OCI, etc.
AWS Transit Gateway is a service that simplifies network connectivity for multiple Amazon Virtual Private Clouds and on-premises networks. It acts as a hub that allows you to connect VPCs and VPN connections, enabling centralized management of network routing and traffic between these resources.
A transit gateway is a network transit hub that you can use to interconnect your virtual private clouds and on-premises networks. The networking service uses a hub-and-spoke model to connect on-premises data centers and Amazon Virtual Private Clouds to a single gateway. With Transit Gateway, you can connect up to 5,000 VPCs and on-premises networks to a single gateway, making it easier to manage and scale your network as your business grows.
Hub-and-Spoke Architecture and Scaling Benefits
The Transit gateway acts like a hub and spoke model where each spoke VPC connects to the single gateway from where the traffic routing is managed by TGW. One of the main benefits of using AWS Transit Gateway is that it helps you to reduce the complexity and cost of your network infrastructure.
Transit Gateway is a network hub that connects multiple VPCs, VPN connections, and Direct Connect gateways through a single central point. Before Transit Gateway, connecting N VPCs required N*(N-1)/2 peering connections. With Transit Gateway, each VPC just connects to the hub. Once you've got more than two or three VPCs, Transit Gateway is the way to go.
Transit Gateway replaces the mesh of VPC peering connections with a centralized hub:
TGW[Transit Gateway] --> VPC_A[VPC A - Production]
TGW --> VPC_B[VPC B - Staging]
TGW --> VPC_C[VPC C - Shared Services]
TGW --> VPC_D[VPC D - Development]
TGW --> VPN[VPN Connection]
VPN --> OnPrem[On-Premises Network]
A Transit Gateway acts as a Regional virtual router for traffic flowing between your Virtual Private Clouds and on-premises networks. Transit Gateway simplifies how customers interconnect their networks to scale their AWS workloads. Transit Gateway reduces the number of connections needed to connect many VPCs, AWS accounts, and on-premises networks.
As your cloud infrastructure expands globally, inter-Region peering connects transit gateways together using the AWS Global Infrastructure.
Transit Gateway Versus VPC Peering
Peering is wonderful, but it just doesn’t scale well. Consider an architecture with only five VPCs before implementing something like Transit VPC or Transit Gateway. When you start to have a lot of peering connections between multiple VPCs, in multiple regions, across multiple AWS accounts, managing the connections starts to get difficult.
Transit Gateway solves the complexity involved with creating and managing multiple VPC peering connections at scale. Transit Gateway should be utilized whenever connectivity is required with more than two VPCs.
A transit gateway is an effective method of connecting multiple VPCs, Direct Connects, VPNs, and other networks. Transit gateways are also a good way to connect VPCs to shared services, such as NAT gateways, firewalls, and other security appliances. By using a transit gateway, the number of connections to and from VPCs can be reduced, which reduces the number of routes that need to be managed.
Transit Gateway can also be used to isolate workloads by attaching VPCs and on-premises networks to different route tables which can send traffic to security appliances, such as virtual firewalls.
Terraform Module Design and Configuration
A Terraform module for deploying AWS Transit Gateways does not use default route tables by design - specify all the route tables explicitly through respective input variables.
Module Requirements and Providers
| Name | Version |
|---|---|
| terraform | >= 1.5.0, < 2.0.0 |
| aws | ~> 5.17 |
| Name | Version |
|---|---|
| aws | ~> 5.17 |
For complete examples using the terraform-aws-modules repository:
| Name | Version |
|---|---|
| terraform | >= 1.5.7 |
| aws | >= 6.28 |
| Name | Version |
|---|---|
| aws | >= 6.28 |
Core Inputs
| Name | Description | Type | Default | Required |
|---|---|---|---|---|
| asn | BGP Autonomous System Number of the AWS Transit Gateway | number | 65200 | no |
| autoacceptshared_attachments | See the provider documentation | string | null | no |
| create | Trigger module mode between creating a new TGW or retrieving an existing one | bool | true | no |
| dns_support | See the provider documentation |
Resources Created by the Module
| Name | Type |
|---|---|
| awsec2transit_gateway.this | resource |
| awsec2transitgatewayroute_table.this | resource |
| awsramprincipal_association.this | resource |
| awsramresource_association.this | resource |
| awsramresource_share.this | resource |
Additional data sources are available:
| Name | Type |
|---|---|
| awsec2transit_gateway.this | data source |
| awsec2transitgatewayroute_table.this | data source |
A complete module resource set includes:
| Name | Type |
|---|---|
| awsec2tag.this | resource |
| awsec2transit_gateway.this | resource |
| awsec2transitgatewayroute.this | resource |
| awsec2transitgatewayroute_table.this | resource |
| awsec2transitgatewayroutetableassociation.this | resource |
| awsec2transitgatewayroutetablepropagation.this | resource |
| awsec2transitgatewayvpc_attachment.this | resource |
| awsramprincipal_association.this | resource |
| awsramresource_association.this | resource |
Example module invocation:
hcl
module "tgw" {
source = "terraform-aws-modules/transit-gateway/aws"
name = "my-tgw"
description = "My TGW shared with several other AWS accounts"
enable_auto_accept_shared_attachments = true
vpc_attachments = {
vpc = {
vpc_id = "vpc-1234556abcdef"
subnet_ids = ["subnet-abcde012", "subnet-bcde012a", "subnet-fghi345a"]
dns_support = true
ipv6_support = true
tgw_routes = [
{
destination_cidr_block = "30.0.0.0/16"
},
{
blackhole = true
destination_cidr_block = "40.0.0.0/20"
}
]
}
}
ram_allow_external_principals = true
ram_principals = [307990089504]
tags = {
Terraform = "true"
Environment = "dev"
}
}
The complete example shows TGW in combination with the VPC module and Resource Access Manager. The multi-account example shows TGW resources shared with different AWS accounts via Resource Access Manager.
VPC Attachment and Resource Access Manager Sharing
Configuration in this directory creates AWS Transit Gateway, attach VPC to it and share it with other AWS principals using Resource Access Manager.
To run this example you need to execute:
bash
terraform init
terraform plan
terraform apply
terraform destroy when you don't need these resources.
Modules used in the complete example:
| Name | Source | Version |
|---|---|---|
| tgw | ../../ | n/a |
| vpc1 | terraform-aws-modules/vpc/aws | ~> 6.0 |
| vpc2 | terraform-aws-modules/vpc/aws | ~> 6.0 |
Data sources:
| Name | Type |
|---|---|
| awsavailabilityzones.available | data source |
Outputs provided by the example:
| Name | Description |
|---|---|
| ec2transitgateway_arn | EC2 Transit Gateway Amazon Resource Name |
| ec2transitgatewayassociationdefaultroutetable_id | Identifier of the default association route table |
| ec2transitgateway_id | EC2 Transit Gateway identifier |
| ec2transitgatewayownerid | Identifier of the AWS account that owns the EC2 Transit Gateway |
| ec2transitgatewaypropagationdefaultroutetable_id | Identifier of the default propagation route table |
| ec2transitgatewayrouteids | List of EC2 Transit Gateway Route Table identifier combined with destination |
| ec2transitgatewayroutetable_association | Map of EC2 Transit Gateway Route Table Association attributes |
| ec2transitgatewayroutetableassociationids | List of EC2 Transit Gateway Route Table Association identifiers |
Creating Transit Gateway with Terraform Steps
This guide covers creating a Transit Gateway, attaching VPCs, configuring route tables, and building a hub-and-spoke architecture with Terraform.
The Hub-and-Spoke Model replaces the mesh of VPC peering connections with a centralized hub.
Creating the Transit Gateway itself is simple to create. The Transit Gateway itself is a resource that can be provisioned declaratively and then VPC attachments, route tables, associations, and propagations are defined as additional resources.
Usage examples for the module are available in the examples folder. For example usage, please refer to the examples directory.
Conclusion
Terraform AWS Transit Gateway implementations provide a scalable, declarative alternative to VPC peering meshes. The hub-and-spoke model centralizes routing, reduces the number of required connections from N*(N-1)/2 to N, and enables management of up to 5,000 VPCs and on-premises networks per gateway. Module design emphasizes explicit route table definitions, no implicit defaults, and integration with Resource Access Manager for cross-account sharing. Version constraints for the terraform-aws-modules transit-gateway module require Terraform >= 1.5.7 and AWS provider >= 6.28, with earlier community modules targeting Terraform >= 1.5.0 and AWS ~> 5.17. The pattern supports VPC attachments with DNS and IPv6 support, custom TGW routes including blackhole routes, auto-accept shared attachments, and tagging for environment governance. When connectivity involves more than two VPCs, multiple regions, or shared services such as NAT gateways and firewalls, Transit Gateway with Terraform delivers centralized control, reduced route management overhead, and repeatable infrastructure through modules and Resource Access Manager sharing.