(EFS): EFS Mount Targets fail if subnets change positions within the vpc_subnets property

[tbreysse]

Describe the bug

When changing the vpc_subnets property of an EFS FileSystem construct, the order of existing subnets is required to stay the same or else an error will occur on update stating that a mount target already exists for a certain AZ.

Expected Behavior

Expected behavior is that the subnets can be changed for vpc_subnets without any failure to update. In theory, any subnets that remain during any update should retain the exact same logical ID and property definitions for the created mount target.

Current Behavior

Currently, the order of subnets within vpc_subnets is required to be unchanging between stack updates.

Example:

Assume there are 3 subnets defined

        subnet1 = ec2.Subnet.from_subnet_id(self, "importsubnet1",
            subnet_id = "subnet-11111111"
        )
        subnet2 = ec2.Subnet.from_subnet_id(self, "importsubnet2",
            subnet_id = "subnet-22222222"
        )
        subnet3 = ec2.Subnet.from_subnet_id(self, "importsubnet3",
            subnet_id = "subnet-33333333"
        )

And assume that a stack with an EFS FileSystem is created with the following vpc_subnets:

vpc_subnets = ec2.SubnetSelection(subnets=[subnet1, subnet2, subnet3]),

If subnet2 is removed as follows,

vpc_subnets = ec2.SubnetSelection(subnets=[subnet1, subnet3]),

then the generated MountTarget created for subnet3 will be deleted, and the MountTarget for subnet2 will have it's SubnetId value changed to subnet3

This causes a failure since the existing mount target will try to update to use subnet3 when the MountTarget originally created for subnet3 still exists.

---

Secondary example:

With the same subnets defined as above, assume a stack with an EFS FileSystem is created with the following vpc_subnets:

vpc_subnets = ec2.SubnetSelection(subnets=[subnet1, subnet2]),

Now is subnet1 and subnet2 swap indexes like this,

vpc_subnets = ec2.SubnetSelection(subnets=[subnet2, subnet1]),

This will also cause the failure because the generated MountTarget resources remain consistent and match their value for the SubnetId property to the matching index value defined for vpc_subnets.

Reproduction Steps

Define 2 subnets

        subnet1 = ec2.Subnet.from_subnet_id(self, "importsubnet1",
            subnet_id = "subnet-11111111"
        )
        subnet2 = ec2.Subnet.from_subnet_id(self, "importsubnet2",
            subnet_id = "subnet-22222222"
        )

Create an EFS FileSystem as follows:

        file_system = efs.FileSystem(self,
            id = 'filesystem',
            vpc = vpc,
            vpc_subnets = ec2.SubnetSelection(subnets=[subnet1, subnet2]),
            file_system_name = "sampleName",
            file_system_policy = iam.PolicyDocument(
            statements = [ iam.PolicyStatement(
                actions = ["elasticfilesystem:*"],
                principals = [iam.AnyPrincipal()],
                conditions = {
                "Bool": {
                    "elasticfilesystem:AccessedViaMountTarget": "true"
                }
                }
            )],
            ),
            # removal_policy = cdk.RemovalPolicy.DESTROY
        )

Then swap the positions of subnet1 and subnet2

        file_system = efs.FileSystem(self,
            id = 'filesystem',
            vpc = vpc,
            vpc_subnets = ec2.SubnetSelection(subnets=[subnet2, subnet1]),
            file_system_name = "sampleName",
            file_system_policy = iam.PolicyDocument(
            statements = [ iam.PolicyStatement(
                actions = ["elasticfilesystem:*"],
                principals = [iam.AnyPrincipal()],
                conditions = {
                "Bool": {
                    "elasticfilesystem:AccessedViaMountTarget": "true"
                }
                }
            )],
            ),
            # removal_policy = cdk.RemovalPolicy.DESTROY
        )

The update will trigger the error reliably.

Possible Solution

CDK seems to need some way to maintain a direct connection between the generated MountTarget resources and their respective subnets.

Currently the MountTarget resources are matched to the subnets based on their index value with vpc_subnets which is prone to error and requires any subnets to maintain the exact same position in the array during updates.

Additional Information/Context

This issue has been noted before here: #25099

Ultimately this issue was closed with a fix that maps the logical ID of the EFS MountTarget resources to index values: #26155

However, the issue appears to persist still, and the fix did not address the main issue where subnet IDs are assigned to different MountTarget IDs based on their index number.

One possible solution would be to map the MountTarget logical IDs to be suffixed with the subnet ID instead of indexes. In theory this should allow the same MountTarget logical IDs to be generated no matter where the subnet is within the index of vpc_subnets.

CDK CLI Version

2.99.1

Framework Version

No response

Node.js Version

18.18.0

OS

Windows 10

Language

Python

Language Version

No response

Other information

No response

[peterwoodworth]

This would be a CloudFormation issue - the order of equivalent sets changing is expected to be handled by CloudFormation properly. We will create an internal ticket for this for the right team, thank you for reporting.

[khushail]

Ticket created with internal team (P101654610). Will follow with them and share updates.

[khushail]

@tbreysse , could you please check in the code(as heard from the team) whether this flagEFS_MOUNTTARGET_ORDERINSENSITIVE_LOGICAL_ID is enabled.

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.