Amazon EKS — KEDA — Event-Driven Scaling
KEDA — Kubernetes Event-Driven Autoscaling
KEDA extends HPA to scale based on external events: SQS queue depth, Kafka lag, CloudWatch metrics, Prometheus queries, and 50+ other sources.
How KEDA Works
KEDA Architecture
┌──────────────────────────────────────────────────┐
│ │
│ Event Source KEDA Kubernetes │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ SQS │───▶│ Scaler │───▶│ HPA │ │
│ │ Kafka │ │ │ │ (pods) │ │
│ │ CloudWatch│ │ ScaledObj│ │ │ │
│ │ Cron │ │ │ │ 0→N pods │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Key feature: Can scale to ZERO (and back) │
│ HPA alone can only scale to 1 minimum │
└──────────────────────────────────────────────────┘
Install KEDA
$ helm repo add kedacore https://kedacore.github.io/charts
$ helm install keda kedacore/keda --namespace keda --create-namespace
Scale Based on SQS Queue
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: sqs-worker
spec:
scaleTargetRef:
name: worker-deployment
minReplicaCount: 0 # Scale to zero!
maxReplicaCount: 50
triggers:
- type: aws-sqs-queue
metadata:
queueURL: https://sqs.us-east-1.amazonaws.com/123456789012/my-queue
queueLength: "5" # 1 pod per 5 messages
awsRegion: us-east-1
authenticationRef:
name: keda-aws-credentials
Common Scalers
| Scaler | Trigger | Use Case |
|---|---|---|
| aws-sqs-queue | Queue depth | Worker processing |
| kafka | Consumer lag | Stream processing |
| prometheus | Any Prometheus metric | Custom metrics |
| cron | Schedule | Predictable traffic patterns |
| aws-cloudwatch | Any CloudWatch metric | AWS-native scaling |
Common Mistakes
| Mistake | Impact |
|---|---|
| Not using IRSA for KEDA | Can’t authenticate to AWS |
| Scale-to-zero without readiness check | First request fails (cold start) |
| Too aggressive scaling | Oscillation |
What’s Next?
Practice: Auto Scaling Exercises.