Event-Driven Autoscaling with KEDA
Scale workers on queued work or pending database rows rather than on CPU, down to zero when there is nothing to do, and how to request it.
This page explains how to scale workloads on events — work waiting in a queue or rows waiting in a database table — rather than on CPU and memory, and how to request it.
KEDA starts workers when there is work to do and scales them back, down to zero, when there is none. That suits background processing that arrives in bursts: you are not paying for idle workers between bursts, and a backlog is worked off by more workers in parallel.
Availability
KEDA is available on AWS and GCP, on request. It is set up together with CTO2B because the right trigger and limits depend on how your workload behaves.
Requesting it
Raise a request asking for event-driven autoscaling. We start with a short call, about 30 minutes, to agree what scales and on which signal. Preparing these answers makes the call quick:
| Question | Example |
|---|---|
| What does the work? | A worker Component, or one job per unit of work |
| What signals there is work waiting? | A database query returning pending rows, or a queue |
| How much work per worker? | One job per 10 pending items |
| How many workers at most? | 10 |
| How long can one job run? | 20 minutes |
How job-based scaling behaves
When each unit of work runs as a job, these defaults apply unless we agree different values:
| Setting | Default |
|---|---|
| How often the signal is checked | every 30 seconds |
| Workers when there is no work | 0 |
| Maximum workers at once | 10 |
| Maximum run time per job | 20 minutes |
| Retries for a failed job | 3 |
Scaling from zero means the first job starts shortly after work appears, not instantly. Design for that small delay rather than for an always-on worker.
Deploying a new version does not kill running jobs when a gradual rollout is used. Jobs already running finish on the old version; new jobs start on the new one. A job that runs past its maximum run time is stopped either way.
Monitoring
With a dedicated observability stack, a KEDA dashboard is available in Grafana, with alerts for:
- scaling failures
- work waiting with no jobs running
- workers held at the maximum for a sustained period, a sign the maximum is too low
Things to avoid
- Do not combine KEDA with CPU-based autoscaling on the same workload. Both try to control the number of replicas and they conflict. KEDA replaces it for that workload.
- Do not size the maximum for the worst day only. Every worker needs node capacity, and nodes are added for them automatically — see Cluster Autoscaling.
Related articles
- Cluster Autoscaling — how nodes are added for new workers
- CronJobs — scheduled work that runs at fixed times rather than on demand
- Workload Resources and Health Checks — resource requests and limits
Updated 26 days ago