This message was deleted.

Hi @high-wire-68732. A couple of things to keep in mind that might be helpful here. I know this is delayed but it may still help others. 1. You're using the

awsx

library as opposed to the

aws

library. The

awsx

library does a lot of stuff automatically under the hood. So, if you don't specficy any security group configuration, it's going to automatically assign them for you and create the appropriate rules. The documentation covers some of it, and some of it you may have to discover from poking around in the source code. 2. I've had this "duplicate Security Group" problem before. Typcically it's happened when a build times out or fails and the project gets stuck in a weird state. If Pulumi already creates the Security Group and then the build crashes, it may not know to delete it. If it doesn't delete it, then you run into this duplicate issue. To fix this, you can go into the AWS console and manually delete the particular security group rule from the Security Group that's associated with your service. Once you do that, run

pulumi refresh

and that will sync your Pulumi project up with whatever resources that it actually finds in AWS. Then try deploying again.

Hi @able-zoo-58396, it was neither of the cases you pointed out, we actually started by specifying a security group, it would still give the same error, and the second case we hand no orphaned security groups There is a bug in

awsx

where it tries to generate security groups for all the ingress definitions for the listener rules, in my case I do need multiple listener rules pointing to the same port because they route differently depending on different paths, and as you mention, since

awxs

library does this setup automatically, it should take into account the need for the ability to have multiple listener rules pointing to the same port With the previous understood, you might see the problem when I point you to the code generating this issue: https://github.com/pulumi/pulumi-awsx/blob/master/nodejs/awsx/lb/application.ts#L244-L248 There is no check to make sure whether a security group with the same ingress/egress definitons had been created before in that loop or not, quite an oversight, so much so that, for now, our workaround has been to comment out the aforementioned lines in the

awsx

module installed within our

node_modules

directory I have reported this on this issue: https://github.com/pulumi/pulumi-awsx/issues/293 No reply from the pulumi team yet, although it seems this awful workaround has already helped someone else out Really hope the issue actually gets resolved soon, it's still very concerning for my team that our company is using a tool that would leave such an easy to fix yet aggravating issue open for so long, and I'm the one responding for the decision of using Pulumi in the first place 😕

Hi @high-wire-68732. I understand now, and I share your frustration with the

awsx

limitations. In my experience, using the

awsx

library comes with many trade-offs. It's an opinioned library that seems to only work well certain configurations. It's generally not very flexible if you want to do something custom. In your case, since you're mixing in existing security groups, this might fall into that custom category. Whenever possible, I try to use the

aws

library directly, because it's far less opinionated. In your case, it may be possible to use the

awsx

library to create the initial listener groups, and then use the

aws

library to attach the additional listener rules. The pattern that I use in cases like this is to create the resources with

awsx

and then read the reference to the created resources after that. Something like this:

const loadBalancer = new awsx.elasticloadbalancingv2.ApplicationLoadBalancer('lb', { cluster.securityGroups })

// ... create a target group and listener that point to port 8000 (for example) ... 

// Then you can references the loadBalancer to add your second listeners using the plain "aws" library:
const newTargetGroup = new aws.lb.TargetGroup("frontEndTargetGroup", {});

new aws.lb.Listener("frontEndListener", {
    loadBalancerArn: loadBalancer.arn,
    port: 8000,
    defaultActions: [{
        type: "forward",
        targetGroupArn: newTargetGroup.arn,
    }]
})

The plain

aws

library won't try to create any additional resources automatically.

We did try a combo of aws and awsx but it was failing at different points, so we tried to keep it all under awsx. With that said, given that this is such an specific case that we have good understanding of, I think we can try and give it another go with what you are suggesting here @able-zoo-58396

@high-wire-68732 the example here breaks down setting up the load balancer and listeners without awsx, so it won't auto-create those security group rules: https://www.pulumi.com/docs/reference/pkg/aws/alb/listener/