- Newest
- Most votes
- Most comments
I found a workaround. I created an unmanaged Batch compute environment, which creates an ECS cluster. I then created an ASG (Auto-Scaling Group), and set it as the capacity provider for that cluster.
For the ASG, I set min capacity and desired capacity to 0. I then created an EventBridge rule, that is triggered when the batch job status is changed, and executes a lambda when this happens.
In the lamabda, I increment/decrement the ASG DesiredCapacity property. This results in an instance being created/destroyed when the jobs is submitted/completes.
To get the instances to register with ECS after booting, I updated the launch template with this user data:
#!/bin/bash echo ECS_CLUSTER="name_of_the_ecs_cluster" >> /etc/ecs/ecs.config
To ensure that the scaling down terminates the correct instance, the one with the terminated job, I enabled "instance scale-in protection" for all new instances, and then in the lamabda, before decrementing DesiredCapacity , I disable the instance protection for the container instance associated with the job.
Hello,
I couldn't find a straight forward doc to reduce the latency. One of recommendation from EC2 docs is to configure Warm pool instances so that instances can be launched faster to reduce latency.
Hope this helps!
[1] https://ec2spotworkshops.com/efficient-and-resilient-ec2-auto-scaling/lab1/90-enable-warm-pool.html [2] https://docs.aws.amazon.com/autoscaling/ec2/userguide/examples-warm-pools-aws-cli.html
Relevant content
- asked 2 years ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 3 months ago