KEDA vs HPA: When Kubernetes' Built-In Autoscaler Isn't Enough

Here's a confusing truth about Kubernetes autoscaling: KEDA and HPA aren't actually enemies. KEDA literally uses HPA under the hood to do its job. And yet, teams still agonize over which one to build their scaling strategy around — because the choice determines how your infrastructure reacts to the world.

The real tension is simplicity versus intent. HPA is the default that ships with every cluster. It watches CPU and memory, and it scales your pods when those metrics move. It's boring, reliable, and completely free. KEDA is the ambitious newcomer that scales on anything: queue depth, Kafka consumer lag, cron schedules, even the number of messages sitting in a dead-letter queue. It's also free, but it comes with an operator to run, CRDs to learn, and 70+ scalers to wrap your head around.

Quick answer: If your workloads are steady, predictable, and HTTP-driven, use HPA and stop reading. If you're processing events from queues, streams, or databases — or if you want to scale to zero and stop paying for idle pods — KEDA is worth the extra complexity. Most teams will eventually need both.

---

The Quick Comparison Table

One honest note on ratings: neither tool has a traditional G2 listing because they're open-source infrastructure, not SaaS products. The community signals are what matter here. HPA has a decade of production trust. KEDA was accepted into CNCF in 2022, is backed by Microsoft, Red Hat, and AWS, and runs in production at companies like Shopify and Zalando.

---

Feature-by-Feature Deep Dive

1. Scaling Triggers & Metric Sources

What HPA does: Out of the box, HPA watches CPU utilization and memory usage. That's it. If you want custom metrics — say, requests per second or queue depth — you need to stand up a metrics adapter like the Prometheus Adapter and wire it into the Kubernetes metrics API. That's a real engineering project. The autoscaling/v2 API introduced in Kubernetes 1.23 supports custom and external metrics, but the plumbing required to feed them is substantial.

What KEDA does: KEDA ships with 70+ scalers that connect directly to your event sources. Kafka consumer lag, RabbitMQ queue depth, AWS SQS and SNS, Azure Service Bus, Google Pub/Sub, Redis lists, Postgres query results, Cassandra, MongoDB, even cron schedules. Each scaler has documented metadata and a clear YAML example. You define a ScaledObject, point it at your event source, and KEDA handles the rest. There's even a scaler for GitHub Actions runner queues and one for Twilio — the community got creative.

Which wins: KEDA, decisively. There's no contest here. HPA can technically do custom metrics, but KEDA makes it a 15-minute YAML change instead of a two-week adapter project.

2. Scale-to-Zero: The Killer Feature

What HPA does: HPA cannot scale a deployment to zero replicas. The minReplicas field effectively bottoms out at 1. There have been experimental configurations with custom metrics returning zero that technically work, but the behavior is inconsistent across Kubernetes versions and cloud providers. In practice, if you set minReplicas: 0 on an HPA, you're asking for trouble.

What KEDA does: minReplicaCount: 0 is a first-class feature. When your queue is empty, KEDA scales the deployment down to zero pods. When a message arrives, it scales back up within seconds. This is the single biggest reason teams adopt KEDA. If you have a consumer service that processes work in bursts — say, a batch job that runs when a Kafka topic has messages — you can stop paying for idle pods entirely.

Which wins: KEDA, and it's not close. This is the feature that pays for the operator's operational overhead within the first month.

3. Scaling Speed & Reaction Time

What HPA does: The kube-controller-manager checks HPA conditions every 15 seconds by default. But the metrics pipeline adds latency — the Metrics Server scrapes every 30-60 seconds, and there's propagation delay. In practice, a CPU spike can take 1-3 minutes to trigger a scale-up. Scale-down is deliberately slower: the default stabilization window is 5 minutes to prevent flapping.

What KEDA does: KEDA's operator polls your event source every 30 seconds by default, and you can configure this down to a few seconds for time-sensitive scalers. The catch: KEDA still delegates the actual scaling decision to HPA underneath. So the trigger detection is faster, but the final reconciliation is still bounded by HPA's mechanics.

Which wins: KEDA, marginally. For queue-based workloads, detecting a backlog 30 seconds faster matters. But don't expect the kind of millisecond response you'd get from a service mesh or a custom controller. Both tools are "fast enough" for most workloads; neither is real-time.

4. Operational Footprint & Reliability

What HPA does: Zero footprint. HPA is compiled into the kube-controller-manager. There's nothing to install, nothing to monitor, nothing to upgrade. It's just there, and it has been for a decade. If you're running Kubernetes, you're running HPA.

What KEDA does: KEDA runs as an operator — two pods in HA mode, consuming roughly 100m CPU and 100Mi memory each in production. You also get a metrics adapter and a set of CRDs. That means you own another piece of infrastructure. You need to monitor the operator's health, plan upgrades, and understand its failure modes. If the KEDA operator goes down, the HPA objects it created remain, so your last-known scaling configuration persists, but new scaling events stop. It's manageable, but it's a real operational burden.

Which wins: HPA, no contest. This is the price of KEDA's power. For a small team without dedicated platform engineers, that extra operator can be a genuine liability.

5. Extensibility & Custom Metrics

What HPA does: Extending HPA means writing a custom metrics API adapter. The Prometheus Adapter is the most common path, but it requires you to write PromQL queries, configure rules, and map series to the metrics API. It's doable, but it's a significant engineering investment. Most teams who go down this path end up maintaining a bespoke adapter that breaks silently when queries change.

What KEDA does: Writing a custom scaler in Go is a weekend project for a competent engineer. The scaler interface is well-documented, and the community has already built 70+ scalers you can reference. If your event source isn't covered, you can extend KEDA without touching the Kubernetes control plane. This is why KEDA has become the de facto standard for event-driven autoscaling — the extension barrier is low enough that the ecosystem grew organically.

Which wins: KEDA, clearly. The extensibility story is the difference between "we can scale on anything" and "we can scale on anything if we spend three weeks building an adapter."

6. Managed Kubernetes & Multi-Cloud Support

What HPA does: Works everywhere, zero configuration. Every managed Kubernetes service — EKS, GKE, AKS, OpenShift — supports HPA natively. If your cluster is up, HPA is available.

What KEDA does: Also works everywhere, but you install it yourself. That said, the vendor support is surprisingly strong. Red Hat ships KEDA as an optional operator on OpenShift with commercial support. AWS documents KEDA as the recommended approach for event-driven scaling on EKS. Azure integrates KEDA with AKS and uses it under the hood for Azure Functions and Container Apps. Google has published production guides for KEDA on GKE.

Which wins: Tie. Both tools run anywhere. But KEDA has more vendor muscle behind it in 2026 — Microsoft and Red Hat both have commercial stakes in its success, and AWS's EKS documentation increasingly points to KEDA as the default for event-driven workloads.

7. Security, RBAC & Multi-Tenancy

What HPA does: HPA is a control-plane component. Cluster admins manage it, and HPA resources are namespace-scoped. The security model is simple and well-understood. There's no additional service account to configure, no extra RBAC to audit.

What KEDA does: The KEDA operator runs cluster-wide by default, which means it needs broad RBAC permissions to manage HPAs across namespaces. That's a legitimate concern for platform teams with strict multi-tenancy requirements. KEDA has improved this significantly — newer versions support namespace-scoped operators and fine-grained permission controls — but it's still more complex than HPA's zero-footprint model. You need to think about who can create ScaledObjects and what triggers they can access.

Which wins: HPA for simplicity. KEDA is workable, but if your security team gets nervous about cluster-wide operators, expect a few uncomfortable review meetings before it gets approved.

---

Pricing Face-Off

Here's the thing about pricing: both tools are free. The real cost is what you burn in cloud spend when you're not scaling correctly, plus the engineering time to operate the tool.

Let me break down what that looks like for different team sizes:

The pattern is clear: HPA's cost is hidden in over-provisioning and custom adapter maintenance. KEDA's cost is upfront engineering time and a small operator footprint.

For a 5-person team running a simple web app, HPA is the obvious choice — KEDA's complexity isn't justified. For a 50-person team running event-driven microservices, KEDA pays for itself in the first billing cycle.

---

Integration Ecosystem

HPA's ecosystem: HPA integrates with the Metrics Server, the custom metrics API, and any adapter that speaks the Kubernetes metrics protocol — most notably the Prometheus Adapter. Every cloud provider's managed Kubernetes supports it out of the box. But the integration story stops there. HPA doesn't know what Kafka is, doesn't