- Why ECS is the exception on memory
- Fargate is where the reservation is the bill
- Both dimensions have to be slack
- What counts as enough evidence
- Sizing a Fargate task correctly
- Applying it
- Frequently asked questions
On ECS, the instance type is rarely the problem. The problem is the gap between what a task reserves and what it uses. A task holding 2048 CPU units and peaking at 180 is keeping 91% of its reservation away from everything else, and on Fargate you are billed for the reservation whether or not anything touches it.
This is also the one place in an AWS account where a memory recommendation can be honest, which is worth explaining because everywhere else it cannot.
Why ECS is the exception on memory
For EC2, memory utilization is unavailable. The hypervisor cannot see inside the guest operating system, so unless you have installed the CloudWatch Agent, nobody knows how much memory an instance is using. Any rightsizing advice that quotes your memory headroom is inventing it. That constraint is covered in the rightsizing comparison.
ECS is different because the ECS agent reports MemoryUtilized and MemoryReserved to Container Insights by itself. There is nothing to install inside the container. So a memory-based recommendation for an ECS service rests on measurement rather than inference, and it is the only place in this analysis where cutting memory can be recommended with real evidence behind it.
Container Insights is not free. It is billed per metric, so enabling it across a large cluster is a trade rather than a pure win. It is also the only way to size ECS tasks from measurement instead of guesswork, and the cost of a small metrics bill is usually far less than the cost of tasks reserving three times what they use.
Fargate is where the reservation is the bill
The economics differ sharply by launch type, and the difference determines whether over-reservation costs you money or costs you capacity.
On Fargate, the reservation is the invoice. You are billed for the vCPU and memory the task definition asks for, per second, regardless of use. A task reserving 2 vCPU and using 0.2 is billed for 2. Lowering the reservation lowers the bill directly, and the saving is computable from published rates.
On EC2 launch type, the reservation is a scheduling constraint. You pay for the container instances in the cluster, not for what tasks reserve. An over-reserving task does not add to the bill by itself; it consumes room on a host, so fewer tasks fit, so the cluster scales out sooner than it needed to. The cost is real but indirect, and it depends on how the cluster's capacity provider is configured.
That difference is why a finding for a Fargate service carries a dollar figure and a finding for an EC2-launch-type service does not. The waste is real in both cases. Only one of them can be priced without inventing a model of your cluster's scaling behaviour.
Both dimensions have to be slack
This is the guard that stops a plausible-looking recommendation from killing a service.
A task using 20% of its CPU looks obviously oversized. If that same task is using 85% of its memory, it is not oversized at all: it is a memory-bound workload that happens not to need much CPU. Fargate ties CPU and memory together in a fixed set of valid combinations, so shrinking the CPU allocation drags the available memory down with it, and the task starts being killed for running out of memory.
So a cut is only recommended when both CPU and memory sit below the headroom ceiling. If either dimension is close to its reservation, the service is correctly sized on that dimension and the finding is not emitted at all. The ceiling is 70%, the same figure used across the rest of the analysis, leaving roughly 30% headroom above the worst peak observed.
Where memory was not reported by Container Insights for a particular service, the finding says exactly that rather than defaulting the value or quietly proceeding on CPU alone.
What counts as enough evidence
Three guards, all of them about not judging a service from too little data.
A minimum sample count. At least 24 datapoints, so a service is not assessed from the handful of metrics left behind by a deployment that ran for twenty minutes.
A confidence window. The same 7, 15, 30, 60 and 90 day bands used elsewhere, where the short windows produce an observation and are structurally incapable of producing a resize instruction. A batch service that runs hard once a month looks idle for 29 days out of 30.
Peaks, never averages. The measurement is the peak over the window, because the average of a service that is idle most of the time and saturated at month end describes neither state. The recommendation quotes the peak, the reservation and the resulting percentage, so you can check the arithmetic.
Sizing a Fargate task correctly
Fargate does not accept arbitrary CPU and memory values. Each CPU size permits a specific range of memory, so a downsize has to land on a combination that actually exists.
| Task CPU | Valid memory range |
|---|---|
| 256 (.25 vCPU) | 512 MB, 1 GB, 2 GB |
| 512 (.5 vCPU) | 1 GB to 4 GB, in 1 GB steps |
| 1024 (1 vCPU) | 2 GB to 8 GB, in 1 GB steps |
| 2048 (2 vCPU) | 4 GB to 16 GB, in 1 GB steps |
| 4096 (4 vCPU) | 8 GB to 30 GB, in 1 GB steps |
Because of that coupling, the target has to be chosen as a pair rather than by scaling each dimension independently. A recommendation that proposes 512 CPU with 8 GB of memory is not a size Fargate will accept, and finding that out at deploy time is a poor way to learn it. The analysis proposes an actual valid pair that keeps both peaks under the ceiling, so the numbers can go straight into the task definition.
Applying it
Change the cpu and memory values in the task definition and redeploy. There is nothing to migrate and no data to move; a new revision is registered and the service rolls onto it.
Two things worth doing around that.
Step down rather than jumping to the computed minimum. The peak is the worst thing that happened in the observation window, not the worst thing that can happen. Moving in one step to a size that just clears the historical peak leaves no room for a load pattern the window did not contain.
Watch the first month-end after the change. Month-end is when the load pattern most often differs from everything the window observed, and it is the most common time for a downsize to turn out to be too aggressive.
Where both AWS Compute Optimizer and this analysis produce a finding for the same Fargate service, they are deduplicated on resource type, resource ID and region, keeping the larger saving so the total is never counted twice.
Frequently asked questions
Why is ECS the only place a memory rightsizing recommendation is trustworthy?
Because the ECS agent reports MemoryUtilized and MemoryReserved to Container Insights by itself, with nothing to install inside the container. For EC2 instances the hypervisor cannot see inside the guest operating system, so memory utilization is unavailable without the CloudWatch Agent and any stated memory headroom is inferred rather than measured.
Does over-reserving an ECS task cost money on EC2 launch type?
Indirectly. On EC2 launch type you pay for the container instances in the cluster rather than for what tasks reserve, so an over-reserving task consumes room on a host, fewer tasks fit, and the cluster scales out sooner than it needed to. On Fargate the reservation is the invoice directly, billed per second for the vCPU and memory the task definition asks for regardless of use.
Why do some ECS findings have no dollar figure?
Because only the Fargate case can be priced from published rates. On EC2 launch type the cost of over-reservation depends on how the cluster's capacity provider scales, and putting a number on that would mean inventing a model of your cluster's behaviour. The waste is real in both cases; only one is computable.
Can I shrink an ECS task that uses very little CPU?
Only if its memory is also slack. Fargate ties CPU and memory together in a fixed set of valid combinations, so reducing the CPU allocation drags the available memory down with it. A task at 20 percent CPU and 85 percent memory is correctly sized for memory, and shrinking it will get the task killed for running out of memory.
What CPU and memory combinations does Fargate allow?
Each CPU size permits a specific memory range: 256 CPU allows 512 MB, 1 GB or 2 GB; 512 allows 1 to 4 GB; 1024 allows 2 to 8 GB; 2048 allows 4 to 16 GB; 4096 allows 8 to 30 GB, in 1 GB steps. A downsize has to land on a pair that exists, so the two dimensions cannot be scaled independently.
Is Container Insights worth enabling?
It is billed per metric, so across a large cluster it is a trade rather than a free win. It is also the only way to size ECS tasks from measurement instead of guesswork, and the metrics bill is usually far smaller than the cost of tasks reserving several times what they use.
How much observation is needed before resizing an ECS service?
At least 24 datapoints so a service is not judged from the metrics left by a twenty-minute deployment, and at least 30 days of window before a resize instruction rather than an observation. Measurement uses peaks rather than averages, because the average of a service that is idle most of the month and saturated at month end describes neither state.