Aws-cdk: Cannot add AutoScalingGroup to more than one Target Group

[KingOfPoptart]

When attempting to assign an ASG to multiple target groups, CDK errors out with Cannot add AutoScalingGroup to 2nd Target Group

CFN supports passing in a list of Target Group ARNs to an autoscaling group - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html#cfn-as-group-targetgrouparns

Use Case

This feature is necessary if anybody would like to assign multiple load balancers to an ASG

Proposed Solution

Remove the check here - https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts#L559

Figure out any other functions that are effected and come up with workarounds. Rico thinks there could be issues with scaleOnRequestCount()

Other

• [ ] :wave: I may be able to implement this feature request
• [ ] :warning: This feature might incur a breaking change

---

This is a :rocket: Feature Request

[icecold21]

+1 on this, my use case is I would like to add listener for both http and https, but point them to the same autoscaling group.

[hikeeba]

This issue is causing us problems as well. We need an ASG to be attached multiple times to a target group because of multiple applications running on our instances with different ports and domains.

[manikandanmsairam]

+1 We have a usecase where the application has to be exposed both internally and to Internet. Internet facing load balancer will be restricted to CloudFront IPs and internal load balancer will be accessed by another application for flushing. Hence we need to attach the same target group into internal load balancer and internet facing load balancer.

[kevinslin]

current workaround we are using

...
const cfnAsg = asg.node.defaultChild as CfnAutoScalingGroup;
cfnAsg.targetGroupArns = [tgHTTP.targetGroupArn, tgHTTPS.targetGroupArn];

[trevordilley]

Definitely would love to have this resolved unless their is a more idiomatic way to handle HTTP -> HTTPS redirects, thanks!

[rbobrowicz]

Ran into this issue today as well. As far as I can tell the only reason this limitation is there is because scaleOnRequestCount() is hard coded to only work with one target group. Which is an unnecessary limitation as well, since you can have a scaling policy per target group.

Unfortunately, I'm not sure how to fix this. The real fix would be a change to scaleOnRequestCount() to take a target group as an argument, but that will cause an API breakage.

The only other path I see would be to have scaleOnRequestCount() only work with the first target group attached, as it does now, but still allow other target groups to be attached. This is rather crummy API, and still limits scaling policies, but it would at least be a step forward.

I'm willing to work on a patch for this, since this a pretty big issue for us, but I would need some guidance from the maintainers on how to proceed and what they think an acceptable solution looks like.

@trevordilley You shouldn't need multiple target groups to handle an HTTP to HTTPS redirect, that can be handled with a listener on the ALB:

const alb = new ApplicationLoadBalancer(this, 'alb', { ...your props...});
const listener = new ApplicationListener(this, 'httplistener', { port: 80, loadBalancer: alb });
listener.addRedirectResponse("redirect", { protocol: "HTTPS", port: "443", statusCode: "HTTP_301" });

[thedevopsguyblog]

+1 I have run into this issue.
I need to point multiple target groups to a single fleet running some containers on multiple ports.

[antonfelich]

+1 we use Octopus to push multiple applications to a single box running on different ports. Would be nice to attach multiple target groups to a single asg without resorting to a "hack".

Gold star for @kevinslin his workaround has sorted me out for now.