Cutting compute cost up to 80% by moving off ECS Fargate

The setup

A regulated digital-asset trading platform was running its services on ECS Fargate. I owned the platform side and needed to stand up infrastructure for a third-party ledger system, a workload that didn't fit the existing ECS setup.

I built an EKS platform for it, solo, with the infrastructure defined in Pulumi, and rolled it out to production. The ledger system ran on it.

The cost finding

Building that platform surfaced a pricing problem hiding in plain sight.

Fargate bills each task for the maximum resources its workload might need. You allocate for the peak, and you pay for the peak, all the time, per task. Most services spend most of their life nowhere near peak. On EKS, workloads share nodes: many services pool the same compute, and the scheduler packs them so one service's idle headroom absorbs another's burst.

I priced the company's service fleet both ways. Running it on the EKS platform came out up to 80% cheaper than the ECS Fargate equivalent, roughly $40k/year in compute, on infrastructure that was already built, rolled out, and carrying production traffic.

That's the shape of finding I look for in every assessment: not a dashboard recommendation, but a structural pricing mismatch quantified against the client's own workloads, with the implementation path already proven.

How I make changes like this safely

Infrastructure cutovers on production systems are routine for me, and they all run the same way: start with one small service, shift an increasing share of traffic onto the new infrastructure while watching error rates, and wherever possible make the transition fail back automatically on issues. No big-bang migrations, no changes without a rollback path. I've run production deployments and cutovers on underlying infrastructure changes this way for years, in environments where trading was live and downtime was measured in money.

Beyond the one story

At the same company I also cut observability spend, primarily Datadog log indexing, which is one of the most common silent line-item bloats I see. And I've since delivered a second EKS platform from greenfield at another company, so the platform build itself is a repeatable capability, not a one-off.

Names withheld. Every number in an assessment I deliver is computed from the client's own billing data. See the sample report for what that looks like.