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

+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.

current workaround we are using

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

3 years later and this is still a issue

In our case we have a service which exposes two ports and we want both attached to an ALB listener, one with a listenCondition based on path.

Our workaround looks something like the following:

const asg = new autoscaling.AutoScalingGroup()
const lb = new elbv2.ApplicationLoadBalancer()
const listener = lb.addListener()
const tgREST = new elbv2.ApplicationTargetGroup()
listener.addTargetGroups("RestTarget", {
            targetGroups: [tgREST],
            conditions: [
                elbv2.ListenerCondition.pathPatterns(["/api/*"]),
            ],
            priority: 100,
        });
const tgHTTP = new elbv2.ApplicationTargetGroup()
const ServiceAsg = asg.node.defaultChild as autoscaling.CfnAutoScalingGroup
ServiceAsg.targetGroupArns = [tgREST.targetGroupArn, tgHTTP.targetGroupArn]

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" });