cross-region cross-stack references: No longer accessing another stack's resource causes deadly embrace (different region)

[oriolpetit]

Describe the bug

This is a variation of #7602

CDK's automatic determination and synthesis of exports to imports can get locked into a deadly embrace that cannot be resolved without destroying your stacks.

Reproduction Steps
Stack1 creates a common Security Group, sg1.
Stack2 in a different region uses sg1.

CDK's automatic determination and synthesis described here, will trigger a custom resource which will trigger a lambda which will publish will export in ssm parameter store from Stack1 for sg1. Stack2 will import it via by custom resource that reads from parameter store.

Then you deploy these stacks.

Later, you decide that Stack2 really needs it's own more specific Security Group, so you create it's own sg2. Again, CDK's automatic determination and synthesis realizes that sg1 is no longer referenced by Stack2 (or any other stack) and attempts to delete the Export of sg1 from Stack1.

This will fail and cannot be deployed.

CloudFormation will be prevented from deleting sg1 as an export from Stack1 since it is currently being used as an Import in the (existing) Stack2. Ironically, you were trying to update Stack2 to no longer reference Stack1's sg1.

The solution for same region stacks is to use Stack.exportValue(sg1). The solution does not work for cross-region references since cdk is only exporting those references are used in a different region. The lambda link is failing with error:

{
  Status: 'FAILED',
  Reason: 'Error: Exports cannot be updated: \n' +
    '\n' +
    '    at i (/var/task/index.js:4:10)\n' +
    '    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n' +
    '    at async P (/var/task/index.js:3:18)\n' +
    '    at async Runtime.handler (/var/task/__entrypoint__.js:1:932)',

Regression Issue

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

Last Known Working CDK Library Version

No response

Expected Behavior

Stack.exportValue would takes extra arguments that determine that this needs to be exported to a different region and, as such, we avoid a deadly embrace when using cross-region

Current Behavior

https://github.com/aws/aws-cdk/blame/main/packages/aws-cdk-lib/core/lib/custom-resource-provider/cross-region-export-providers/export-writer-provider.ts#L8 does not "read" Stack.exportValue

Reproduction Steps

CDK's automatic determination and synthesis of exports to imports can get locked into a deadly embrace that cannot be resolved without destroying your stacks.

Reproduction Steps
Stack1 creates a common Security Group, sg1.
Stack2 in a different region uses sg1.

CDK's automatic determination and synthesis described here, will trigger a custom resource which will trigger a lambda which will publish will export in ssm parameter store from Stack1 for sg1. Stack2 will import it via by custom resource that reads from parameter store.

Then you deploy these stacks.

Later, you decide that Stack2 really needs it's own more specific Security Group, so you create it's own sg2. Again, CDK's automatic determination and synthesis realizes that sg1 is no longer referenced by Stack2 (or any other stack) and attempts to delete the Export of sg1 from Stack1.

This will fail and cannot be deployed.

CloudFormation will be prevented from deleting sg1 as an export from Stack1 since it is currently being used as an Import in the (existing) Stack2. Ironically, you were trying to update Stack2 to no longer reference Stack1's sg1.

The solution for same region stacks is to use Stack.exportValue(sg1). The solution does not work for cross-region references since cdk is only exporting those references are used in a different region. The lambda link is failing with error:

{
  Status: 'FAILED',
  Reason: 'Error: Exports cannot be updated: \n' +
    '\n' +
    '    at i (/var/task/index.js:4:10)\n' +
    '    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n' +
    '    at async P (/var/task/index.js:3:18)\n' +
    '    at async Runtime.handler (/var/task/__entrypoint__.js:1:932)',

Possible Solution

No response

Additional Information/Context

Potentially, this could be solved if Stack.exportValue would take extra arguments that determine that this needs to be exported to a different region

AWS CDK Library version (aws-cdk-lib)

2.200.0

AWS CDK CLI version

2.200.0

Node.js Version

20

OS

N/A

Language

TypeScript

Language Version

No response

Other information

No response

[sanyamk23]

My approach would be to extend the Stack.exportValue method to accept an additional option, such as crossRegion: true, to explicitly mark values that need to be exported for cross-region references. This would give users granular control and prevent CDK from automatically deleting exports that are still in use by other stacks in different regions.

For example:

// In Stack1 (us-east-1)
const sg1 = new ec2.SecurityGroup(this, 'SG1', { ... });
const sg1Export = this.exportValue(sg1.securityGroupId, { crossRegion: true });

// In Stack2 (eu-west-1)
const importedSg1 = cdk.Fn.importValue(sg1Export);

With this flag, the CDK could ensure that the export is only removed when it is no longer referenced by any stack, regardless of region, avoiding the current “deadly embrace” scenario.

Next Steps:
Update Stack.exportValue to support the new argument.
Adjust the export/import logic to track cross-region references more robustly.
Add tests to verify the export is retained until all references are removed.

Does this approach make sense, or is there additional context I should consider? If no one else is working on this, I’d be happy to start implementing and submit a PR. Please let me know if you’d like me to proceed or if there’s any further guidance.

Thanks for your time, looking forward to contributing!