feat: expose amazon_side_asn variable

[PePe Amengual (jamengual)]

what

Adds optional amazon_side_asn variable to the module (default 64512, matching the AWS provider default) and plumbs it through to the aws_ec2_transit_gateway resource.

variable "amazon_side_asn" {
  type    = number
  default = 64512
}

 resource "aws_ec2_transit_gateway" "default" {
   ...
+  amazon_side_asn                    = var.amazon_side_asn
   auto_accept_shared_attachments     = var.auto_accept_shared_attachments
   ...
 }

why

The module currently does not expose amazon_side_asn, so all Transit Gateways created by it share the AWS default ASN 64512. This is a problem in several real-world deployments:

• TGW-to-TGW peering (same or cross-region) — AWS rejects peering attachments when both TGWs share an ASN.
• Direct Connect Gateway associations — each TGW associated with a DXGW must have a unique ASN.
• BGP-based Site-to-Site VPN — when multiple TGWs terminate against the same on-premises customer gateway, identical ASNs cause unpredictable BGP best-path selection.

In our SALUS landing zone we run two Transit Gateways (prod + non-prod) in the same account; without distinct ASNs we cannot move to BGP VPNs or DX in the future without destroying and recreating both TGWs (because `amazon_side_asn` is `ForceNew` on the underlying resource).

references

• AWS Terraform provider — `aws_ec2_transit_gateway` argument reference
• AWS API — `TransitGatewayRequestOptions.AmazonSideAsn`
• AWS whitepaper — Building a Scalable and Secure Multi-VPC AWS Network Infrastructure

test

• `terraform init -backend=false` — OK
• `terraform validate` — Success! The configuration is valid.
• `terraform fmt -recursive -check` — clean
• Default value preserves current behavior; no existing deployment will see drift.

[PePe Amengual (jamengual)]

/terratest

[Veronika Gnilitska (gberenice)]

👍

[github-actions]

These changes were released in v0.13.1.