Use Kubernetes HPA alone when CPU, memory, or a metric already exposed to Kubernetes expresses your workload’s demand. Choose KEDA when you need a supported event-source scaler—such as a queue—or event-driven activation from zero replicas. They are not mutually exclusive: KEDA handles activation between zero and one, while the HPA normally manages scaling above one. Scale-to-zero depends on the Kubernetes release, metric type, and cluster configuration.
HPA vs. KEDA at a glance
| Decision | HPA alone | KEDA |
|---|---|---|
| Best fit | Demand is expressed by CPU or memory, or by a custom, object, or external metric already available through Kubernetes APIs and providers. | Demand is best expressed by a supported event-source scaler, or the workload needs KEDA-managed activation from zero. |
| Metrics and scaling | The HPA evaluates its configured metrics and recommends replica counts. | KEDA supplies scaler metrics to the HPA; the HPA normally handles scaling above one replica. |
| Scale from zero | Possible only with a suitable object or external metric and compatible Kubernetes release and configuration; CPU or memory alone cannot provide a signal at zero. | KEDA can activate from zero when a suitable scaler and configuration are available. CPU- or memory-only KEDA triggers cannot wake a zero-Pod workload. |
| Operational setup | Configure the HPA and operate the required metrics APIs and providers. | Operate KEDA’s operator and metrics API server, configure KEDA resources and scalers, and manage any required source credentials. |
This is a capability comparison, not a performance benchmark. No workload performance results are established by the cited documentation. See the Kubernetes HPA concepts, HPA v2 API reference, KEDA concepts, and KEDA v2.20 scaler catalog.
As an Amazon Associate I earn from qualifying purchases.
What HPA does—and what it needs
The Horizontal Pod Autoscaler is a Kubernetes API resource and control-plane controller. Its stable API is autoscaling/v2. It periodically adjusts a scalable workload, such as a Deployment or StatefulSet, based on metrics.
Metrics and prerequisites
- CPU and memory: Resource metrics are commonly served through
metrics.k8s.io, often by a separately deployed Metrics Server. For CPU-utilization targets, the HPA compares usage with requested CPU; a missing CPU request can leave utilization undefined for the affected metric. - Custom and external metrics: These require the corresponding Kubernetes metric APIs and an adapter or provider. Object metrics are also supported, provided the relevant metric source is available.
- Multiple signals: With
autoscaling/v2, an HPA can use multiple metrics and selects the largest replica recommendation among the metrics it can evaluate, subject to its configured maximum.
The documented default controller sync period is 15 seconds; it is a configuration default, not a guarantee that a workload reacts or becomes ready within that time. HPA behavior settings can define separate scale-up and scale-down policies, stabilization windows, and tolerance to control scaling velocity and reduce flapping. The HPA concepts documentation explains the control loop and metric requirements.
Keep replica ownership clear
When HPA controls a workload’s replica count, omit the workload’s declarative spec.replicas field from the manifest. Applying a manifest that specifies replicas can reset the count and interfere with autoscaling. Also verify that the metric APIs your HPA references are registered and readable; a syntactically valid HPA is not useful if its metrics cannot be fetched.
What KEDA adds
KEDA connects workloads to event sources through scalers and KEDA custom resources. Its operator manages KEDA resources and the HPA lifecycle, while its metrics API server exposes external scaler metrics for HPA decisions above one replica. KEDA’s documented architecture also includes admission webhooks that validate KEDA resources. In this arrangement, KEDA adds event-driven metrics and activation; it does not replace the HPA’s ordinary scaling role above one replica. See KEDA concepts and the v2.20 scaler catalog.
Event-driven workers
For a queue consumer, a KEDA scaler can observe pending work while there are no worker Pods and activate the Deployment. As demand grows, KEDA supplies event metrics and the HPA scales the workers above one replica. When the source is idle, suitable configuration can let KEDA scale the workload back to zero.
Recommended Free Tools
Workers can then pull messages from the event source. Whether that preserves retries, ordering, or dead-letter handling depends on the application and event source; autoscaling itself does not guarantee those processing semantics. The KEDA scaling documentation describes how KEDA and HPA divide scaling responsibilities.
Choose a scaler that matches the deployed release
KEDA’s catalog spans messaging, datastores, metrics, storage, CI/CD, applications, scheduling, Kubernetes, testing, and monitoring. The catalog consulted here is labeled v2.20, while the concepts and scaling pages carry v2.22 and v2.21 labels respectively. These pages should not be treated as one release-aligned specification: check the documentation for the KEDA version actually deployed and confirm the chosen scaler’s availability, configuration, and credential requirements.
Can Kubernetes HPA scale to zero?
It can under specific conditions; do not assume every cluster or HPA configuration supports it. Kubernetes documentation describes HPA scale-to-zero through the HPAScaleToZero feature gate and requires at least one object or external metric. CPU and memory alone cannot signal demand when no Pods are running.
Rank #4
The Kubernetes v1.37 announcement, published September 2, 2026, describes HPA scale-to-zero as Beta and enabled by default in that release for suitable object or external metrics. It also specifies that HPA must itself have scaled the workload down; manually setting replicas to zero leaves it paused. The relevant control-plane components must support and enable the feature. Check your actual Kubernetes version and control-plane configuration rather than relying on the version announcement alone. Read Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler.
With KEDA, the documented operator handles the zero-to-one and one-to-zero transitions. A KEDA setup using only CPU or memory triggers cannot activate a workload from zero, because those resource metrics require running Pods. For either approach, the activation signal must remain observable while the workload has no Pods.
Best Value
- Kubernetes is an open platform that automates container orchestration, enabling seamless deployment, automatic scaling, self-healing, and efficient management of applications across servers or clouds with high availability and optimal resource use
- Kubernetes is perfect for development operations engineers, cloud architects, site reliability engineers, platform engineering teams and infrastructure specialists who build, operate and maintain modern containerized applications in production environments
- Lightweight, Classic fit, Double-needle sleeve and bottom hem
What scale-to-zero means for users and traffic
Zero replicas can reduce idle compute, but a new activation takes time: the metric must be observed, a Pod scheduled, and the application started. For queue-backed work, messages can remain at the source until consumers return, subject to the queue’s retention and delivery behavior. Ordinary Kubernetes Services do not buffer HTTP requests while no Pods are ready. If requests must survive a zero-Pod interval, put a suitable buffering layer in front of the workload; otherwise, retain a minimum replica count.
Quick Recap
Choose based on your workload
Use HPA alone when
- CPU or memory utilization is a sufficient demand signal, and the necessary resource metrics are available.
- A custom, object, or external metric already exists in Kubernetes through a compatible API and provider.
- You want to configure the Kubernetes HPA directly and do not need KEDA-specific event-driven activation.
Add KEDA when
- A supported event-source scaler is a more direct measure of work than Pod CPU or memory—for example, pending queue messages.
- The workload should activate from zero based on a signal that remains available while it has no Pods.
- You are prepared to operate KEDA’s components and configure its custom resources, scaler, source access, and version-specific behavior.
Before relying on zero replicas
- Check the deployed Kubernetes and KEDA versions, and use documentation matching those versions.
- Confirm the metric or event source remains observable at zero Pods; CPU and memory alone do not meet this requirement.
- Verify the relevant metric APIs, providers, feature gates, control-plane support, and scaler configuration in the cluster.
- Decide what should happen to incoming work during activation. A queue may retain work according to its own semantics; HTTP traffic needs a separate buffer if it must be held until Pods are ready.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
