[aws-efs] New EFS fails to create due to : "fsmt-123456 already exists in stack..." on existing VPC with other EFS mounts

When creating a new stack and just trying to create a new EFS, I receive numerous errors:

fsmt-96f68d16 already exists in stack arn:aws:cloudformation:us-east-1:311209486165:stack/CodepipelineForEcrStack/9eee4d30-ee60-11ea-ab6f-12717722e021

Once for each subnet.

Reproduction Steps

I am doing:

import * as cdk from '@aws-cdk/core';
import { Vpc } from '@aws-cdk/aws-ec2';
import { FileSystem, PerformanceMode, ThroughputMode } from '@aws-cdk/aws-efs';

export class CodepipelineForEcrStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Import VPC
    const vpc = Vpc.fromLookup(this, "CdkTestVPC", {
      vpcId: "vpc-xxxxxxx"
    });

    // EFS
    const _efsName = 'cdkTest';
    const _efs = new FileSystem(this, 'CdkTestEFS', {
      vpc: vpc,
      performanceMode: PerformanceMode.GENERAL_PURPOSE,
      throughputMode: ThroughputMode.BURSTING,
      // fileSystemName: _efsName,
      removalPolicy: cdk.RemovalPolicy.DESTROY, // Destroy EFS when we delete the stack
    });    

  }
}

Then when I cdk deploy I get numerous errors about the file system mounts already exist. During my numerous tests, I also was able to confirm this issue too.

I have manually checked and deleted both security groups and network interfaces but I still get these errors.

When the stack is rolled back, the security groups and the network interfaces persist. I have to manually delete them.

I am new to the CDK but I would expect that to launch the EFS into my existing VPC.

What did you expect to happen?

I was trying to create an EFS.

I was also hoping to control the subnets this mounted to but it seems to mount to all subnets as this is how many fsmt’s it tried to deploy.

What actually happened?

I received numerous errors:

fsmt-96f68d16 already exists in stack arn:aws:cloudformation:us-east-1:311209486165:stack/CodepipelineForEcrStack/9eee4d30-ee60-11ea-ab6f-12717722e021

One of these for each fsmt for each subnet.

Then the stack rollsback and it takes 2 hours to resolve (only on EFS rollback). I spent 14 hours today on 7 edits… literally. Found it was faster to delete the efs parts myself to speed up the time. Didn’t find this out until just now…

Environment

• CLI Version : 1.61.1 (build 347918f)
• Framework Version: 1.61.1
• Node.js Version: v12.18.3
• OS : Linux Zeus 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
• Language (Version): typescript (3.9.7)

Other

I ran into this issue while working on my stack. I then decided to just try to create just the EFS and that’s when I realized I was not able to do this.

At first, I thought it was due to me using a custom name. So I commented that out and it still happens.

In case this helps, I just commented out my stack and used the code I posted above. Since it was in the same stack just destroyed than deployed, I don’t think this would be an issue but wanted to make note.

Also, this VPC already has 2 EFS mounts in it that are named something completely different.

Thank you.

---

This is 🐛 Bug Report

[ssedrick]

I found a workaround, at least for my case. Because we had both public and private subnets in the same AZs, I had to change the EFS to only create mountpoints on the private subnets. This reduced the redundancy and allowed me to create the EFS without any issue:

const fileSystem = new efs.FileSystem(this, 'some-efs-identity', {
  ...,
  vpcSubnets: {
    subnetType: ec2.SubnetType.PRIVATE,
    onePerAz:  true,  // This might help as well.
  },
});

[ssedrick]

I’m also running into this issue. The stack is creating 6 file system mount points, but the stack tries to give them 3 physical ids, each id having 2 separate logical ids.

CloudFormation in the console looks like the following:

Logical ID	Physical ID
EfsMountTarget123456789	fsmt-abc123
EfsMountTarget456789abc	fsmt-abc123
EfsMountTarget789abcdef	fsmt-def345
EfsMountTargetabcdef123	fsmt-def345
EfsMountTargetdef123456	fsmt-789abc
EfsMountTarget987654321	fsmt-789abc

If you look at the output of the stack using yarn cdk synth it is trying to create 6 mount targets, but it doesn’t give any physical ids, so I’m not sure where it is assigning these.

CLI Version: 1.67.0 NodeJS Version: 12.18.3 OS: MacOS 10.14.6 Typescript: 3.9.7