[ECS] Why "securityGroups" fromClusterAttributes mandatory ?

[Cloudrage]

When using ECS with EC2 instances (hosts), no pb; but when using Fargate, we don't have any Security Group associated with the container instances registered to the cluster, so why it's needed at the import ?

Reproduction Steps

For example, you create a Cluster in a Stack A :

    const EcsCluster = new ecs.Cluster(this, 'EcsCluster', {
      vpc: vpc,
      clusterName: EcsClusterName,
      containerInsights: true
    });

     const SecurityGroupEcsHost = new ec2.SecurityGroup(this, 'SecurityGroupEcsHost', {
       vpc: vpc,
       allowAllOutbound: true,
       description: 'Security Group for ECS Host'
     });

    AutoScalingGroupEcsHost.addSecurityGroup(SecurityGroupEcsHost);

    EcsCluster.addAutoScalingGroup(AutoScalingGroupEcsHost;

And you want to create an ECS EC2Service in another Stack B :

clusterName: EcsClusterName,
vpc,
securityGroups: [SecurityGroupEcsHost]
});

No pb at this time because on the first Stack, you have provided SGR & ASG resources for Hosts Instances.

What did you expect to happen?

But now, I want to create ECS Fargate resources on the other Stack, and the SGR is created on this one because associated with Fargate Service.

    const EcsClusterFargate = new ecs.Cluster(this, 'EcsClusterFargate ', {
      vpc: vpc,
      clusterName: EcsClusterFargateName,
      containerInsights: true
    });

But in that case, I can't import the dedicated Cluster like that :

const EcsClusterFargate = ecs.Cluster.fromClusterAttributes(this, 'EcsCluster', {
clusterName: EcsClusterFargateName,
vpc
});

So,, why it's mandatory ?
Do I have to attach a fake SGR ?

Environment

• CLI Version : 1.68.0
• Framework Version: 6.14.8
• Node.js Version: v12.15.0
• OS : Linux
• Language (Version): TypeScript

---

This is 🐛 Bug Report

[Cloudrage]

For a workaround, I've provided the Fargate SGR create on the other Stack "B" :

    const SecurityGroupEcsFargate = new ec2.SecurityGroup(this, 'SecurityGroupEcsFargate', {
      vpc: vpc,
      allowAllOutbound: true,
      description: 'Security Group for Fargate'
    });

        const EcsCluster = ecs.Cluster.fromClusterAttributes(this, 'EcsCluster', {
          clusterName: EcsClusterName,
          vpc,
          securityGroups: [SecurityGroupEcsFargate]
        });

Even if the SGR is, not the one associated with the container instances registered to the cluster :
https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs.ClusterAttributes.html

Maybe you can clarify the situation ? ^^

[MrArnoldPalmer]

So, this is required because of the way the Cluster L2 construct is modeled. As detailed in this comment ecs clusters don't actually have security groups. This instances within them do, but if your cluster is purely fargate that isn't a thing.

This causes a couple of weird issues, including this one. I don't see an issue changing this to be an optional property, we just need to make sure we are checking for the presence of an SG on imported clusters wherever they are needed and throwing a nice error if it's not present.

[mimozell]

I'm experiencing the same. It's a very stupid error. If you don't need security groups with aws ecs describe-clusters <clustername> why would you need it here? :(

[tscully49]

We are having the same issue in a different context. In cloudformation, creating a fargate serivice only requires The short name or full Amazon Resource Name (ARN) of the cluster on which to run your service. If you do not specify a cluster, the default cluster is assumed. (from https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html) and I would expect that to have similar behavior here. Instead, for CDK, to create a FargateService construct, I have to find the cluster with this function by passing both the securityGroups and VPC, when it seems a cluster name or ARN should be fine.

[jordie23]

Still a problem in 1.110.

So is the work around to just add a "fake" security group since it doesn't matter at all?

[nacitar]

Still a problem in 1.110.

So is the work around to just add a "fake" security group since it doesn't matter at all?

Seems to work in my tests, just to confirm.

EDIT: But an empty array, as mentioned in the next comment, is better.

[frankwese]

the securityGroups property can contain an empty array

const vpcId = StringParameter.valueFromLookup(this, `/${stage}/VpcId`);
const cluster = ecs.Cluster.fromClusterAttributes(this, 'ImportedCluster', {
      clusterName: cdk.Fn.importValue(`${stage}-ClusterName`),
      vpc: ec2.Vpc.fromLookup(this, 'VPC', { vpcId}),
      securityGroups: [],
    })

[ranma2913]

the securityGroups property can contain an empty array

const vpcId = StringParameter.valueFromLookup(this, `/${stage}/VpcId`);
const cluster = ecs.Cluster.fromClusterAttributes(this, 'ImportedCluster', {
      clusterName: cdk.Fn.importValue(`${stage}-ClusterName`),
      vpc: ec2.Vpc.fromLookup(this, 'VPC', { vpcId}),
      securityGroups: [],
    })

This fixed my lookup issue. Thanks so much!

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[madeline-k]

There is now a fromClusterArn static method that may help with some of the issues mentioned in this thread. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.Cluster.html#static-fromwbrclusterwbrarnscope-id-clusterarn

We can still change securityGroups to be an optional property here. Especially since passing an empty array is accepted. That's not a very nice UX.

[pksinghus]

There is now a fromClusterArn static method that may help with some of the issues mentioned in this thread. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.Cluster.html#static-fromwbrclusterwbrarnscope-id-clusterarn

Doesn't work. I get this Error: vpc is not available for a Cluster imported using fromClusterArn(), please use fromClusterAttributes() instead. . This continues to be a problem.

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