(aws-batch): ComputeEnvironment should implement IConnectable

[yoshizawa56]

Describe the feature

Once a ComputeEnvironment is created, there is no way to access the security group associated with it. We would like to implement IConectable interface in the ComputeEnvironment to more easily control connections from the batch container.

Use Case

Current implementation requires 3 steps below when creating batch with db connection.

1. create a security group
2. create the computing resource and associate with the security group created in 1.
3. run db.connections.allowFrom(sg, ...)

If ComputeEnvironment implements IConnectable, it become more simple

1. create computing environment without explicit security group association
2. run db.connections.allowFrom(computeEnv, ...)

Proposed Solution

No response

Other Information

No response

Acknowledgements

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

CDK version used

2.24

Environment details (OS name and version, etc.)

ubuntu 18.04

[tcutts]

I encountered this issue when working on a PoC for a customer.
In my case I was adding EFS volumes to the container definitions. The EFS filesystem needs to have appropriate connection changes to allow batch containers to access the filesystem. I found myself having to do this to get connectivity:

declare const fs: efs.FileSystem;

fs.connections.allowDefaultPortFromAnyIpv4();

which is clearly very bad practice, even if it's all in a private subnet. The security groups which which the Batch construct creates for each ComputeEnvironment need to be available, so I agree that ComputeEnvironment needs to implement IConnectable. I have implemented this, in a way which does not seem to have added any integration problems. I also added an integration test, but I'm not 💯 % comfortable this is the right design, it's not quite high level enough to make this really suitable for the user.

For a start, the computeEnvironments are not exposed by the JobQueue that contains them, so with my implementation the user still has to create the environments themselves and alter them before creating the batch queue as follows, which seems a bit cumbersome:

const computeEnvironments = [
  {
    computeEnvironment: new batch.ComputeEnvironment(stack, 'batch-demand-compute-env-launch-template', {
      managed: true,
      computeResources: {
        type: batch.ComputeResourceType.ON_DEMAND,
        vpc,
        launchTemplate: {
          launchTemplateName: launchTemplate.launchTemplateName as string,
        },
      },
    }),
    order: 2,
  },
  {
    computeEnvironment: new batch.ComputeEnvironment(stack, 'batch-spot-compute-env', {
      managed: true,
      computeResources: {
        type: batch.ComputeResourceType.SPOT,
        vpc,
        bidPercentage: 80,
      },
    }),
    order: 3,
  },
];

// at least with ComputeEnvironment implementing IConnectable, we now have sensible ingress rules:
computeEnvironments.forEach((ce) => {
  fs.connections.allowDefaultPortFrom(ce.computeEnvironment);
});

new batch.JobQueue(stack, 'batch-job-queue', { computeEnvironments });

I'll link a pull request to this issue, to show what I've done, although I'm not expecting it to be the final design that gets merged, more that it's food for thought about how this could be implemented.

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