AWS Provider v2.2.0 - v2.10.0 keeps changing settings in aws_ec2_transit_gateway_vpc_attachment resource

[piersf]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform & AWS Provider Version

Terraform: v0.11.11
AWS Provider version: tested with 2.2.0 up to 2.10.0

Affected Resource(s)

• aws_ec2_transit_gateway_vpc_attachment

Terraform Configuration Files

For the below resource, AWS Provider from version 2.2.0 up to 2.10.0 will keep setting the properties transit_gateway_default_route_table_association and transit_gateway_default_route_table_propagation to false even though they are already set to false.
It seems to think that these settings are set to true but they are not.

If I downgrade back to AWS Provider version 1.57.0 which was my previous version before upgrading it, then I don't see this behavior anymore.

resource "aws_ec2_transit_gateway_vpc_attachment" "transit_gateway_vpc_attachment" {
  subnet_ids              = ["some-sub-id"]
  transit_gateway_id = "some-tgw-id"
  vpc_id                     = "some-vpc-id"
  dns_support		 = "enable"
  ipv6_support		 = "disable"
  tags                        = "some-tag"
  transit_gateway_default_route_table_association = "false"
  transit_gateway_default_route_table_propagation = "false"
}

Expected Behavior

No change should happen as the resource is already in the configured state.

Actual Behavior

~ aws_ec2_transit_gateway_vpc_attachment.transit_gateway_vpc_attachment
      transit_gateway_default_route_table_association: "true" => "false"
      transit_gateway_default_route_table_propagation: "true" => "false"

Steps to Reproduce

Upgrade to AWS Provider version 2.2.0 or higher and then:

1. terraform plan

Has anyone else noticed this?

Thanks,

[piersf]

Any updates on this?

Thank you

[raut02a]

Hi All and Terraform Team,

I am also facing the issue that even if Transit Gateway attachment already created by terraform code and all other things remains the same, every subsequent run of the same code without any change modifies the attachment in place. Can you please look into this priority as I have 100+ account and their VPCs to attach to Transit Gateway.

Below are details for your analysis.

Definition :

resource "aws_ec2_transit_gateway_vpc_attachment" "target_tgw_attach" {
...
transit_gateway_default_route_table_association = false
transit_gateway_default_route_table_propagation = false
}

Plan:
update in place

--
Terraform will perform the following actions:
module.tgw_attachment.aws_ec2_transit_gateway_vpc_attachment.target_tgw_attach[0] will be updated in-place
~ ~ resource "aws_ec2_transit_gateway_vpc_attachment" "target_tgw_attach" {
...
~ transit_gateway_default_route_table_association = true -> false
~ transit_gateway_default_route_table_propagation = true -> false
...
}
Plan: 0 to add, 1 to change, 0 to destroy

Apply :

aws_ec2_transit_gateway_vpc_attachment.target_tgw_attach[0]: Modifying...
aws_ec2_transit_gateway_vpc_attachment.target_tgw_attach[0]: Modifications complete .

version : 12.20

[raut02a]

@apparentlymart , sorry to tag you in this issue. But looks like this issue passing from 11 to 12 version.
Could you please have a look.

[raut02a]

I think, this gives the answers on why it is always applying the changes even if there is no change in old and new value.

Referring to https://www.terraform.io/docs/providers/aws/r/ec2_transit_gateway_vpc_attachment.html, transit_gateway_default_route_table_association and transit_gateway_default_route_table_propagation cannot be configured or perform drift detection with Resource Access Manager shared EC2 Transit Gateways. Default value: true.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.