CloudFormation: stacks might become undeployable because replacement breaks resource relationship constraints

[rix0rrr]

The situation

• I have an (ELBv2) Load Balancer, associated to a TargetGroup (indirectly, but still).
• A TargetGroup can only ever be associated with one Load Balancer.
• I've deployed my LoadBalancer with internetFacing = false, and now I want to switch it to internetFacing = true. This change causes replacement of the load balancer.

The problem

For rollbackability, CloudFormation is going to create a new Load Balancer first, and try to associate it with the TargetGroup (which didn't change). This breaks the "Target Group can only ever be associated with one Load Balancer" constraint, and the deployment fails.

This means I can never deploy this update anymore!

The workaround

What needs to happen is that the Target Group gets replaced as well. This will happen if it's logical ID changes, so an easy "enough" workaround is to change its construct ID.

Still, this is not a great experience because:

• It's not obvious to people that this will get them unstuck (anecdata: I got halfway through writing this post before realizing that would have helped me and I work on this tool 😳). The error message certainly doesn't help, and it's going to be hard to catch it and make the toolkit give hints because it's going to be service-specific.
• You might not always control the construct IDs to a degree you'd want, especially when they are further down the construct tree or hidden in abstractions.

The better solution

Resources that have a constraint to other resources should have some way of incorporating the immutable values of the other construct into their own logical ID hash.

That way, we can automatically regenerate the ID of the TargetGroup if something on the LB changes, and cause the replacement that we want to happen.

This is feasible because we have the list of immutable properties in our schema, so we can actually calculate this hash.

Potential downsides

• Might be non-obvious why logical ID changes and replacements happen.
• Would this cause replacement in cases where you wouldn't want this to happen?
• What if our schema isn't correct/up-to-date?

[eladb]

Interesting! What comes to mind is the little "hack" we implemented for API Gateway deployment resources, which use a hash of the APIGW model to invalidate the logical ID of the deployment, so it will be recreated every time the model changes.

The implementation is here, but maybe we can move it to cdk.Resource.

[github-actions]

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