Right-size ECS tasks and Fargate services

Most cloud bills are usage-based — you pay for what you consume. Fargate is subtly different and it catches finance teams out: you pay for what engineering asked for when they defined the container, regardless of how little the container actually uses. If a team requested a large container and the workload only touches a fraction of it, the bill reflects the large request, every hour, forever, until someone changes the definition.

This makes the Fargate line on the invoice deceptively sticky. It doesn't fall when traffic falls; it only falls when an engineer registers a smaller task definition. And because the over-request is multiplied by the number of running copies of the service (a service can run anywhere from one to dozens of identical tasks), a single oversized definition can quietly become one of the larger lines in the container spend without anyone noticing — there's no spike, just a flat number that's twice what it should be.

For budgeting and forecasting this matters in two ways. First, container spend that's set by request rather than usage won't self-correct, so it has to be actively reviewed. Second, the right metric isn't dollars in isolation — it's the gap between requested capacity and used capacity, often called utilisation. A service running at 15% CPU utilisation is the budget equivalent of a half-empty truck on every delivery. The question to bring to the monthly cost review is: across our container services, what's the average requested-vs-used ratio, and which services are furthest from a healthy number?

Priya is the finance partner embedded with the platform team at a logistics company. At the monthly cost review the container line is flat at around $4.3k for one service, and Priya asks the question that's now standard on the agenda: "What utilisation is that service running at — how much of what we're paying for is it actually using?" The engineering lead pulls up Container Insights: about an eighth, roughly 12% on CPU and 16% on memory.

The conversation isn't technical. Priya doesn't ask about task definitions or vCPU grids. She asks three things: is this driven by real traffic or by a request set once and forgotten, what would a sensible utilisation target look like, and when can it be reviewed. The answer is clear — it's an over-request, the team is comfortable targeting 50–60% utilisation with autoscaling for the spikes, and they can ship a smaller definition this sprint. Priya adds requested-vs-used utilisation as a standing line on the cost pack so it can't drift back.

A month later the same service is ~$1.1k at healthy utilisation. Priya knows that's the right floor — real work, sized sensibly — and she also knows that if utilisation across the container estate drifts below ~30% again, that's the conversation, not the raw dollar figure. The dollars are a lagging indicator; the utilisation gap is the leading one.

The aggregate impact is material precisely because it hides. There's no spike to investigate and no anomaly alert — just a flat container line that happens to be two-to-four times larger than the workload warrants, multiplied across every service that was padded "to be safe." In many estates this is the single largest pool of no-architecture-change savings available, and it sits in plain sight on the invoice as a perfectly normal-looking number.

It also distorts commitment economics. Compute Savings Plans can cover Fargate, and if you commit against today's inflated usage you lock in a one-to-three-year promise sized to waste — then right-size later and strand part of the commitment. The discount looks great on paper and quietly underperforms. The sequencing rule that protects the budget is simple: right-size first, commit second. The commitment-utilisation number on the monthly report is where this shows up when it's done out of order.

The third impact is on chargeback and forecast credibility. When a service's cost is driven by an arbitrary request rather than its real usage, the figure you charge back to a business unit isn't defensible — it's an accident of how the task definition was written, not a reflection of value delivered. Right-sizing makes the chargeback honest: the unit pays for capacity proportional to what its workload actually consumes.

Finally, it's a leading indicator. A container estate where average utilisation drifts down month over month is telling you that requests are set once and never revisited — and that same set-and-forget pattern predicts other waste categories (idle services, oversized databases, unused load balancers) trending the same way. Watch the requested-vs-used ratio as a signal, not just the dollars.

Containers on Fargate are billed for the capacity the engineering team requested when they defined the workload — not for what the workload actually uses. When those requests are set high "to be safe" and never revisited, the business pays for headroom that's never touched, multiplied by every running copy of the service.

This is a recurring, low-risk savings category and a discipline signal. A healthy container estate runs at sensible utilisation and gets reviewed as workloads change; a low-utilisation estate means requests are set once and forgotten. The leadership question isn't the dollar figure — it's whether container utilisation is measured at all and trending the right way.

At one company the quarterly review used to show container spend as a single growing line with no context — just a bigger number each quarter. The exec sponsor stopped asking "why is it going up?" and started asking "what utilisation are these services running at, and is that number on the dashboard at all?"

Two quarters later the slide had changed. Container spend was still there, but next to it sat an average-utilisation figure with a target band, and a count of services below the band. The image-worker service that had been $4.3k was $1.1k, and three similar over-requests had been caught the same way. The exec hadn't asked anyone to chase dollars — she'd asked them to measure utilisation, and the dollars followed.

That's the right outcome state. "Minimise container spend" is the wrong goal — some workloads genuinely need big containers. "Every service runs at a measured, sensible utilisation and gets reviewed" is the right one. The cost line stops being an action item and becomes a confidence signal.

Container spend on its own is a number without a verdict — it could be entirely justified or it could be twice what it should be, and the dollar figure alone won't tell you which. What tells you is utilisation: how much of the capacity the business is paying for is actually being used. A healthy, measured utilisation figure means engineering is sizing workloads to reality; a low or unmeasured one means capacity is being ordered on guesswork and never reconciled.

There's a second-order point. Whether utilisation is even on the dashboard is itself the signal. An org that measures and reviews container utilisation almost always has the broader cost discipline that keeps the bigger spend categories honest too; one that can't answer "what utilisation are we running at?" usually has the same blind spot across its whole estate. This category is cheap to fix and disproportionately revealing about everything else.