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

basically combining the various tutorials

<https://gist.github.com/maxcan/c10e48ebfe6d9b19e22dc67ab9a41860>

this error is classic:
```   * [WARN] A duplicate Security Group rule was found on (sg-0a0f3c5fc91f75c92). This may be
    a side effect of a now-fixed Terraform issue causing two security groups with
    identical attributes but different source_security_group_ids to overwrite each
    other in the state. See <https://github.com/hashicorp/terraform/pull/2376> for more
    information and instructions for recovery. Error: InvalidPermission.Duplicate: the specified rule "peer: 0.0.0.0/0, TCP, from port: 443, to port: 443, ALLOW" already exists
        status code: 400, request id: 5db2e46f-244c-4009-b179-46ae45b85150```


That's not specific to any of the techs you mentioned initially. That problem generally occurs (for me) when I change the Pulumi name of a security group rule.

Changing the name of a rule means it's a new rule in Pulumi's eyes. It will delete the old rule and create the new one. Unfortunately, it creates the new rule _first_, which causes it to conflict with the old rule.

The way I usually fix this is to comment out the rule that is having its name changed, and run `pulumi up`. This deletes the rule with the old name. You can then put the code back in and run `pulumi up` again, which puts the rule back with the new name.

Try to avoid renaming SG rules (and NACL rules, and probably a few other similar entities), as the process is annoying.

thanks.  I’ve worked through this one.  I guess my point is that it just seems like there is a huge lack of sensible defaults.  what i’m doing is pretty standard, it “smells wrong” that it takes a few hundred lines of configuration

then your trapped with a security group that Pulumi requires you to delete but RDS wont let you delete

RDS is a bit of a pain when it comes to configuration. We have a multi-AZ SQL server instance, and our playbooks list which properties we must change when it's up, which must be changed when it's stopped, and which require turning off multi-AZ in order to change... :sob:

i wonder if some of these issues would go away if i migrated to the awsnative provider off of classic

Good question. The closer you are to the AWS SDKs, the less likely some unassuming convenience code sneaks up and hits you in the back of the head.

so AWS AppRunner was what I was looking for.. would have saved two days of fighting with fargate if i found it monday :shrug:

doing literally the same stuff in our stack, and what i will say is this isn't really on pulumi. Renaming security groups and any of the nitty gritty inside VPCs is tricky. Even in AWS. If it's still in your test stack, just tear it down and recreate it, it's much easier. Plus, when you ask nicely here, people are generally really helpful!