Aws-cdk: So many unwanted resources

Created on 10 Apr 2019  路  3Comments  路  Source: aws/aws-cdk

Hi Team,

So I'm trying to utilize CDK in a pretty strict environment (devs not allowed to create security groups, IAM roles + policies) and I'm kinda confused. I don't understand why a simple AutoScaling group is trying to create so many unwanted resources: SNS topic, Python Lambda script, IAM role for the Lambda, but most importantly a brand new security group:

https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts#L227-#L230

It also took me a while to figure out that there is a built-in mechanism to create a Lambda that is subscribed to the ASG life cycles.

https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-ecs/lib/cluster.ts#L167-#L173

While I appreciate a lot of built-in services (like auto fill the ASG user-data with the cluster name) I don't understand why are there so many "secret features". What is the idea behind it?

constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
        super(scope, id, props);

        const vpc = ec2.VpcNetwork.import(this, 'ExistingVpc', {
            vpcId: 'vpc-6esds30a',
            availabilityZones: ['us-west-2c'],
            privateSubnetIds: ['subnet-2fsdf7b7c']
        });

        const asg = new autoscaling.AutoScalingGroup(this, 'PeterDemeAsgTest', {
            instanceType: new ec2.InstanceTypePair(InstanceClass.T2, InstanceSize.Small),
            machineImage: new ec2.AmazonLinuxImage({ generation: ec2.AmazonLinuxGeneration.AmazonLinux2 }),
            role: iam.Role.import(this, 'AppRole', { roleArn: 'arn:aws:iam::274712788788:instance-profile/AppRole' }),
            desiredCapacity: 1,
            vpc
        });

        asg.addSecurityGroup(ec2.SecurityGroup.import(this, '10x', { securityGroupId: 'sg-gjghg'}));

        const cluster = new ecs.Cluster(this, 'Cluster', { clusterName: 'PeterDemeTestCluster',  vpc });

        cluster.addAutoScalingGroup(asg, { taskDrainTimeSeconds: 0 });
    }

I never asked the script to attach more than one security groups to my ASG but it still does. Also, my understanding is that this would create a new security group to every single cluster, but all security groups are exactly the same (outbound rules). I don't get the idea. Moreover, we don't even have a "reference" to these specific security groups because it's hidden in the cluster creation logic.

Most helpful comment

I recommend reading our User Guide, specifically the section on Constructs, to better understand the philosophy behind the CDK.

Each module in the AWS Construct Library includes two types of constructs for each resource: low-level constructs known as an AWS CloudFormation Resource constructs and high-level constructs known as an AWS Construct Library constructs.

Creating the SecurityGroup and the DrainHook are examples of behavior we wish to abstract/simplify for users with our "AWS Construct Library constructs", but in your case, that behavior was unexpected and undesirable. You can achieve your desired infrastructure by "dropping down" to the Resource layer (or L1 as we colloquially describe it) and defining it with raw CloudFormation resources. The API will be more verbose but you have full control over what is provisioned.

See how the AutoScalingGroup high-level construct creates the CfnAutoScalingGroup resource:

https://github.com/awslabs/aws-cdk/blob/b61707896582373c4526129945ddaac20055f313/packages/%40aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts#L272-L292

Based on your feedback, we may wish to re-visit the API of AutoScalingGroup to support users passing in their own security group to avoid creating one for each group.

I'm re-opening this issue in case you want to discuss further. I'm happy to elaborate more if it still isn't clear.

All 3 comments

Nevermind, we'll prolly transition to Terraform.

I recommend reading our User Guide, specifically the section on Constructs, to better understand the philosophy behind the CDK.

Each module in the AWS Construct Library includes two types of constructs for each resource: low-level constructs known as an AWS CloudFormation Resource constructs and high-level constructs known as an AWS Construct Library constructs.

Creating the SecurityGroup and the DrainHook are examples of behavior we wish to abstract/simplify for users with our "AWS Construct Library constructs", but in your case, that behavior was unexpected and undesirable. You can achieve your desired infrastructure by "dropping down" to the Resource layer (or L1 as we colloquially describe it) and defining it with raw CloudFormation resources. The API will be more verbose but you have full control over what is provisioned.

See how the AutoScalingGroup high-level construct creates the CfnAutoScalingGroup resource:

https://github.com/awslabs/aws-cdk/blob/b61707896582373c4526129945ddaac20055f313/packages/%40aws-cdk/aws-autoscaling/lib/auto-scaling-group.ts#L272-L292

Based on your feedback, we may wish to re-visit the API of AutoScalingGroup to support users passing in their own security group to avoid creating one for each group.

I'm re-opening this issue in case you want to discuss further. I'm happy to elaborate more if it still isn't clear.

@sam-goodwin Thanks Sam, it's clear. You can close this issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

markusl picture markusl  路  37Comments

AlexCheema picture AlexCheema  路  32Comments

rclark picture rclark  路  49Comments

juhofriman picture juhofriman  路  33Comments

PygmalionPolymorph picture PygmalionPolymorph  路  53Comments