AWS::EC2::TransitGatewayAttachment - SubnetIds should not require replacement

[sturdiva]

2. Scope of request

Currently updating the SubnetIds property of a transit gateway VPC attachment requires replacement, however there is an underlying API (ModifyTransitGatewayVpcAttachment) which would allow for making such an update without replacement.

3. Expected behavior

In Update, changing the SubnetIds property should not require replacement.

4. Suggest specific test cases

5. Helpful Links to speed up research and evaluation

ModifyTransitGatewayVpcAttachment API docs:

https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyTransitGatewayVpcAttachment.html

6. Category (required) - Will help with tagging and be easier to find by other users to +1

Networking & Content (VPC, Route53, API GW,...)

[dhruvdakoria]

Have the same issue. I see the ticket has been open for a year. Any updates or timeline on this request?

This is a critical issue and a limitation because when adding new subnet, we will need to delete the existing TGW attachment and recreate the TGW attachment with updated subnets list (new physical resource ID). TGW Route Tables would also need to be updated just to accommodate this small change which should not be the case.

[hyogyunbang]

I have the same issue. Does anyone have a workaround to add a subnet to a existing transit gateway attachment?

[wawaberry]

I believe I am hitting the same issues. The delete and recreate would cause a brief outage for existing subnets and is not clean. Is there any progress on modify functionality

[hyogyunbang]

@wawaberry I asked AWS Enterprise Support Team about this issue 6 months ago, they confirmed replacement was required.

[f7o]

A replacement is just not possible if you do not change the VPC, which is the common use case to switch from HA multi AZ to a single subnet in a single AZ.

A replacement is trying to create a new attachment for the same VPC and TGW. This fails cause an attachment already exists.

-> No update of subnets via CFN possible! This is not a feature from my pov, rather then an unexpected/miss-leading behaviour.

Any updates on this?

[srikanthkube]

I hit the same issue when adding/modifying subnets using AWS::EC2::TransitGatewayAttachment resource. Found the alternative TG attachment resource AWS::EC2::TransitGatewayVpcAttachment. This allow to add/remove subnets to TG attachment.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-transitgatewayvpcattachment.html

Hope this helps.

[f7o]

@srikanthkube I do not want to comment on the way that is implemented to be honest!

But, most use cases keep actually state properly. If you look at my use case adding subnets and removing subnets via parameters, i need to specify properties reflecting the state of a VPC.

This strange resource provider basically lets me call add subnets/ remove subnets API via CFN!? I my opinion "AddSubnetIds" is no state, this is a parameter for an operation.

As Cfn is a state machine itself how does this implementation into the whole concept?

[rhbecker]

I'm trying to understand the current state of play here ...

The original poster indicates that, wrt the AWS::EC2::TransitGatewayAttachment resource ...

updating the SubnetIds property of a transit gateway VPC attachment requires replacement

But the documentation for that resource's SubnetIds property indicates ...

Update requires: No interruption

Is the documentation wrong? Has that resource been enhanced to allow edits to the SubnetIds value?

From some of the comments on this thread (and on #1133 and #661), it seems like maybe the AWS::EC2::TransitGatewayVpcAttachment resource is newer, and intended to replace the AWS::EC2::TransitGatewayAttachment resource? If that is the case, it seems like some sort of deprecation notice should be added to the docs - or at least some guidance to help new users understand why both resources exist.

Regarding the AWS::EC2::TransitGatewayVpcAttachment resource, I share @f7o's concerns that its AddSubnetIds and RemoveSubnetIds properties seem oddly procedural, relative to the more standard declarative approach of CFN.

Additionally, its documentation doesn't seem to explain the design intentions around how the various subnet id properties should be used in relation to one another - particularly, over time. Are the AddSubnetIds and RemoveSubnetIds properties intended to be used in only a single stack update operation, with values subsequently relocated into or out of the SubnetIds property to capture sustained state? What happens if you run multiple stack updates with the same values in those properties? Etc.