KEDA
Kubernetes Event-Driven Autoscaling — extends Kubernetes' built-in HPA (Horizontal Pod Autoscaler) with 60+ scalers for external event sources. Where standard HPA scales on CPU/memory, KEDA scales based on external metrics: Kafka consumer lag, Azure Service Bus queue depth, AWS SQS messages, Prometheus metrics, Cron schedules, and many more. Enables scale-to-zero for event-driven workloads, activating pods only when messages are waiting. CNCF graduated project.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Apache 2.0, CNCF graduated. TriggerAuthentication for scaler credentials — avoids embedding credentials in ScaledObject. Kubernetes RBAC for CRD access. External scaler credentials support IRSA/Workload Identity for cloud-native auth.
⚡ Reliability
Best When
You have event-driven Kubernetes workloads (Kafka consumers, queue processors, batch jobs) that should scale to zero when idle and scale up based on queue depth.
Avoid When
You need HTTP traffic scaling for web services — use Knative, standard HPA, or KEDA HTTP add-on for request-based autoscaling.
Use Cases
- • Scale Kafka consumers up/down based on consumer group lag — add more consumers when queue backs up, scale to zero when caught up
- • Scale agent worker pods based on Redis queue depth — deploy more parallel agent workers when work is available, zero when idle
- • Auto-scale async processing workloads based on SQS/Service Bus queue depth to match throughput with incoming demand
- • Schedule-based scaling using Cron scaler — pre-scale ML inference pods before peak traffic windows
- • Scale Kubernetes deployments based on Prometheus metrics — scale on custom application metrics like active sessions or task queue length
Not For
- • Real-time traffic autoscaling — KEDA is for event-driven workloads; use standard HPA or KEDA HTTP add-on for HTTP traffic scaling
- • Stateful applications requiring careful scale-down — KEDA scale-to-zero kills pods; stateful apps need draining logic
- • Non-Kubernetes environments — KEDA is Kubernetes-only
Interface
Authentication
KEDA interfaces via Kubernetes CRDs — Kubernetes RBAC is the auth model. ScaledObject and ScaledJob resources reference TriggerAuthentication resources that hold credentials for external scalers (Kafka SASL, SQS IAM, etc.). KEDA itself authenticates to external systems via these credentials.
Pricing
Apache 2.0, CNCF graduated. Free forever. Commercial Kubernetes distributions (OpenShift, AKS, EKS) include KEDA support.
Agent Metadata
Known Gotchas
- ⚠ ScaledObject takes ownership of the target Deployment's HPA — don't manually modify HPA created by KEDA or ScaledObject will override changes
- ⚠ Scale-to-zero means cold start latency when first message arrives — configure minReplicaCount: 1 if cold starts are unacceptable
- ⚠ Scaler polling interval (pollingInterval) vs cooldown period (cooldownPeriod) both affect scale responsiveness — tune both for your workload
- ⚠ TriggerAuthentication must be in the same namespace as ScaledObject (or use ClusterTriggerAuthentication for cross-namespace)
- ⚠ KEDA's Kafka scaler requires lag to be computed by KEDA — the consumer group must be registered even if no active consumers
- ⚠ Simultaneous scale-up and scale-down decisions for the same ScaledObject are handled by HPA — KEDA provides metrics, HPA makes the decision
- ⚠ External scaler timeouts can prevent scale-up if the external system is slow to respond — configure appropriate timeouts per scaler
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for KEDA.
Scores are editorial opinions as of 2026-03-06.