Maintain auto-generated outputs/exports when referencing resources in others stacks.

Maintain auto-generated outputs/exports when referencing resources in others stacks.

Use Case

In order to improve code readability, avoid zombies resources, and ease the deploy process in the pipeline As a devOps I want to be able to maintain the output/export, after not being used. (the output that gets generated when I reference a resource created in other stack)

Proposed Solution

Have an attribute that let us keep the output/export in order to be able to “remove” the reference of the resource but not the output/export, and not fail at deploy time. (almost the same way the retention policy works)

Other

The deployment process seems to be the following: 1st. Synth the template, 2nd. Removes the resources that changed in a way they have to be replaced/recreated, 3rd. Recreates/creates the resources needed, 4th. Replaces the needed references. 5th. The rest of the steps. or so it seems.

For example: Version 1: API GW method XYZ(stack 1) -> ALambda(stack 2) (this creates an output for ALambda) Version 2: API GW method XYZ(stack 1) -> AnotherLambda(stack 2) (this creates an output for AnotherLambda but “erases” the ALambda output because is not being used, failing at deploy time either way) because it would still point to the old ALambda name

In this example fails in the hypothetical 2nd step.

In the proposal I think the deployment process wouldn’t change at all and we could avoid de deployment problem.

Our specific problem was that we changed the name of a lambda function that was in a stack and was referenced by APIGateway in another stack. Throwing this error:

Export APIStackExampleStack123456:APIStackExampleStackExportsOutputFnGetAttStepFunctionInvokerABE843C6Arn8B082DE7 cannot be deleted as it is in use by APIStack213522BF

Which is clear but that give us a constraint in the pipeline.

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

PS: This wouldn’t go against the design system of CloudFormation because is the same concept the DeletionPolicy.RETAIN resource property have.

This is a 🚀 Feature Request

[jindriago-scf]

@skinny85 made a cool post working this thing around!

https://www.endoflineblog.com/cdk-tips-03-how-to-unblock-cross-stack-references

If your CDK version is grater than 1.90.1 you can do: this.exportValue(bucket.bucketArn); where this is the Stack instance.

[edisongustavo]

I was able to create a workaround, in the same spirit of the proposed workaround at https://github.com/aws/aws-cdk/issues/5819#issuecomment-643821627, but I don’t need the full logical id that CDK generates.

I create a GcStack, which “holds” dummy resources:

from itertools import count
from aws_cdk.core import Resource, CfnResource, App, Stack, Environment

class GcStack(Stack):
    def __init__(self, other_stack: Stack, cdk_environment: Environment):
        app: App = other_stack.node.root
        if not App.is_app(app):
            raise ValueError("The stack doesn't have an App")
        super().__init__(app, "GcStack", env=cdk_environment)
        self.counter = count()

    def register(self, resource: Resource, attribute: str):
        cfn_resource: CfnResource = resource.node.default_child
        CfnResource(
            self,
            f"DummyField{next(self.counter)}",
            type="Custom:Null",
            properties={"foo": cfn_resource.get_att(attribute)},
        )
        CfnResource(
            self,
            f"DummyField{next(self.counter)}",
            type="Custom:Null",
            properties={"foo": cfn_resource.ref},
        )

And then using it:

stack_with_resources = Stack(...)
cdk_environment = Environment(...)

gc_stack = GcStack(
     stack_with_resources,
     cdk_environment=cdk_environment,
 )
 gc_stack.register(
     stack_with_resources.ecr_repository, "Arn"
 )

This creates a stack named GcStack that only contains Custom:Null resources which reference the resources from stack_with_resources. You don’t need to deploy the GcStack, but I think it doesn’t hurt if you deploy it (I haven’t tested though).

With this workaround you can reference resources across many many accounts/environments without having to go through all of the outputs that each account/environment generate.

I hope this helps someone.