[AWS::EC2::SubnetRouteTableAssociation] - [Enhancement] - CFN to not delete the route table association with the old subnet during an update to the subnet with UpdateReplacePolicy: Retain.

[Waqiah]

Name of the resource

AWS::EC2::SubnetRouteTableAssociation

Resource name

No response

Description

It is understood that UpdateReplacePolicy: Retain keeps the physical instance of a resource when it's replaced during a stack update.

Currently it is seen that when updating the Subnet resource that the AWS::EC2::SubnetRouteTableAssociation resource is associated with, and specifying UpdateReplacePolicy: Retain for both resources, CFN disassociates the route table association with the old subnet and replaces both resources during the update.

Would like to request that CFN doesn't delete the route table association with the old subnet when updating the SubnetId of AWS::EC2::SubnetRouteTableAssociation resource with UpdateReplacePolicy: Retain.

Behaviour can be replicated using sample template below: .... Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.16.0.0/16

PrivateRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: Ref: "VPC"

PrivateSubnet: Type: "AWS::EC2::Subnet" UpdateReplacePolicy: Retain Properties: VpcId: !Ref VPC AvailabilityZone: <insert AZ> CidrBlock: 10.16.0.0/24

PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" DeletionPolicy: Retain UpdateReplacePolicy: Retain Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTable ....

Let's say the subnet ID is subnet-abc and the Route Table Association ID is rtbassoc-123.

Next when performing an update to the subnet resource, for example changing the CidrBlock from 10.16.0.0/24 to 10.16.1.0/24, the update will require replacement on the Route Table Association resource as expected. Meaning the new subnet ID is subnet-def and the Route Table Association ID is rtbassoc-456, albeit subnet-abc still remains in the account.

Hoping to have the old route table association with the old subnet not be deleted as currently it makes it complicated when deploying using Lamdba, etc.

Other Details

No response