KEDA autoscaling allows scaling Kubernetes based on backlog in SQS. This shifts the scaling signal from CPU to actual load.
In event-driven systems on Kubernetes, classic metrics such as CPU and memory often do not reflect the real pressure on the system. Pods may be almost idle, but the Amazon SQS queue may already contain thousands of messages. The reverse situation is also typical: pods continue to run after a traffic spike has already passed. In such conditions, autoscaling based on CPU leads to either processing delays or excess resources. The key issue is the incorrect scaling signal. In queues, the signal is the backlog, not infrastructure utilization.
The solution revolves around KEDA autoscaling and integration with Amazon SQS. KEDA monitors queue metrics and manages Kubernetes HPA. This shifts the focus from resource metrics to workload volume. The main trade-off is the dependency on an external metrics source (SQS) and the need to properly configure scaling parameters. In return, the system begins to respond to actual load: it processes peaks faster and does not keep excess pods when the queue is empty. This approach has long been discussed in the industry as being more accurate for asynchronous workloads.
The architecture includes the KEDA operator, metrics API server, and CRD resources such as ScaledObject and TriggerAuthentication. Installation is performed via Helm, simplifying deployment. Access to SQS is configured through IAM with the principle of least privilege. This is important, as KEDA requires access only to a specific queue. The binding of deployment and queue is implemented through ScaledObject. The queueURLFromEnv parameter allows avoiding hardcoding. KEDA calculates the backlog as the sum of ApproximateNumberOfMessages and ApproximateNumberOfMessagesNotVisible, considering delayed messages if necessary.
The scaling model is built around queueLength. For example, if a value of 10 is set, one pod processes 10 messages. The formula is simple: desired replicas = ceil(outstanding messages / queueLength). The final number of pods is limited by minReplicaCount and maxReplicaCount. Scale-to-zero is supported, which is important for resource savings. System behavior is checked by sending messages to the queue and observing the ScaledObject and pods through kubectl. Possible issues include lack of scale-out, excessive number of pods, or inability to return to zero.
The result is a more accurate correspondence between load and scaling. The system responds faster to peaks and reduces idle costs when the queue is empty. Specific metrics of improvements are not indicated in the original material, but the system’s behavior becomes more predictable. This approach is universal and applicable not only to SQS but also to other messaging systems. The key principle is to choose a metric that reflects actual work rather than indirect signs of load.