aws-ec2: Getting Cannot delete export though no changes in VPC stack

[RambabuPatina]

Describe the bug

Hi Team,

We have two AWS CDK stacks: the VPC stack, which provisions the VPC, subnets, and related networking resources, and the EKS stack, which creates the EKS cluster and a security group to allow access to an EFS file system. To enable this, we pass VPC details from the VPC stack to the EKS stack and use the VPC CIDR range to configure security group ingress rules.

       const efsSg = new SecurityGroup(stack, constructId, {
		vpc: props.vpc,
		description: "xxxx for Fargate",
		securityGroupName: `${constructId}-efs-sg`,
		allowAllOutbound: true,
	});

	const vpcCidrBlock = props.vpc.vpcCidrBlock;

	efsSg.addIngressRule(
		Peer.ipv4(vpcCidrBlock),
		Port.tcp(2049),
		"Allow NFS access from VPC CIDR",
	);

On re-deployment we are getting below error, however it is reproducible in one account consistently but not in other account.
xxxxxx-dev-vpc-stack Delete canceled. Cannot delete export xxxxxxxx-dev-vpc-stack:ExportsOutputFnGetAttxxxxxxxxdevvpcstackVpcConstructxxxxvpcxxxxxxxxdevvpcstackVpcxxxxvpc480918FACidrBlock07D1D2D0 as it is in use by xxxxxxxx-dev-eks-cluster

We observed that the CloudFormation export for CidrBlock from the VPC stack is being used in the EKS stack. However, despite no changes in the VPC stack, CloudFormation attempts to update the export name for CidrBlock, which is unexpected. This behavior is surprising, and we are unsure of the reason. Do you know if this is a known issue or if there is an explanation for this behavior?

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Version

No response

Expected Behavior

It should not update the cfn export name for 'CidrBlock'

Current Behavior

It is updating the cfn export name for 'CidrBlock' which causing VPC stack deployment failure

Reproduction Steps

1. Create a VPC stack with some CIDR range
2. Pass the VPC props to other stack EKS stack and create it
3. Use below snippet to create a Security Group in EKS stack

       const efsSg = new SecurityGroup(stack, constructId, {
		vpc: props.vpc,
		description: "xxxx for Fargate",
		securityGroupName: `${constructId}-efs-sg`,
		allowAllOutbound: true,
	});

	const vpcCidrBlock = props.vpc.vpcCidrBlock;

	efsSg.addIngressRule(
		Peer.ipv4(vpcCidrBlock),
		Port.tcp(2049),
		"Allow NFS access from VPC CIDR",
	);

4. Re-deploy the whole stack
   (Note: This is consistently reproducible in one account but not in other account. Not sure why VPC stack is trying to update the export name for 'CidrBlock')

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.172.0 (build 0f666c5)

Framework Version

No response

Node.js Version

18.x

OS

MacOs

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

Can you share your vpc stack? How do you create the vpc and share its CidrBlock?

Also, when you run cdk diff, did you see any change from the vpc stack?

[pahud]

OK I see some potential issue here:

This is essentially a cross-stack reference for Vpc CidrBlock.

The key issue is in how CDK generates the export name. Looking at the code in refs.ts:

aws-cdk/packages/aws-cdk-lib/core/lib/private/refs.ts

Line 246 in 9449f9c

function generateExportName(importStack: Stack, reference: Reference, id: string): string {

So when you synthesize the EKS stack:

1. CDK needs to generate an import expression for the CIDR block
2. The import expression references an export that must exist in the VPC stack
3. The export name is generated based on the logical IDs and paths in both stacks
4. If anything in the EKS stack changes that affects how CDK generates these names (like stack name, construct IDs, or the path to where vpc.vpcCidrBlock is used), it will generate a different export name
5. This forces CloudFormation to try to update the export name in the VPC stack, even though the VPC itself hasn't changed
   This is why you see the error "Cannot delete export" - CloudFormation is trying to rename the export because CDK generated a different name for it during the EKS stack synthesis.

On re-deployment we are getting below error,
Can you tell me what you have changed on the EKS stack before the re-deployment?

I'll bring it up to the team for further inputs and investigation.

[RambabuPatina]

Hi @pahud , Thanks for your swift response and digging into the issue.

Here are the answers for questions,

1. Can you share your vpc stack? How do you create the vpc and share its CidrBlock?
   A) We are using the Vpc construct from 'aws-cdk-lib/aws-ec2' to create a VPC with specific properties. The VPC properties are then shared from the VPC stack to the EKS stack, establishing a dependency between these two stacks—ensuring that the VPC stack is deployed first, followed by the EKS stack. Although we cannot share our entire code, below is an example of how we pass the VPC details to the EKS stack:

const vpcTask = new VpcTask(this, this._appPreRequisites);
const vpcStack = vpcTask.deploy();
const vpc = vpcStack?.getVpc();
...
const eksStack = new EKSTask(this, this._appPreRequisites).deployEKSStack(
vpc
);

2. When you run cdk diff, did you see any change from the vpc stack
   A) We did run and found a difference that it is trying to update export key for 'CidrBlock'. I’m fairly certain that there were no changes in the VPC stack code. [Edited]
3. Can you tell me what you have changed on the EKS stack before the re-deployment?
   A) In the EKS stack, we made changes to remove the EFS file system and its associated security group, which referenced the VPC CIDR. However, please note that during re-deployment, the deployment fails at the VPC stack itself and does not reach the EKS stack.

Please let me know if needed additional details.

Thanks,
Rambabu

[pahud]

@RambabuPatina Thank you for the report. While my assumption above might be valid, we still need a minimal code snippet to reproduce that on our end before we are able to address the root cause and get it fixed. Any chance would you help us provide minimal code snippet that we can simply paste into our IDE and reproduce this error? I will try to build one on my end though. This ensures we are aligned on the same code snippets.