kube-sqs-autoscaler

kube-sqs-autoscaler matched the number of application workers to the backlog in an AWS SQS queue. It periodically checked the queue and changed a Kubernetes Deployment's replica count, making it useful when demand arrived as background messages. This entry identifies Wattpad's archived implementation. A replacement needs to preserve how waiting and in-flight work affect scaling, while the workers still handle retries, acknowledgements and safe repetition of interrupted tasks.

Current guidance

This record identifies Wattpad’s kube-sqs-autoscaler, a controller that polls an AWS SQS queue and changes a Kubernetes Deployment’s replica count. GitHub’s repository metadata marks that exact repository archived. Its README also retains an extensions/v1beta1 Deployment example, so the preserved instructions should not be applied unchanged to a modern cluster.

KEDA’s SQS scaler is a separately maintained implementation to evaluate, not a renamed release or automatic replacement. Its queue-length target, activation behavior, authentication and treatment of in-flight or delayed messages need to be chosen explicitly. Compare those semantics with the old controller’s scale-up, scale-down and cooldown settings before replacing it.

Use queue-scoped AWS permissions and verify which identity performs the queue API calls. Test backlog growth, an empty queue, authentication failure and a worker terminating during processing. Workers still need suitable visibility timeouts, idempotent message handling and a dead-letter policy; adding replicas does not repair failed message processing. Avoid two independent autoscalers managing the same replica target during migration. The replacement has not been installed or benchmarked as part of this resource review.