/terraform-aws-transit-gateway-satellite

Terraform module for handling the Transit Gateway satellite resources

Primary LanguageMakefileMIT LicenseMIT

Terraform Transit Gateway "satellite" module

We are following the hub-spoke(s) (aka star network) network topology model.

This Terraform module aims to handle the AWS resources required by a so-called "satellite" node.

It is important to mention that the invocation of this module is going to actually make cross-account changes. That is, we need to adjust the configuration on the hub side (mainly routing).

This module assumes that its pair module was used: terraform-aws-transit-gateway-hub to handle the actual TGW.

Check out the examples in the aforementioned module.

Supported resources

At the moment, this module only supports attaching VPCs to the TGW. Support for VPN tunnels will be added soon.

Assumptions

Credentials

See this example to first make sure that the credentials you want to use allow for cross-account actions.

You can read more about how Terraform handles this here.

Obviously, all the supported authentication methods can also be used.

Routing

For creating the network routes on the satellite side, the module expects to find the keyword "private" in the name of the subnets, so that it may collect their IDs and those of their associated routing tables. Check the subnet_name_keyword_selector variable if you want to change this.

When creating TGW attachments, AWS supports adding only one subnet per AZ. For example, when a VPC has 6 subnets, with each AZ having a pair consisting of a public and a private subnet, it's recommended to only use the private subnets when creating the TGW attachment. For the described example, in the eu-central-1 (Frankfurt) region, as currently there are 3 Availability Zones, the TGW attachment will contain 3 (private) subnets. The resources placed within the remaining subnets (public and/or private), will also be able to route their traffic through the TGW.

ACLs

Caveat: Building on the example described above, when using Network ACLs (NACLs), the behaviour is different between subnets that are part of the TGW attachment and subnets that aren't.

Specifically, because the ACL rules are stateless (as opposed to the Security Group rules, which are stateful), when trying to reach an external IP from a subnet that is also part of the TGW attachment, this will work even without an explicit ACL allow rule.

However, for another subnet that's not part of the TGW attachment, although with a NACL allow rule for the targeted external CIDR in place, the traffic will not flow.

This has to do with how NACL inbound rules are not being evaluated since the resource (i.e. EC2 instance) is in the same subnet with the TGW association.

Unfortunately, AWS fails to provide explicit documentation for this behavior. It is implied on this documentation page and they've been made aware of this fact.

Requirements

Name Version
terraform >= 1.2
aws ~> 4.27.0

Providers

Name Version
aws.hub ~> 4.27.0
aws.satellite ~> 4.27.0

Inputs

Name Description Type Default Required
aws_account_id_hub AWS account number containing the TGW hub string n/a yes
role_to_assume_hub IAM role name to assume in the AWS account containing the TGW hub (eg. ASSUME-ROLE-HUB) string n/a yes
attachment_subnet_filters List of maps selecting the subnet(s) where TGW will be attached 
list(object({
    name   = string
    values = list(string)
  }))
 
[
  {
    "name": "tag:Name",
    "values": [
      "private"
    ]
  }
]
 no
aws_account_id_satellite AWS account number containing the TGW satellite string "" no
hub_destination_cidr_blocks List of CIDRs to be routed for the hub list(string) [] no
private_subnet_filters List of maps selecting the subnet(s) which are private 
list(object({
    name   = string
    values = list(string)
  }))
 
[
  {
    "name": "tag:Name",
    "values": [
      "private"
    ]
  }
]
 no
private_subnets_strict_acl_rules Create additional ACLs for private subnets to restrict inbound traffic only to VPC itself and VPCs paired over TGW bool false no
ram_resource_association_id Identifier of the Resource Access Manager Resource Association string "" no
role_to_assume_satellite IAM role name to assume in the AWS account containing the TGW satellite (eg. ASSUME-ROLE-SATELLITE) string "" no
route_entire_satellite_vpc Boolean flag for toggling the creation of network routes for all the subnets of the satellite VPC bool false no
route_private_subnets_via_tgw Use TGW attachment as a default route (0.0.0.0/0) for private subnets. Value satellite_destination_cidr_blocks will be ignored. bool false no
satellite_create Boolean flag for toggling the handling of satellite resources bool false no
satellite_destination_cidr_blocks List of CIDRs to be routed for the satellite list(string) [] no
transit_gateway_default_route_table_association Set this to false when the hub account also becomes a satellite. Check the official docs for more info. bool true no
transit_gateway_default_route_table_propagation Set this to false when the hub account also becomes a satellite. Check the official docs for more info. bool true no
transit_gateway_hub_name Name of the Transit Gateway to attach to string "" no
transit_gateway_id Identifier of the Transit Gateway string "" no
transit_gateway_route_table_id Identifier of the Transit Gateway Route Table string "" no
vpc_name_to_attach Name of the satellite VPC to be attached to the TGW string "" no

Outputs

Name Description
transit_gateway_vpc_attachment_id Identifier of the Transit Gateway VPC Attachment

To do

  • Collect TGW ID directly rather than using a RAM data source (currently not supported)
  • Add support for VPN attachments