[ECS] [Fargate]: Expose Firecracker MicroVM Snapshots to AWS Fargate Tasks
- 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**
> What do you want us to build?
I would like to request the addition of snapshot capabilities to AWS Fargate, enabling the ability to pause and resume containers. This feature would leverage Firecracker microVM snapshots, similar to what I believe AWS App Runner utilizes to transition containers between provisioned (memory-only) and active (memory and vCPU) states.
If AWS App Runner is using Firecracker microVM snapshots to efficiently manage container states, this functionality suggests that it should be feasible to extend similar capabilities directly to Fargate tasks, given that App Runner operates on Fargate.
> **Which service(s) is this request for?**
> This could be Fargate, ECS, EKS, ECR
Fargate
> **Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
> What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
Currently, the only way to save on costs with a Fargate task is to set the desired task count to 0. While you can resume the task by setting the desired count back to 1, the restart time is too long to effectively serve web requests.
**Goals:**
* Resource Optimization: Pause idle tasks to free up CPU resources while maintaining their state for quick resumption.
* Cost Efficiency: Minimize operational costs by reducing resource usage for inactive tasks.
* Improved Management: Simplify task lifecycle management with seamless pause and resume capabilities.
Providing an API to pause and resume tasks within a cluster would significantly enhance Fargate's flexibility and resource efficiency. Specifically, when a task is paused, it should:
* Take a snapshot of the container's memory and store it on disk.
* Retain the same networking configuration (IP address, ENI, etc.) and ephemeral storage as it had when launched.
**A task could be paused:**
* Manually via an API, SDK, or CLI
* Internally from a container calling an endpoint similar to the [ECS metadata endpoint](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4.html)
**A task could be resumed:**
* Manually via an API, SDK, or CLI
* When it receives network traffic on the Host Port
> **Are you currently working around this issue?**
> How are you currently solving this problem?
* Pause: Set desired task count to 0, Resume: Set desired task count to 1. By the time the task is ready (> 1 minute) the web requests fail
Other service options:
* Use Lambda, but it doesn't fit my use case very well where I need a long lived processes that can handle many requests concurrently.
* Use App Runner, but it is very limited compared to Fargate (storage, memory/vCPU options, price)
* Use a different cloud provider/service like Google Cloud Run
> **Additional context**
> Anything else we should know?
Many users have requested a "Scale to Zero" feature for Fargate and App Runner for many years. I'm not sure if this aligns with the current service goals or technical capabilities, but I believe implementing a feature similar to AWS App Runner's provisioned containers would be the next best alternative.
* https://github.com/aws/containers-roadmap/issues/1017
* https://github.com/aws/apprunner-roadmap/issues/9
Contributor guide
Assessment
This issue has not been assessed yet.