To cut costs with KEDA, install it, find workloads that can sit idle, create a ScaledObject with minReplicaCount set to zero, and pick an event source so KEDA scales up when work arrives. For web services, add the KEDA HTTP add-on, which queues the first request while pods start. KEDA scales a deployment to zero pods when its event source is empty, so idle workloads consume nothing. The only real trade off is cold start latency, which you manage per workload.
Last updated: June 2026. Written by Morten Andersen and reviewed by Fredrik Filipsson, built on our See, Cut, Lock, Run method.
This article sits in our complete guide to Kubernetes cost optimization, the cluster pillar it links up to, and connects to the broader cloud cost optimization playbook. Scaling to zero pairs naturally with right-sized requests, so see our companion guide on how to right-size Kubernetes requests with VPA and Goldilocks. Scale-to-zero is a Cut step move that removes spend you were never using.
minReplicaCount: 0 on a ScaledObject. That single field is what tells KEDA a workload may fall all the way to zero pods, not just down to one. Without it, even an event driven service holds at least one idle replica burning CPU and memory around the clock. With it, plus a scaler that activates on work arriving, the deployment costs nothing while it waits. Match it to workloads that can absorb a cold start, and the savings are immediate.
What is KEDA and how does scale to zero work?
KEDA, Kubernetes Event-driven Autoscaling, is a CNCF component that extends the Horizontal Pod Autoscaler so a deployment can scale to zero pods and back up based on an event source. Scale to zero works by setting minReplicaCount to zero on a ScaledObject; when the event source, such as a queue, topic, cron schedule, or metric, reports no pending work, KEDA drops the deployment to zero, and when work appears it activates the deployment and the HPA scales it out. The result is that idle, event driven workloads consume no compute, which is exactly the spend that quietly accumulates with always on replicas.
Which workloads should scale to zero?
Workloads that should scale to zero are those that can tolerate a short cold start: batch jobs, queue and topic consumers, scheduled tasks, internal tools, dev and staging services, and low traffic APIs. These spend most of their time idle, so holding even one replica is pure waste. The poor candidates are latency sensitive, user facing paths where the cold start delay would breach an SLO, and anything that must respond instantly on the first request. The skill is classifying your services honestly: most estates have a long tail of intermittently used workloads that are paying to do nothing.
How do I set it up, step by step?
Set it up by installing KEDA, picking idle-capable workloads, defining the ScaledObject, choosing a scaler, and validating. Six steps:
- Install KEDA. Deploy KEDA with Helm so it can manage HPAs and scale from zero. Result: the autoscaling engine is live.
- Identify idle-capable workloads. Find batch jobs, queue consumers, and low traffic services that can sit at zero between events. Result: a candidate list ranked by idle time.
- Create a ScaledObject with minReplicaCount zero. Target the deployment and set minReplicaCount to zero. Result: the workload can fall fully idle.
- Choose an event source scaler. Pick a queue, topic, cron, or metric scaler so KEDA scales up when work arrives. Result: prompt activation on demand.
- Add the HTTP add-on for web services. Use the KEDA HTTP add-on to scale HTTP services to zero, queuing the first request. Result: even web services can idle.
- Validate cold start behavior. Test scale from zero latency and tune the activation threshold. Result: cold starts stay within your SLO.
Want every idle workload found and scaled to zero?
Our Kubernetes cost audit identifies the workloads paying to sit idle, configures KEDA scale-to-zero with the right scalers, and validates cold starts against your SLOs. On the performance model, you pay only from realized savings. No savings, no fee.
Book a Kubernetes cost audit →How do I manage cold starts?
Manage cold starts by matching scale-to-zero to tolerant workloads and tuning the activation threshold, with a small minimum where the first request must be fast. A workload at zero must start a pod before serving the next request or event, which adds latency. For batch, queue, and internal services that delay is invisible. For a service where the first hit matters, you can keep a single warm replica and only scale the rest to zero, or use the HTTP add-on's interceptor to hold the request while pods come up. Set the activation threshold so brief gaps do not trigger constant scale down and up. The broader autoscaling sequence lives in our Kubernetes guide.
The Kubernetes Cost Optimization Handbook includes the scale-to-zero candidate checklist and the cold start tuning guidance referenced above. It is the downloadable companion to this guide.
Frequently asked questions
What is KEDA?
KEDA, Kubernetes Event-driven Autoscaling, is an open source component that complements the Horizontal Pod Autoscaler and lets you scale a deployment to zero pods and back up from zero based on an event source such as a queue, topic, cron schedule, or metric. It is a CNCF project and is the standard way to run scale-to-zero on Kubernetes.
How does KEDA scale to zero?
You set minReplicaCount to zero on a ScaledObject targeting the deployment. When the configured event source reports no pending work, KEDA scales the deployment to zero pods so it consumes no CPU or memory. When work arrives, KEDA activates the deployment and the Horizontal Pod Autoscaler scales it out, so you pay only when there is something to process.
Can KEDA scale HTTP services to zero?
Yes, using the KEDA HTTP add-on, which scales HTTP workloads on request rate and concurrency and can hold the first request in an interceptor while pods start. The HTTP add-on is a separate component installed after KEDA core and is currently in beta, so test cold start latency before relying on it for production traffic.
What is the downside of scaling to zero?
The trade off is cold start latency. A workload at zero must start a pod before it can serve the next request or event, which adds delay. For batch, queue, and low traffic internal services this is usually fine; for latency sensitive user facing paths it may not be. Set a sensible activation threshold and a small minimum where the first request must be fast.
The short version
Install KEDA, find the workloads that sit idle, set minReplicaCount to zero on a ScaledObject, and pick the right event source, adding the HTTP add-on for web services. You stop paying for idle replicas and only pay when there is work. When you want every idle workload found and scaled to zero, that is what our rightsizing and waste elimination service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.