[ECS] [request]: Expose CapacityProviderReservation at Cluster level without using Capacity Provider
- 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**
We are trying to operate an ECS cluster and can't use CapacityProviders. However the metric explained [here](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) is incredibly valuable. I would love to have it at the entire cluster level so the users have the flexibility to build their own cluster controller.
I know there is [ClusterReservation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-metrics.html#cluster_reservation) metric but it only applies to RUNNING tasks. I want to know the requirement including tasks that aren't placed yet. From my understanding that metric will never be above 100 like the CapProvider metric can be.
**Which service(s) is this request for?**
ECS on EC2
**Are you currently working around this issue?**
Basically we just make sure we have enough overhead on the cluster that tasks can be placed. We would like to run it a little thinner though.
Contributor guide
Research direction
Start by reading the AWS deep-dive on Amazon ECS cluster auto scaling and the ECS CloudWatch metrics documentation linked in the request, especially CapacityProviderReservation and ClusterReservation. Confirm how the requested cluster-level metric should include tasks that are not yet placed and support clusters without capacity providers. Done means the proposed behavior and API or metric surface are clearly defined for ECS on EC2.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100