kubernetesautoscalingPractitioner

Scaling Kubernetes Pods with KEDA: Mastering SQS Queue Depth

5 min read CNCF BlogJul 31, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

In the world of cloud-native applications, managing workloads efficiently is crucial. KEDA (Kubernetes Event-driven Autoscaling) addresses this by allowing Kubernetes to scale pods based on the depth of messages in an Amazon SQS queue. This capability is vital for applications that experience fluctuating workloads, ensuring that you only use resources when necessary, thus optimizing costs and performance.

KEDA operates by polling the SQS queue attributes to assess the backlog of messages. It updates the target metrics in the Horizontal Pod Autoscaler (HPA), which then scales the worker deployment accordingly. As the queue depth increases, KEDA triggers scaling actions, and as the queue drains, it scales down the replicas. Key configuration parameters include pollingInterval, set to 10 seconds by default, and cooldownPeriod, which is 120 seconds after scaling up. You can define minimum and maximum replicas with minReplicaCount and maxReplicaCount, respectively, ensuring that your application can handle varying loads without manual intervention.

In production, ensure you have an Amazon EKS cluster running a supported Kubernetes version, and KEDA installed via Helm. Authentication methods like IRSA or EKS Pod Identity are necessary to connect to your SQS queue securely. Be mindful of the activationQueueLength, which is set to 1 by default; this means scaling actions will trigger as soon as there is at least one message in the queue. While KEDA is powerful, always monitor your application’s performance and adjust configurations based on your specific workload patterns. The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Key takeaways

→Configure KEDA with `pollingInterval` set to 10 seconds for timely scaling actions.
→Set `maxReplicaCount` to 30 to handle high loads effectively.
→Use `activationQueueLength` of 1 to trigger scaling with minimal queue presence.
→Implement `cooldownPeriod` of 120 seconds to prevent rapid scaling down.
→Ensure proper AWS authentication methods are in place for secure SQS access.

Why it matters

Efficiently scaling your Kubernetes pods based on SQS queue depth can drastically reduce costs and improve application responsiveness, especially during peak loads.

Code examples

Bash

1# Add the KEDA Helm repository
2helm repo add kedacore https://kedacore.github.io/charts
3helm repo update
4
5# Install KEDA into a dedicated namespace
6helm install keda kedacore/keda \
7  --namespace keda \
8  --create-namespace

YAML

1apiVersion: keda.sh/v1alpha1
2kind: TriggerAuthentication
3metadata:
4  name: sqs-processor-auth
5  namespace: workers
6spec:
7  podIdentity:
8    provider: aws
9---
10apiVersion: keda.sh/v1alpha1
11kind: ScaledObject
12metadata:
13  name: sqs-processor
14  namespace: workers
15spec:
16  scaleTargetRef:
17    name: sqs-processor
18  pollingInterval: 10
19  cooldownPeriod: 120
20  minReplicaCount: 0
21  maxReplicaCount: 30
22  advanced:
23    horizontalPodAutoscalerConfig:
24      behavior:
25        scaleDown:
26          stabilizationWindowSeconds: 60
27  triggers:
28    - type: aws-sqs-queue
29      authenticationRef:
30        name: sqs-processor-auth
31      metadata:
32        queueURLFromEnv: QUEUE_URL
33        awsRegion: us-east-1
34        queueLength: "10"
35        activationQueueLength: "1"