[Fargate] [Task Resources]: Allow smaller CPU/Memory configurations

[idubinskiy]

Tell us about your request Allow lower CPU and Memory resource allocation for Fargate tasks.

Which service(s) is this request for? Fargate

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Fargate is very appealing because it removes the requirement to run Container Instances. However, we have a lot of microservices whose CPU and Memory requirements are lower than the minimums allowed on Fargate. Fargate is already more expensive than running on-demand instances of families like m5 and c5 with equivalent vCPU and Memory configurations. For tasks that require less than 0.25 vCPU and 0.5GB Memory, the cost is even higher compared to running those tasks binpacked with others on an ECS Container Instance.

Are you currently working around this issue? We're using ECS with the EC2 launch type.

[aapjeisbaas]

I would love to have smaller containers, I have an interesting use case with lightweight http proxies and 128MB of RAM with 64CPU would be plenty in my setup. ref: https://gitlab.com/nsi-public/s3-proxy

We now run them on ecs on ec2 or fargate RAM:512 CPU:256

[fed135]

Resurrecting this thread.

Having a smaller configuration will definitely benefit Node.js users.

Garbage collection in Node.js becomes increasingly long and frequent the higher the memory, causing pretty bad performance impact. Node itself will crash by default beyond ~1.65gb. So it's recommended that individual processes do not exceed 512mb of memory, with even lower values encouraged.

Default CPU usage for standard APIs (orchestration, database interface, proxying, etc) is also rather low, idling at <0.1% of the current smallest Fargate instance (RAM:512 CPU:256)

Having the possibility of setting .125 CPU and 128 MB of RAM would reduce our costs and make our horizontal scaling policies more responsive.

[nazreen]

this is very needed. we have a service running on Fargate but the max CPU usage ever is only 25% and the cost of running this service doesn't really add up for us that we might switch to EC2 launch type instead. would prefer to stay with Fargate if only it allows lower CPU/Memory configs.

[rajp33]

Bump any updates on this?

[fishnix]

💯 👍

We're running a bunch of very small microservices that require much less than the current minimum... 128MB RAM would probably be more than enough.

[malcolmmackay]

I have just converted my web application to Fargate. It took several days of a holiday to do. The service has very low CPU and memory use, but I need to run a few of them with different software versions. I thought the "pay for what you use" Fargate model would work well. It does not. Whilst each service uses <<0.25vCPU and <1GB of RAM, I have to pay for the resources anyway. This could have been made clearer.

Now, to reduce costs, I have to convert my work from Fargate to a T3 nano instance or similar. Not a positive experience. Whilst I think AWS is cool, I feel led up the garden path on this one.

[mreferre]

@malcolmmackay I am sorry for the experience. We are trying to clarify that the model isn't "pay per what you use" but rather "pay for what you size". Was there a specific place (doc, blog etc) that was particularly misleading to you? We would like to fix that. Thanks.

[ArnoldKell]

Our team could use this as well. We have a bunch of microservices that use 128MB of memory and even less. While I understand if this is not possible due to some restriction such as the one with Elastic Network Interfaces (which are limited per instance), we would like to know if this is something that we can hope to see in the future.

[redterror]

My team has a bunch of jobs at the 32MB of RAM level. Our particular use case is in long running diagnostics poking at our services; these jobs simulate IoT hardware, so they're tiny. For us moving to fargate is desirable but the cost increase is prohibitive due to the minimum memory of a fargate task.

[mreferre]

@ArnoldKell @redterror all I can say is that this is something we are aware of and the requirement is understood. There is work that needs to be done to make this happen but we are definitely not discounting the need.

[EvertonMJunior]

Would be awesome if this was possible for me as well. Currently running multiple microservices, and even one big API at Fargate and the charts are sad.

[mreferre]

Hi @EvertonMJunior. Thanks for the data point. What type of application is the one whose metrics you posted above (language? type of app? etc). Also, how does the CPU profile (configured Vs utilized) looks like for that app? Thanks.

[EvertonMJunior]

Hi @EvertonMJunior. Thanks for the data point. What type of application is the one whose metrics you posted above (language? type of app? etc). Also, how does the CPU profile (configured Vs utilized) looks like for that app? Thanks.

Hey @mreferre, you're welcome. The application on display is an Express server written in Typescript, running on docker containers. It's the main backend service for an education app, mostly text data goes through it from and to the PostgreSQL db. All the images, videos and audio that circulates are directly uploaded and download from S3, so there's no impact on the Express server.

Below is the CPU profile for the app as well. Based on the low average and occasional peaks, a burstable EC2 environment is working better right now, we migrated to an EC2-based ECS to utilize better the resources. We tried Fargate for the better autoscaling capacities, but this made it costly to use it.

Thanks!

[mreferre]

@EvertonMJunior fantastic feedback, very insightful. I will say that coming in with utilization graphs you raised the bar on feedback quality. I'd buy you a beer if I could! Thanks!

[EvertonMJunior]

@mreferre awesome, I feel flattered about that hahaha, couldn't live without having dashboards about everything on CloudWatch. Thank you as well!

[rinogo]

Subscribing for updates on this. I think copilot with Fargate ECS is an absolute game changer, but the minimum size resource reservations are still unnecessarily large for many uses, leading to wasted resources and higher-than-necessary costs.

There's enough value for us at the current price point that we're not planning on migrating to a different configuration. However, lowering the "minimum size" would help accelerate copilot/Fargate adoption and open up more use cases.

[David-Development]

Another real world example showing that often more CPU Power is needed with little RAM usage. One of our production services is running ~150 Containers (in 8vCPU / 16GB) - we're blocking Terrabytes of RAM that we are not using. The service is a WebServer (written in Go). Would be great to choose a better CPU/RAM ratio as most of my previous comments mentioned. Our diagrams for that particular service:

[maticomp]

I add a watch on this one also, as we also have quite a bunch of ECS Fargate tasks that are CPU-bound but with very little memory usage. We end up having a dozen of 2vCPU/4GB memory task combos, where the CPU is pretty much utilized as we intend to, but memory never hits more than 512MB of use.

I used to workaround this by running multiple containers in a single task definition, but this impacts the observability and ability to scale independently, so is more like a hack than a solution. I try not to use that unless for precise cost management requirements.

It would be very cool to see looser CPU/mem coupling in Fargate in general, or at least a compute-optimized/memory-optimized variants available.

Looking forward to this being put on the roadmap sometime!

[shaaza]

+1 here. The inability to right size workloads forced us to use ECS on EC2 for a use case where we're running lightweight workloads on behalf of our users, but if we could do ECS Fargate with e.g. 0.125 CPU, it would massively simplify our experience!