Defining the Scaling Rules
To use KEDA, you create a ScaledObject Custom Resource Definition (CRD). This is the single source of truth for how a workload should scale. It tells KEDA three things: what to scale, when to scale it, and how aggressively.
A complete, annotated ScaledObject for an SQS-backed worker names the Deployment to scale (scaleTargetRef), sets the replica bounds (minReplicaCount: 0 to enable scale-to-zero, maxReplicaCount as a hard cap), configures timing (cooldownPeriod — how long to wait after the queue empties before scaling to zero, and pollingInterval — how often KEDA checks the event source), and lists its triggers — here, a single aws-sqs-queue trigger naming the queue URL, a target queueLength of messages per pod, the AWS region, and a reference to a TriggerAuthentication resource for credentials.
The Scaling Math
The target replica count is calculated as:
desired_replicas = ceil(current_queue_depth / queueLength)
So with queueLength: "5":
- 0 messages → 0 pods (scale to zero)
- 1–5 messages → 1 pod
- 6–10 messages → 2 pods
- 47 messages → 10 pods (ceil(47/5) = 10)
- 100 messages → 20 pods (capped at maxReplicaCount)
ScaledJob vs ScaledObject
For workloads that process exactly one item per pod run (like a video transcoding job), KEDA offers ScaledJob instead of ScaledObject. A ScaledJob creates individual Kubernetes Job objects rather than scaling a Deployment. Each job processes one event and exits. This is ideal when you want strict per-item isolation and don't want a long-running worker process.