[ECS] [request]: Don't always pick the largest instance configured when determining CAS scaling
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
Currently when CAS is determining how many instances it needs to launch, it picks the largest configured instance type in the auto scaling group's launch template. Would like it to either pick the smallest or most likely to be launched (based on ASG configuration) type instead. Perhaps even let users configure which method of selection to use.
**Which service(s) is this request for?**
ECS cluster auto scaling
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Trying to run jobs on an ASG using spot instances while still maintaining high availability. Best practices for using spot instances dictate having several different instance types available to ensure higher chance of stable spot capacity; however, if the instance types are different sizes, then the scaling algorithm will be impacted.
**Are you currently working around this issue?**
Only using instance types that have the same memory and cpu. This keeps the scaling happy, but results in more spot failures.
Contributor guide
Research direction
Start by reviewing ECS cluster auto scaling and how it determines the instance type used for capacity calculations. Compare the requested smallest, most-likely, and user-configured selection approaches against ASG configurations with varied spot instance types. Done means the selection behavior is defined and the scaling impact of mixed instance sizes is addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100