Automating Kubernetes rightsizing and container-level cost allocation
Platform teams have spent years squeezing more efficiency out of Kubernetes. The real pressure hits when your AWS bill rises and nobody can confidently map spend back to workloads, teams, or tenants.
In this session, AWS and CloudBolt walk through a practical “better together” approach: EKS Auto Mode reduces day-to-day cluster overhead (compute, patching, upgrades), while StormForge Optimize Live continuously right-sizes workload requests so node provisioning and consolidation actually reflect actual usage.
You’ll see the before/after in a live demo, plus how cost allocation becomes actionable when idle, overhead, and shared services are modeled explicitly.
See what this looks like in your clusters
Book a meeting
Key takeaways
- Auto Mode reduces cluster operational overhead, but right-sized requests still shape the outcome (node sizing and consolidation follow workload requests).
- Overprovisioning persists because requests sit in a gray area between dev and SRE; policy-based optimization helps teams tune conservatism by environment.
- Cost allocation gets real when you can attribute spend by namespace/label and distribute shared pool costs (idle + overhead + system) across tenants.
What You’ll Learn
- How Auto Mode changes the ops burden for upgrades, patching, add-ons, and node lifecycle
- Why request hygiene is the multiplier for node consolidation and cost efficiency
- A concrete baseline vs optimized walkthrough using StormForge recommendations + auto-deploy
- How to allocate Kubernetes costs for chargeback (including shared pool costs)
Jump to:
- 00:00 – Why this webinar (and what you’ll get)
- 01:15 – The 3-way challenge at scale
- 05:31 – Why upgrades are painful (and why drift happens)
- 09:40 – Why Kubernetes bills go up
- 17:42 – Better together: Auto Mode + StormForge
- 19:00 – What EKS Auto Mode manages
- 26:43 – 21-day node rotation and upgrade behavior
- 31:10 – StormForge Optimize Live: how it works
- 37:19 – Live demo begins
- 58:39 – Q&A: under-provisioned apps + Goldilocks/VPA
Q&A highlights
A few of the audience questions we covered (with the practical takeaway):
- Under-provisioned apps with no requests: If workloads don’t set requests, scheduling gets unreliable and clusters become easier to overload. StormForge can generate sane request values even when you’re starting from “nothing,” which improves placement and stability—not just cost.
- StormForge vs Goldilocks (VPA): Goldilocks is typically a front-end for Kubernetes VPA. VPA can be a good baseline, but it has constraints (including common HPA/VPA tradeoffs) and a simpler sizing approach. StormForge uses a richer time-series model, supports more policy control, and is designed for continuous optimization workflows.
- CPU limits and memory limits: Many teams avoid CPU limits because throttling can hurt performance during microbursts. Requests still matter for scheduling and capacity planning. Memory limits are often kept (to protect against leaks), and StormForge can recommend requests and apply configurable request-to-limit ratios.
- Auto Mode node pools and instance selection: Auto Mode provides default node pools, but you can define custom pools (for example GPU) via manifests. StormForge can help inform workload “shape” so you can choose more appropriate families (compute-optimized vs memory-optimized) when you do customize.
Related Blogs
From Aria to agility: Modern hybrid cloud automation
If your automation strategy has been anchored in VMware Aria (vRA), the last two years have introduced real operational uncertainty.…
