Identifying up to 80% lower compute cost with EKS

The setup

While working as a platform engineer at a regulated digital-asset trading platform, I owned the infrastructure for a third-party ledger rollout. The company's services were running on ECS Fargate, but the ledger workload did not fit the existing ECS setup.

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

The cost finding

Building the platform also exposed a significant difference in the cost model.

ECS Fargate bills each running task for its configured vCPU and memory. Services often reserve capacity for peak demand even when they use less most of the time. On EKS, workloads share node capacity, and the scheduler places them according to their resource requests.

The largest modeled differences came from replacing per-task logging and monitoring sidecars with node-level agents, using granular requests for small services, and pooling burst capacity for spiky workloads.

I modeled the company's production service fleet using its ECS Fargate configuration and the EKS platform I had built. The model identified compute costs up to 80% lower on the workloads that benefited most, with roughly $40k/year in modeled savings across the fleet.

How I make changes like this safely

For production cutovers, I start with a low-risk service and move traffic gradually while monitoring errors and latency. Where the deployment controls support it, health checks can trigger an automatic rollback. I document the rollback procedure before production approval.

Names withheld. Each dollar figure in an assessment traces to a saved calculation over the available billing data. See the sample report for the report structure and method.