Hypothesis

Scaling Kubernetes pods with KEDA based on Amazon SQS queue depth

Core Premise: Traditional CPU/memory metrics fail for asynchronous, queue-based workloads; SQS queue depth (backlog) serves as the true scaling metric.
Architecture Flow: Producers publish messages to Amazon SQS -> KEDA polls queue backlog metrics -> KEDA updates Kubernetes Horizontal Pod Autoscaler (HPA) -> HPA scales consumer deployment pods dynamically.
AWS Authentication: Recommends granting minimal IAM permissions (sqs:GetQueueAttributes, sqs:ReceiveMessage, sqs:DeleteMessage, etc.) to workers via IRSA or EKS Pod Identity.
Replica Calculation: KEDA determines total outstanding messages (ApproximateNumberOfMessages + ApproximateNumberOfMessagesNotVisible) and calculates desired pods via ceil(outstanding messages / queueLength), bounded by minReplicaCount (allows scale-to-zero) and maxReplicaCount.
Key Configuration Parameters:
- queueLength: Target number of messages per pod.
- activationQueueLength: Threshold to trigger initial scale-up from zero.
- cooldownPeriod & HPA behavior: Manage scale-down delay and stabilization windows.
Troubleshooting & Production Advice: Tune queueLength based on consumer throughput, decide whether in-flight messages count (scaleOnInFlight), and configure fallback replicas for operational resilience.