Problem create another loadbalancer

[grassiricardo]

I'm created one new loadbalancer in my app and I have this error in cloudformation

Resource handler returned message: "Resource of type 'AWS::ElasticLoadBalancingV2::ListenerRule' with identifier 'Priority '50000' is currently in use (Service: ElasticLoadBalancingV2, Status Code: 400, Request ID: 9c306f75-f5a0-4041-81c7-8262c7cd96aa, Extended Request ID: null)' already exists." (RequestToken: f2ef6da0-4ade-f81e-9a83-10415266300b, HandlerErrorCode: AlreadyExists)

How can I create a new loadbalancer I need two loadbalancer in most app

[iamhopaul123]

Hello @grassiricardo. We create one LB per environment and when you deploy your first Load balanced web service to that environment, the LB will be created. So ideally you could have multiple LBs if you have multiple environments.

Could you share us what your architecture looks like? Do you need multiple LBs in one environment instead? Thank you!

[grassiricardo]

@iamhopaul123 I need one LB for my API and other LB for my consumer front-end. I require separate this because I have many requests now in one and unique LB

[iamhopaul123]

Gotcha. So the customer front-end LB would be public to internet whereas I guess the API LB would be an internal one?

Also we are working on supporting Network load balancer, and users would be able to create one ALB per environment but one NLB for each service. I wonder if that could help with your use case.

[iamhopaul123]

Also as for the error you got I think it was because you have two LB services with the same path property (see https://github.com/aws/copilot-cli/issues/1376)

[pcolazurdo]

I've just ran into this problem. I have two front ends on the same environment and they both need to respond on the root (/) path so the only way to achieve this is having two different ALBs one for each front end.

[iamhopaul123]

Hello @pcolazurdo. The requirement for having multiple frontend services on the same environment makes sense to me. However, I'm not sure if it can only be addressed by multiple LBs. Possible workarounds are

1. If you'd like to use different domains for each of your frontend service, for example example.com/ and anotherexample.com/, you could use our new cert import feature so as to import these two domains for your services to use.
2. If it is because you want your service code to only accept / but don't mind to have /svc2 to be the domain path, in svc2 you could have an nginx sidecar to redirect traffic for /svc2 to localhost.

Please let us know if anything is not clear. Thank you for the request!

[pcolazurdo]

Thanks for the feedback. I thought about those workarounds but in my case the backend application needs a different security group attached to it

[iamhopaul123]

That makes sense. I wonder if this can be addressed by importing svc-specific security groups (network.vpc.security_groups). Or do you have any other reason why you want multiple LBs?

[pcolazurdo]

In my case, a second LB will be the preferred option. As one of the targets is a management app, I'd like to be able to have separate logs, waf attachments, security settings and monitoring on the two different apps.

[iamhopaul123]

Agreed! I think in your case having two LB would be a better option. However, it sounds more like these two frontend services should be placed in two different apps to me. Is there any reason why you want them to be kept in the same app same environment?

[pcolazurdo]

I need to think about that. They share common resources (database, sqs, sns) and lifecycle and have the same operation model, so I thought this would make sense to have in the same app and environment, but probably need to re read what the concept of an app is as I may have misunderstood the concept.

[pcolazurdo]

Reviewing the documentation, it makes sense to have both pieces of the application in the same Copilot Application and Environment. They are two microservices endpoints of the same core application, so splitting them in different app just because of the Load Balancer limitation would be an anti-pattern and cause extra costs and complexities (i.e. setting VPC peering between both environments to be able to connect to shared backend)

[iamhopaul123]

That's correct. If the backend services for both frontend services need to talk with each other then you would need VPC peering which is impossible for now and expensive. Thank you again for sharing your insights and use cases for this feature request!

[grassiricardo]

In this case, I'm created in different paths. /myproject and other in /v1/myproject. That's correct, this approach. For me, closed this issue.