You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tell us about your request
I'd like to see the coupling between CPU and memory in Fargate task resource allocations loosened or removed. In case there's any doubt, I mean the minimum number of vCPUs allocated for a given memory allocation, or the minimum memory allocated for a given number of vCPUs.
This is similar to #79 but more related to the balance between CPU and memory than the minimum values.
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?
Currently if you have a task that requires 8 GB of memory but has low CPU requirements, the minimum CPU allocation is 1.0 vCPUs.; or you may have a task that warrants 4.0 vCPUs but needs only a small fraction of the 8 GB of memory that is the minimum you may allocate to such a task. In either case you must over-provision either CPU or memory resources to satisfy the resource constraints of the task.
In our specific case we are skewed heavily towards higher memory usage. If we host ECS on our own EC2 instances then by choosing R-series instance types we can gain a lot of efficiency. I'd like to see a similar degree of flexibility in Fargate task resource allocations as we have in EC2 instance types.
The recent price drops for Fargate tasks (which are very welcome!) have made this even more significant for memory-skewed tasks since even with the minimum CPU allocation, a Fargate task is now billed much higher for its CPU resources than its memory resources. The pricing examples on the pricing page appear to be out of date as I write this, incidentally.
Are you currently working around this issue?
We host ECS on our own EC2 instances, using R5 instance types.
The text was updated successfully, but these errors were encountered:
+1 to this - we're in the situation where our main services require a reasonable amount of CPU allocation for handling high load, but really don't need much memory due to the nature of the language we're using (Swift). It would be great if we could do something like 4.0 CPUs and 256 memory
Tell us about your request
I'd like to see the coupling between CPU and memory in Fargate task resource allocations loosened or removed. In case there's any doubt, I mean the minimum number of vCPUs allocated for a given memory allocation, or the minimum memory allocated for a given number of vCPUs.
This is similar to #79 but more related to the balance between CPU and memory than the minimum values.
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?
Currently if you have a task that requires 8 GB of memory but has low CPU requirements, the minimum CPU allocation is 1.0 vCPUs.; or you may have a task that warrants 4.0 vCPUs but needs only a small fraction of the 8 GB of memory that is the minimum you may allocate to such a task. In either case you must over-provision either CPU or memory resources to satisfy the resource constraints of the task.
In our specific case we are skewed heavily towards higher memory usage. If we host ECS on our own EC2 instances then by choosing R-series instance types we can gain a lot of efficiency. I'd like to see a similar degree of flexibility in Fargate task resource allocations as we have in EC2 instance types.
The recent price drops for Fargate tasks (which are very welcome!) have made this even more significant for memory-skewed tasks since even with the minimum CPU allocation, a Fargate task is now billed much higher for its CPU resources than its memory resources. The pricing examples on the pricing page appear to be out of date as I write this, incidentally.
Are you currently working around this issue?
We host ECS on our own EC2 instances, using R5 instance types.
The text was updated successfully, but these errors were encountered: