Remove stacksets from an account in reverse order

[Cihl28]

We have a dozen or so stacksets deployed from CfCT upon account creation. These stacksets, in some cases, depend on the presence of resources from earlier stacksets. E.g. boundary policies, KMS keys.

The problem arises when an account is removed/unmanaged, or moved to an OU which have different or fewer stacksets assigned. E.g. prior to decommissioning. This always leads to dependency failures, because it wants to remove the stack instances in the same order in which it placed them.

We've worked around the issue, for now, by placing a lot of "DeletionPolicy: Retain" statements, which allows us to unmanage an account successfully. But that creates another set of already exists failures when you want to add those stacks again later. We basically have to delete those resources manually first.

I'd like it if deleting stacks from an account were to happen in the reverse order as adding them.

Sounds easier said than done i must admit. You'd basically have to keep a list of stacks to remove from each account and handle that separately, or otherwise run through all the stacks again in a second pass from bottom to top for stack removal purposes. The old AWS Landing Zone used a depends_on parameter to keep tabs on what depends on what, so things are done in the right order. But i do like the simplicity of just adding them in the order in which they appear in the manifest. Not sure if that's what makes CfCT faster than ALZ, but i wouldn't be surprised. I'm also not sure what other problems this might cause, but i'd like to see what other perspectives on this there are.

[snebhu3]

@Cihl28 thank you for the feature request and for the context. We have opened an internal backlog to address this.

[RutgerBeyen]

See also https://github.com/aws-solutions/aws-control-tower-customizations/issues/165, raised in June 2023 for the same issue/feature request