Hey devops and cloud engineering community,
I’ve been knee-deep in a massive cloud migration and Kubernetes optimization project lately, and frankly, our EKS bill almost gave me a heart alarm last month.
Like many of you might be experiencing, our costs were ballooning due to two silent killers:
- Idle Resources: Clusters running full throttle at 3 AM with zero traffic.
- Over-provisioning: Pods sized for peak traffic, but running on a regular weekday.
After a lot of trial and error, wrestling with Karpenter, and fine-tuning HPA/VPA, we managed to claw back 35% of our monthly EKS spend without sacrificing performance.
I documented the entire journey, the specific architectural patterns we implemented (moving beyond just "turn it off at night"), and a practical audit checklist you can run against your own clusters.
You can find the detailed technical breakdown and code snippets on my archive here:
👉 ** https://jackhb1970.blogspot.com/ **
I’m curious to hear how you guys are tackling EKS FinOps in your environments. What tools or strategies are working (or failing) for you? Let’s discuss in the comments.
Cheers,
Jack_Insight
Top comments (1)
35% off an EKS cluster through FinOps patterns instead of a redesign usually means the previous state had requests set way above actual usage
That gap between requested and used is worth checking before assuming a migration is the only lever left
Now that we have HPA scale to 0, I'm sure you can cut another 10% easily