No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

I don't think this will work and I think you should be using `aws.ec2.SecurityGroupRule` to add rules to an `aws.ec2.SecurityGroup` that you have already declared

Okay, thanks - you've saved me another N days of bashing my head :slightly_smiling_face:

yes, to clarify on what Joshua said, the SecurityGroup API call used here is immutable, so if you make changed it'll delete/replace. If you use securitygroup rule it can be updated without impact

My team is coming from CDK - is it safe to say that most "mutations" of pre-existing resources are done by declaring new, additional resources (sort of like PolicyRoleAttachment in IAM?)

btw, would love to get some feedback and thoughts about the migration when you're happy to chat about it!

You're probably already hearing from us, somebody else on my team had a video call with somebody at pulumi yesterday :slightly_smiling_face:

I know you chatted with Cam and Robby yesterday, but would love to chat with you about your experience with CDK and Pulumi when you get chance! lmk if you're open to it!

My personal experience with CDK consists of moving away from it :joy: That being said, it seems like there is a bit more "magic" in CDK than Pulumi, which has made Pulumi much more comprehensible (for me, at least).

One ask is: If these fields are genuinely immutable, could we remove the @property setters on them (or at least document that they're for internal use only?)