Right-Sizing vs. Auto-Scaling: Which Saves More on EKS?
Most EKS cost conversations end up in the same place: someone enables Cluster Autoscaler, watches the node count drop slightly, and calls it done. Then the bill barely moves. The reason is that Cluster Autoscaler and right-sizing solve different problems, and applying one without the other leaves most of the savings on the table.
This piece breaks down what each approach actually does, where each wins, and in what order to apply them.
The Billing Model That Makes Right-Sizing So Powerful
EKS bills for EC2 node capacity, not for what your pods consume. A node is running, so you pay for it, regardless of whether pods use 10% or 90% of its resources.
The waste happens at the request level. Kubernetes uses resource requests, not actual usage, to schedule pods onto nodes. When a pod requests 2 vCPU and uses 0.3 vCPU in practice, that 1.7 vCPU is reserved and unavailable for any other workload. The node fills up on paper while sitting mostly idle in practice.
At $0.384/hr for an m5.2xlarge in us-east-1, that cluster pays for 8 vCPU per node but gets meaningful work out of fewer than 3. Cluster Autoscaler cannot fix this. It sees the node as utilized because requests are high. It will not remove the node even though actual usage is low.
Right-sizing corrects the requests. Once requests reflect real usage, nodes can fit more pods, fewer nodes are needed, and Cluster Autoscaler can actually remove underutilized nodes.
What Right-Sizing Actually Changes
Right-sizing has two layers on EKS: pod-level requests and node-level instance sizing.
At the pod level, the goal is to set CPU and memory requests close to the 90th-percentile actual usage, not at a round number someone picked during deployment. The Vertical Pod Autoscaler (VPA) in Recommendation mode observes pod metrics over time and produces a suggested request value. It does not apply the change automatically in Recommendation mode. You review and apply it yourself.
The impact compounds quickly. Consider a service running 10 replicas on an m5.2xlarge cluster:
| Metric |
Before Right-Sizing |
After Right-Sizing |
| CPU request per pod |
1000m |
250m |
| Memory request per pod |
2 GB |
512 MB |
| Pods per node (bin-packing) |
4 |
14 |
| Nodes needed for 10 replicas |
3 |
1 |
| On-demand hourly cost (us-east-1) |
$1.15 |
$0.384 |
| Monthly cost (730 hrs) |
$840 |
$280 |
The 10 replicas did not change. The pods do the same work. The only thing that changed is what the pods told Kubernetes they needed. That correction removed two nodes permanently.
At the node level, right-sizing means choosing instance types that match the actual pod profile of the workload. A cluster running memory-light, CPU-bound services wastes money on r5 instances. Moving to c5 instances gives more vCPU per dollar. AWS Compute Optimizer analyzes CloudWatch metrics from your managed node groups and recommends instance type changes. It is free to run.
Right-sizing is a one-time correction with a permanent effect on your baseline bill.
How Auto-Scaling Addresses a Different Problem
Auto-scaling does not reduce per-pod waste. It matches the number of running pods and nodes to current demand, which is a different problem entirely.
Horizontal Pod Autoscaler (HPA) adds or removes pod replicas based on CPU utilization or custom metrics. When traffic spikes, more pods appear. When traffic drops, excess pods terminate. This prevents the cluster from being statically sized for peak load when average load is much lower.
Cluster Autoscaler works at the node level. When pending pods cannot be scheduled because no node has enough capacity, it provisions a new node. When a node’s actual utilization drops below a threshold for 10 consecutive minutes, it removes it. The trigger is pod requests, not actual CPU or memory usage.
KEDA extends HPA with event-driven scaling. Instead of scaling on CPU, you can scale on queue depth, Prometheus metrics, scheduled time windows, or external signals. A batch processor that runs overnight can scale to zero during business hours and scale back up at midnight.
Auto-scaling is most valuable when the load is genuinely variable. A service that gets 5x more traffic at noon than at midnight should not run peak-capacity nodes all day. Auto-scaling handles that. A service that runs at steady load 24 hours a day gets nothing from HPA, but gets real savings from right-sizing.
The critical failure mode: if you enable HPA on overprovisioned pods, every new replica inherits the bloated requests. Scaling from 5 pods to 15 pods triples the cluster cost, but the actual work is the same per replica, just distributed across more instances.
Where Each Approach Wins and Where It Fails
| Dimension |
Right-Sizing |
Auto-Scaling |
| Traffic pattern |
Steady or predictable load |
Variable, spiky, or event-driven load |
| Type of savings |
Reduces baseline cost permanently |
Reduces cost during off-peak periods |
| Engineering effort |
One-time: measure, apply, verify |
Ongoing: tune thresholds, monitor lag |
| Time to value |
1 to 2 weeks of VPA observation |
Hours to configure, tuning takes weeks |
| Primary failure mode |
Pods OOMKilled if requests set too low |
HPA lag during sudden traffic spikes |
| Best tool |
VPA Recommendation + Compute Optimizer |
HPA + Cluster Autoscaler + KEDA |
Right-sizing delivers immediate, permanent reduction. It works regardless of traffic shape because it corrects the structural waste in how pods claim resources. Auto-scaling delivers proportional reduction on variable workloads. It works because it removes capacity that is genuinely not needed at a given moment.
Neither approach alone is complete. Right-sizing a statically-sized cluster still leaves it over-provisioned for off-peak hours. Auto-scaling an unright-sized cluster scales up and down efficiently.
The one situation where auto-scaling wins outright: EKS Fargate. Fargate charges per vCPU-second and GB-second of actual pod requests, not for idle node capacity. Right-sizing requests directly reduces the bill with no node management. But Cluster Autoscaler is irrelevant on Fargate since there are no nodes to manage. KEDA and HPA still apply.
The Right Order: Right-Size First, Then Auto-Scale
Applying both approaches in the correct sequence is where the real savings appear. The sequence we use in production:
Step 1: Measure with VPA Recommendation. Deploy VPA in Recommendation mode and let it observe your workloads for at least 7 days. Include a representative sample of traffic, including any weekly peaks. VPA will output a suggested CPU and memory request based on observed percentiles.
Step 2: Apply right-sized requests. Take the VPA recommendation, add 15-20% headroom for burst, and apply it to your pod specs. Roll this out service by service, not all at once. Watch for OOMKilled events in the first 24 hours. An OOMKill means the memory request was set below the actual peak usage. Adjust and re-roll.
Step 3: Tune HPA thresholds. HPA uses CPU target as a percentage of the pod’s CPU request. If a pod requests 1000m CPU and you set HPA to target 70%, it scales at 700m actual CPU. After right-sizing to 250m CPU, that same 70% target triggers at 175m actual CPU. If your workload doesn’t spike that low, HPA will never scale. Recalibrate the target percentage after right-sizing.
Step 4: Validate Cluster Autoscaler behavior. After right-sizing, nodes should consolidate. Cluster Autoscaler should remove nodes that are now underutilized because pods pack more efficiently. If it does not, check the --scale-down-utilization-threshold setting. The default is 50% of requests. With right-sized requests, actual usage should be closer to requests, so utilization will read higher and nodes may survive scale-down review. You may need to lower the threshold slightly or enable bin-packing with the --balance-similar-node-groups flag.
On a 3-node m5.2xlarge cluster running 15 services, this sequence typically consolidates to 1-2 nodes and reduces the hourly EC2 cost from $1.15 to $0.38-0.57. That is a 50-67% reduction. Auto-scaling on its own, without the right-sizing step, would have reduced cost only during off-peak windows, yielding a smaller net monthly reduction.
Right-sizing wins on immediate, permanent impact. Auto-scaling wins on dynamic efficiency. Run both. Run right-sizing first.
Conclusion
If you only auto-scale, you are efficiently managing a wasteful architecture. If you only right-size, you are running a lean architecture that can’t breathe with your traffic.
The most significant EKS savings don’t come from a single “silver bullet” setting; they come from the Right-Size → Bin-Pack → Auto-Scale pipeline. By correcting your pod requests first, you provide the Cluster Autoscaler with the accurate data it needs to actually trigger a scale-down.Start with VPA in recommendation mode today and let your monthly AWS bill reflect the difference.
Google, Android Auto işletim sisteminin kullanıldığı tamamen elektrikli araçlar için Maps (Haritalar) temelli bir şarj güncellemesi yayımladı. “Google Maps’in elektrikli araç şarjına yönelik yapay zeka destekli özelliklerini Android Auto temelli 350’den fazla araç modeline getiriyoruz.” diyen Google, bu konuda yaptığı resmi açıklamada, “Artık Haritalar, elektrikli araç modelinize ve batarya doluluk oranınıza göre ne zaman ve nerede şarj etmeniz gerektiğini söyleyecek; böylece hem yolda kalma korkunuz bitecek hem de farklı uygulamalarla uğraşmak zorunda kalmayacaksınız.” ifadelerine yer verdi. 15’ten fazla markaya ait yüzlerce elektrikli araç modeline açılan altyapı, ilk olarak ABD’de sunuluyor. “Yüzlerce aracın batarya tüketimini doğru tahmin edebilmek adına yapay zekayı gelişmiş enerji modelleriyle birleştiriyoruz. Bu modeller; aracın ağırlığı ve batarya boyutu gibi teknik özelliklerin yanı sıra haritalardan gelen trafik, yol eğimi ve hava durumu gibi gerçek zamanlı verileri de analiz ediyor.” diyen Google, sistemi önümüzdeki dönemde küresel olarak da kullanıma alabilir.
Microsoft 365 Copilot’un doğrudan kompleks görevlere odaklanan Researcher aracı, “Critique” ve “Council” adı verilen yeni özelliklerle güçlendirildi. Microsoft CEO’su Satya Nadella tarafından yapılan paylaşıma göre yeni çok modelli derin araştırma sistemi Critique, birden fazla yapay zeka modelinin (GPT ve Claude) bir arada çalıştırılarak olabilecek en ideal sonuçların/raporların elde edilmesine aracılık ediyor. Council ise kullanıcıların aynı istem (prompt) üzerinde birden fazla modeli eş zamanlı olarak çalıştırmasına imkan tanıyor. Bu özellik farklı modellerin hangi noktalarda birleştiğini, hangi noktalarda ayrıştığını ve her bir modelin sonuca katkısını gözler önüne seriyor. Introducing Critique, a new multi-model deep research system in M365 Copilot. You can use multiple models together to generate optimal responses and reports. pic.twitter.com/m4RlQmCKzs — Satya Nadella (@satyanadella) March 30, 2026 New in M365 Copilot: Council. You can run multiple models on the same prompt at the same time, so you can see where they align and diverge, and understand what each adds. pic.twitter.com/2p7O14OLFp […]
