Autoscaling is supposed to save money. A lot of the time it doesn't, because people reach for the wrong kind. Kubernetes gives you three common options, and they solve three completely different problems. Pick the wrong one and your bill barely moves.
Here's a plain breakdown of HPA, VPA, and KEDA, what each actually does to your cloud spend, and the one thing that decides whether any of them saves you a rupee.
The one-line difference
HPA changes how many pods you run. VPA changes how big each pod is. KEDA makes pods appear and disappear based on events, and can take them all the way to zero. That's the whole mental model. Everything below is detail.
HPA: more pods when it's busy, fewer when it's not
The Horizontal Pod Autoscaler is built into Kubernetes. It watches a metric like CPU, memory, or a custom signal, and adds or removes pod replicas to keep that metric near a target.
For cost, HPA helps when you'd otherwise run a fixed, high replica count "just in case." Instead of paying for 10 pods around the clock, you run 3 at night and let it scale to 10 during the busy hours. It's the right tool for stateless workloads with swings in traffic: web frontends, APIs, microservices.
What it won't do is scale to zero. HPA's floor is one replica, so an idle service still costs you. It also has no idea about money. It optimizes the metric, not the bill.
VPA: right-sizing pods that ask for too much
The Vertical Pod Autoscaler works the other way. Instead of changing the number of pods, it adjusts the CPU and memory each pod requests, based on what it actually uses.
This attacks the most common form of Kubernetes waste: over-provisioning. Developers request 2 CPUs and 4 GB to be safe, then use a fraction of it. It's common to see clusters using only 10 to 20 percent of what they request. That gap is pure waste, and VPA is what closes it by pulling requests down to reality.
Two catches. VPA usually restarts a pod to apply new sizes, which causes brief disruption. And it fights with HPA if they both act on CPU or memory, so you don't point them at the same metric. VPA is best for steady workloads and batch jobs where the replica count isn't the problem, the per-pod size is.
KEDA: scale to zero when nothing is happening
KEDA is the event-driven one, and for a lot of teams it's where the real savings hide. It's a CNCF graduated project (it reached that level in August 2023) with more than 70 built-in scalers for things like queues, Kafka, databases, and cloud services.
The headline feature is scale to zero. Plain HPA keeps at least one pod alive. KEDA can drop a workload to zero replicas when there are no events, then spin it back up the moment work arrives. For anything bursty or scheduled, that's huge. A worker that only processes a queue for a few hours a day sits idle for the rest. Over a 168-hour week, a business-hours-only service is doing nothing for roughly 128 of those hours. Scaling to zero turns that idle time from a cost into nothing.
KEDA shines for background workers, batch pipelines, event consumers, and anything with long quiet stretches. It's less relevant for a service that genuinely needs to answer requests every second.
So which one actually cuts your bill?
Match the tool to the kind of waste you have.
If your pods request far more than they use, that's a VPA problem. If you run a fixed replica count that ignores real traffic, that's an HPA problem. If you keep workloads running while they sit idle, that's a KEDA problem, and usually the biggest single win because zero is a smaller number than "one pod, always on."
Most mature setups use more than one. HPA handles traffic swings, VPA keeps per-pod requests honest, and KEDA drives event-based work down to zero. They cover different waste, so they stack well.
The part everyone forgets
Here's the catch that undoes a lot of autoscaling work: scaling pods down does not save money on its own.
You pay for nodes, not pods. If HPA removes five pods but the nodes stay running, your bill is unchanged. Savings only land when the empty capacity is actually removed by the Cluster Autoscaler, or a tool like Karpenter, shrinking the node pool to match. Pod autoscaling frees the space. Node autoscaling collects the refund. Skip the second half and you've done a lot of tuning for nothing.
The bottom line
None of these three is "the money saver." They target different waste. VPA stops pods from asking for too much. HPA stops you from running a fixed fleet that ignores demand. KEDA stops idle workloads from costing anything at all, which is why it's often the biggest lever for bursty and background jobs.
Start by finding your waste before you install anything. Look at request-versus-usage first, then at whether idle workloads are staying alive. Pick the tool that matches what you find, and make sure your nodes scale down too. Do that, and autoscaling finally does the thing it promised: a bill that follows your real usage instead of your worst-case guess.
Top comments (0)