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

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 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.

[wheresalice]

@kevinslin are you able to expand upon your workaround please?

What is tgHTTP and how is it created? What associates any of this with a listener?

[wheresalice]

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]

[robertofd1995]

Any update about this? We are also facing the same problem

[markdollan243]

Hello, any news about this issue?

[realugbun]

Bump.

We are having the same issue. Any update?

[klang]

The workaround works, but finding the workaround here, takes work :-)

[azatoth]

So I have been thinking, and I wonder if following diff would be an acceptable/reasonable/valid solution to the problem?

I might have totally missed the underlying problem but it seems to me that in the short term (no API changes) we only need to prevent multiple target groups if setScaleOnRequest() has been used; And I believe that the validate functionality might work here.

diff --git a/packages/@aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts b/packages/@aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts
index 0c5006c29f..d27863b642 100644
--- a/packages/@aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts
+++ b/packages/@aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts
@@ -961,6 +961,7 @@ abstract class AutoScalingGroupBase extends Resource implements IAutoScalingGrou
   public abstract readonly osType: ec2.OperatingSystemType;
   protected albTargetGroup?: elbv2.ApplicationTargetGroup;
   public readonly grantPrincipal: iam.IPrincipal = new iam.UnknownPrincipal({ resource: this });
+  protected hasSetScaleOnRequest: boolean = false;
 
   /**
    * Send a message to either an SQS queue or SNS topic when instances launch or terminate
@@ -1064,6 +1065,7 @@ abstract class AutoScalingGroupBase extends Resource implements IAutoScalingGrou
     });
 
     policy.node.addDependency(this.albTargetGroup.loadBalancerAttached);
+    this.hasSetScaleOnRequest = true;
     return policy;
   }
 
@@ -1363,6 +1365,8 @@ export class AutoScalingGroup extends AutoScalingGroupBase implements
     if (props.requireImdsv2) {
       Aspects.of(this).add(new AutoScalingGroupRequireImdsv2Aspect());
     }
+
+    this.node.addValidation({ validate: () => this.validateTargetGroup() });
   }
 
   /**
@@ -1390,10 +1394,6 @@ export class AutoScalingGroup extends AutoScalingGroupBase implements
    * Attach to ELBv2 Application Target Group
    */
   public attachToApplicationTargetGroup(targetGroup: elbv2.IApplicationTargetGroup): elbv2.LoadBalancerTargetProps {
-    if (this.albTargetGroup !== undefined) {
-      throw new Error('Cannot add AutoScalingGroup to 2nd Target Group');
-    }
-
     this.targetGroupArns.push(targetGroup.targetGroupArn);
     if (targetGroup instanceof elbv2.ApplicationTargetGroup) {
       // Copy onto self if it's a concrete type. We need this for autoscaling
@@ -1740,6 +1740,16 @@ export class AutoScalingGroup extends AutoScalingGroupBase implements
       };
     }
   }
+
+
+  private validateTargetGroup(): string[] {
+    const errors = new Array<string>();
+    if (this.hasSetScaleOnRequest && this.targetGroupArns.length > 1) {
+      errors.push('Cannon use multiple target groups if `setScaleOnRequest()` is being used.');
+    }
+
+    return errors;
+  }
 }
 
 /**
diff --git a/packages/@aws-cdk/aws-autoscaling/test/auto-scaling-group.test.ts b/packages/@aws-cdk/aws-autoscaling/test/auto-scaling-group.test.ts
index c0a979408a..23e576599d 100644
--- a/packages/@aws-cdk/aws-autoscaling/test/auto-scaling-group.test.ts
+++ b/packages/@aws-cdk/aws-autoscaling/test/auto-scaling-group.test.ts
@@ -2,6 +2,7 @@ import { Annotations, Match, Template } from '@aws-cdk/assertions';
 import * as cloudwatch from '@aws-cdk/aws-cloudwatch';
 import * as ec2 from '@aws-cdk/aws-ec2';
 import { AmazonLinuxCpuType, AmazonLinuxGeneration, AmazonLinuxImage, InstanceType, LaunchTemplate } from '@aws-cdk/aws-ec2';
+import { ApplicationLoadBalancer, ApplicationTargetGroup } from '@aws-cdk/aws-elasticloadbalancingv2';
 import * as iam from '@aws-cdk/aws-iam';
 import * as sns from '@aws-cdk/aws-sns';
 import { testDeprecated } from '@aws-cdk/cdk-build-tools';
@@ -1766,6 +1767,43 @@ describe('auto scaling group', () => {
     })).not.toThrow();
 
   });
+
+  test('Should validate multiple target groups i conjunction with `setScaleOnRequest()`', () => {
+    const stack = new cdk.Stack(undefined, 'MyStack', { env: { region: 'us-east-1', account: '1234' } });
+
+
+    const vpc = mockVpc(stack);
+
+    const alb = new ApplicationLoadBalancer(stack, 'alb', {
+      vpc,
+      internetFacing: true,
+    });
+
+    const listener = alb.addListener('Listener', {
+      port: 80,
+      open: true,
+    });
+    const asg = new autoscaling.AutoScalingGroup(stack, 'MyFleet', {
+      instanceType: ec2.InstanceType.of(ec2.InstanceClass.M4, ec2.InstanceSize.MICRO),
+      machineImage: new ec2.AmazonLinuxImage(),
+      vpc,
+    });
+
+    const atg1 = new ApplicationTargetGroup(stack, 'ATG1', { port: 443 });
+    const atg2 = new ApplicationTargetGroup(stack, 'ATG2', { port: 443 });
+
+    listener.addTargetGroups('tgs', { targetGroups: [atg1, atg2] });
+
+    asg.attachToApplicationTargetGroup(atg1);
+    asg.attachToApplicationTargetGroup(atg2);
+
+    expect(asg.node.validate()).toEqual([]);
+
+    asg.scaleOnRequestCount('requests-per-minute', { targetRequestsPerMinute: 60 });
+
+    expect(asg.node.validate()).toContainEqual('Cannon use multiple target groups if `setScaleOnRequest()` is being used.');
+
+  });
 });
 
 function mockVpc(stack: cdk.Stack) {

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[Lee4396]

3 years later and this is still a issue