Terraform module to provision:

• AWS Transit Gateway
• AWS Resource Access Manager (AWS RAM) Resource Share to share the Transit Gateway with the Organization or another AWS Account (configurable via the variables ram_resource_share_enabled and ram_principals)
• Transit Gateway route table
• Transit Gateway VPC attachments to connect multiple VPCs via the Transit Gateway
• Transit Gateway route table propagations to create propagated routes and allow traffic from the Transit Gateway to the VPC attachments
• Transit Gateway route table associations to allow traffic from the VPC attachments to the Transit Gateway
• Transit Gateway static routes (static routes have a higher precedence than propagated routes)
• Subnet routes to route traffic from the subnets in each VPC to the other Transit Gateway VPC attachments

Tip

👽 Use Atmos with Terraform

Cloud Posse uses atmos to easily orchestrate multiple environments using Terraform.
Works with Github Actions, Atlantis, or Spacelift.

Watch demo of using Atmos with Terraform

Example of running atmos to manage infrastructure from our Quick Start tutorial.

This module is configurable via the variable transit_gateway_config - see usage and examples below.

The variable transit_gateway_config is a map of environment names (e.g. prod, staging, dev) to the environment configurations.

Each environment configuration contains the following fields:

• vpc_id - The ID of the VPC for which to create a VPC attachment and route table associations and propagations.
• vpc_cidr - VPC CIDR block.
• subnet_ids - The IDs of the subnets in the VPC.
• static_routes - A list of Transit Gateway static route configurations. Note that static routes have a higher precedence than propagated routes.
• subnet_route_table_ids - The IDs of the subnet route tables. The route tables are used to add routes to allow traffix from the subnets in one VPC to the other VPC attachments.
• route_to - A set of environment names to route traffic from the current environment to the specified environments. In the example below, in the prod environment we create subnet routes to route traffic from the prod subnets to the VPC attachments in the staging and dev environments. Specify either route_to or route_to_cidr_blocks. route_to_cidr_blocks supersedes route_to.
• route_to_cidr_blocks - A set of VPC CIDR blocks to route traffic from the current environment to the specified VPC CIDR blocks. In the example below, in the staging environment we create subnet routes to route traffic from the staging subnets to the dev VPC CIDR. Specify either route_to or route_to_cidr_blocks. route_to_cidr_blocks supersedes route_to.
• transit_gateway_vpc_attachment_id - An existing Transit Gateway Attachment ID. If provided, the module will use it instead of creating a new one.

You now have the option to have Terraform manage route table entries by key, whereas previously they were only managed by index. The advantage of managing them by key is that if a route table ID or destination CIDR changes, only that entry is affected, whereas when managed by index, all the entries after the first affected index may be destroyed and re-created at a different index. The reason this is left as an option, with the default being to manage the entries by index, is that if you are creating the VPC or subnets at the same time you are creating the Transit Gateway, then Terraform will not be able to generate the keys during the plan phase and the plan will fail with the error The "for_each" value depends on resource attributes that cannot be determined until apply.... We recommend setting route_keys_enabled to true unless you get this error, in which case you must leave it set to its default value of false.

NOTE: This module requires Terraform 0.13 and newer since it uses module expansion with for_each.

Here's how to invoke this module in your projects:

locals {
  transit_gateway_config = {
    prod = {
      vpc_id                            = module.vpc_prod.vpc_id
      vpc_cidr                          = module.vpc_prod.vpc_cidr_block
      subnet_ids                        = module.subnets_prod.private_subnet_ids
      subnet_route_table_ids            = module.subnets_prod.private_route_table_ids
      route_to                          = ["staging", "dev"]
      route_to_cidr_blocks              = null
      transit_gateway_vpc_attachment_id = null

      static_routes = [
        {
          blackhole              = true
          destination_cidr_block = "0.0.0.0/0"
        },
        {
          blackhole              = false
          destination_cidr_block = "172.16.1.0/24"
        }
      ]
    },

    staging = {
      vpc_id                            = module.vpc_staging.vpc_id
      vpc_cidr                          = module.vpc_staging.vpc_cidr_block
      subnet_ids                        = module.subnets_staging.private_subnet_ids
      subnet_route_table_ids            = module.subnets_staging.private_route_table_ids
      route_to                          = null
      route_to_cidr_blocks              = [module.vpc_dev.vpc_cidr_block]
      transit_gateway_vpc_attachment_id = null

      static_routes = [
        {
          blackhole              = false
          destination_cidr_block = "172.32.1.0/24"
        }
      ]
    },

    dev = {
      vpc_id                            = module.vpc_dev.vpc_id
      vpc_cidr                          = module.vpc_dev.vpc_cidr_block
      subnet_ids                        = module.subnets_dev.private_subnet_ids
      subnet_route_table_ids            = module.subnets_dev.private_route_table_ids
      route_to                          = null
      route_to_cidr_blocks              = null
      transit_gateway_vpc_attachment_id = null
      static_routes                     = null
    }
  }
}

module "transit_gateway" {
  source = "cloudposse/transit-gateway/aws"
  # Cloud Posse recommends pinning every module to a specific version
  # version     = "x.x.x"

  ram_resource_share_enabled = false
  config                     = local.transit_gateway_config

  context = module.this.context
}

Here is a working example of using this module:

• examples/complete

Here are automated tests for the complete example using bats and Terratest (which tests and deploys the example on AWS):

• test

Here is an example of using this module in a multi-account environment (with the Transit Gateway in one AWS account and all the VPC attachments and routes in different AWS accounts):

• examples/multi-account

Available targets:

  help                                Help screen
  help/all                            Display help for all targets
  help/short                          This help short screen
  lint                                Lint terraform code

map(object({
    vpc_id                            = string
    vpc_cidr                          = string
    subnet_ids                        = set(string)
    subnet_route_table_ids            = set(string)
    route_to                          = set(string)
    route_to_cidr_blocks              = set(string)
    transit_gateway_vpc_attachment_id = string
    static_routes = set(object({
      blackhole              = bool
      destination_cidr_block = string
    }))
  }))

{
  "additional_tag_map": {},
  "attributes": [],
  "delimiter": null,
  "descriptor_formats": {},
  "enabled": true,
  "environment": null,
  "id_length_limit": null,
  "label_key_case": null,
  "label_order": [],
  "label_value_case": null,
  "labels_as_tags": [
    "unset"
  ],
  "name": null,
  "namespace": null,
  "regex_replace_chars": null,
  "stage": null,
  "tags": {},
  "tenant": null
}

[
  "default"
]

object({
    create = optional(string),
    delete = optional(string),
    update = optional(string)
  })

Check out these related projects.

• terraform-null-label - Terraform module designed to generate consistent names and tags for resources. Use terraform-null-label to implement a strict naming convention
• terraform-aws-vpc - Terraform Module that defines a VPC with public/private subnets across multiple AZs with Internet Gateways
• terraform-aws-vpc-peering - Terraform module to create a peering connection between two VPCs
• terraform-aws-kops-vpc-peering - Terraform module to create a peering connection between a backing services VPC and a VPC created by Kops
• terraform-aws-dynamic-subnets - Terraform module for public and private subnets provisioning in an existing VPC
• terraform-aws-multi-az-subnets - Terraform module for multi-AZ public and private subnets provisioning
• terraform-aws-named-subnets - Terraform module for named subnets provisioning

For additional context, refer to some of these links.

• Terraform Standard Module Structure - HashiCorp's standard module structure is a file and directory layout we recommend for reusable modules distributed in separate repositories.
• Terraform Module Requirements - HashiCorp's guidance on all the requirements for publishing a module. Meeting the requirements for publishing a module is extremely easy.
• Terraform random_integer Resource - The resource random_integer generates random values from a given range, described by the min and max attributes of a given resource.
• Terraform Version Pinning - The required_version setting can be used to constrain which versions of the Terraform CLI can be used with your configuration

This project is under active development, and we encourage contributions from our community.

Many thanks to our outstanding contributors:

For 🐛 bug reports & feature requests, please use the issue tracker.

In general, PRs are welcome. We follow the typical "fork-and-pull" Git workflow.

1. Review our Code of Conduct and Contributor Guidelines.
2. Fork the repo on GitHub
3. Clone the project to your own machine
4. Commit changes to your own branch
5. Push your work back up to your fork
6. Submit a Pull Request so that we can review your changes

NOTE: Be sure to merge the latest changes from "upstream" before making a pull request!

Join our Open Source Community on Slack. It's FREE for everyone! Our "SweetOps" community is where you get to talk with others who share a similar vision for how to rollout and manage infrastructure. This is the best place to talk shop, ask questions, solicit feedback, and work together as a community to build totally sweet infrastructure.

Sign up for our newsletter and join 3,000+ DevOps engineers, CTOs, and founders who get insider access to the latest DevOps trends, so you can always stay in the know. Dropped straight into your Inbox every week — and usually a 5-minute read.

Join us every Wednesday via Zoom for your weekly dose of insider DevOps trends, AWS news and Terraform insights, all sourced from our SweetOps community, plus a live Q&A that you can’t find anywhere else. It's FREE for everyone!

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

All other trademarks referenced herein are the property of their respective owners.

Copyright © 2020-2024 Cloud Posse, LLC