This message was deleted.

Dependencies between infrastructure pieces are always hard. I would probably use https://www.pulumi.com/docs/intro/concepts/resources/options/retainondelete/ to keep the old cert. The dependent stacks will eventually use the new certificate. The old certs can be deleted by a Lambda that's triggered by Cloudwatch Scheduled events (filtered by "in use"=no).

That sounds viable, thanks @fierce-ability-58936!

Our solution is to not share certificates, and to define them in the stack where they're used. But in general, having to support a being-phased-out resource and a being-phased-in resource probably means having two resources in code...

Yeah, was thinking about that aproach too. The same holds for e.g. security groups etc. I guess. These are all free resources so it doesn't really matter, but I can imagine there are non-free resources where I'd like to save a bit by managing them in a shared stack.

Security groups can usually avoid this. They should be defined in the same functional component as uses / provides them. You can add or change rules to SGs without a problem, you don't need extra ones. You should avoid creating extra ones when possible, as most resources that can have SGs attached are limited to 5 SGs.