{"slug": "keda-how-event-driven-autoscaling-cuts-kubernetes-cost", "title": "KEDA: How Event-Driven Autoscaling Cuts Kubernetes Cost", "summary": "KEDA, an open-source Kubernetes event-driven autoscaler graduated by the CNCF, reduces cloud costs by scaling workloads to zero replicas when no events are pending, a capability standard HPA lacks. Created by Microsoft and Red Hat, KEDA supports 70+ event sources and manages HPA resources automatically, with scale-to-zero as its most impactful cost feature. Cold starts are a trade-off, mitigated by lean containers and tuned probes, while Cast AI optimizes the node layer for cost efficiency.", "body_md": "## Key takeaways\n\n- KEDA is a CNCF Graduated open-source project (graduated August 22, 2023), created by Microsoft and Red Hat.\n- It scales Kubernetes workloads using external event signals: queue depth, Kafka consumer lag, Prometheus metrics, and 70+ additional sources.\n- KEDA wraps Kubernetes HPA rather than replacing it. When you create a ScaledObject, KEDA creates and manages an HPA resource automatically.\n- Scale to zero is KEDA’s most impactful cost feature. HPA cannot go below 1 replica; KEDA patches replicas directly to 0 when no events are pending.\n- Cold starts are the trade-off of scale-to-zero. Mitigate with lean container images, tuned readiness probes, and per-workload\n`minReplicaCount`\n\ndecisions. - Cast AI handles the node layer: provisioning instances, placing pods on spot, and right-sizing resource requests so KEDA-scaled pods land on minimum-cost nodes.\n\n## What is KEDA?\n\nMost queue-based workloads sit idle between processing bursts, holding node reservations and consuming compute budget without doing useful work. KEDA (Kubernetes Event-Driven Autoscaling) addresses this directly. It scales workloads based on external event signals such as queue depth or Kafka lag, rather than CPU or memory alone. When no events are pending, KEDA takes the Deployment all the way to zero replicas, eliminating idle cost. Microsoft and Red Hat created the project; it reached CNCF Graduation on August 22, 2023, with over 10,000 GitHub stars and 400+ contributors confirming production maturity.\n\nThe most important capability separating KEDA from standard HPA: KEDA can scale to zero. HPA enforces a minimum of 1 replica with no mechanism to reach zero. KEDA bypasses that constraint at the controller level, patching the replica count directly when all event sources report empty.\n\n### Key CRDs\n\nKEDA introduces four primary CRDs:\n\n**ScaledObject**: Links a Deployment or StatefulSet to one or more event source triggers. It defines min/max replicas, polling interval, and cooldown period.**ScaledJob**: Targets Kubernetes Jobs instead of long-running Deployments. Use ScaledJob when each event should spawn an isolated Job instance rather than routing to a shared worker pool. This is the right choice for one-shot batch tasks where job isolation matters more than pooled efficiency, for example image processing or report generation where shared state is a liability.**TriggerAuthentication**: Manages credentials for scalers that need to authenticate to external systems, for example storing an AMQP connection string for RabbitMQ.**ClusterTriggerAuthentication**: A cluster-scoped variant of TriggerAuthentication, reusable across multiple namespaces.\n\nKEDA supports Deployments, ReplicaSets, StatefulSets, and Jobs. It runs across AWS EKS, GCP GKE, Azure AKS, and on-premises clusters without cloud-vendor lock-in.\n\n## How event-driven scaling works\n\nKEDA deploys three pods into your cluster: the KEDA Operator (`keda-operator`\n\n), the Metrics API Server (`keda-metrics-apiserver`\n\n), and the Admission Webhooks server (`keda-admission-webhooks`\n\n).\n\n### The KEDA Operator\n\nThe KEDA Operator watches for ScaledObject and ScaledJob CRDs. When you create a ScaledObject, the operator creates and manages an HPA resource targeting your specified Deployment. It polls external event sources continuously to determine whether scaling should activate or deactivate.\n\n### The Metrics API Server\n\nThe `keda-metrics-apiserver`\n\nimplements the `external.metrics.k8s.io`\n\nAPI. This bridges Kubernetes and external event sources so the HPA controller can query queue depths, Kafka consumer lag, or Prometheus values as if they were native cluster metrics. Therefore, HPA’s existing scaling logic applies without modification.\n\n### The Admission Webhooks\n\nThe `keda-admission-webhooks`\n\npod validates ScaledObject and ScaledJob CRDs at creation time. Before Kubernetes commits a ScaledObject to etcd, the webhook checks that the target resource exists and the trigger configuration is valid. It also verifies the referenced TriggerAuthentication is present. This means misconfigured ScaledObjects fail fast at apply time rather than silently misbehaving at runtime. All three pods must be healthy for KEDA to function correctly.\n\n### Scaling flow\n\n- You create a ScaledObject referencing a Deployment and a trigger, for example a RabbitMQ queue.\n- The Admission Webhook validates the ScaledObject before Kubernetes commits it.\n- The KEDA Operator detects the validated ScaledObject and creates an HPA targeting the Deployment.\n- The Metrics API Server queries the external event source for current queue depth.\n- HPA reads the metric via\n`external.metrics.k8s.io`\n\nand scales the Deployment accordingly. - When the queue empties, KEDA directly patches the Deployment replica count to 0, bypassing HPA’s minimum-1 constraint.\n\n### KEDA scalers\n\nA scaler is KEDA’s abstraction for connecting to an external event source. Each entry in a ScaledObject’s `triggers`\n\nlist corresponds to one scaler. KEDA ships with 70+ built-in scalers. Common examples include:\n\n**rabbitmq**: Scales on queue length or queue message rate.** kafka**: Scales on consumer group lag per topic.** aws-sqs-queue**: Scales on`ApproximateNumberOfMessagesVisible`\n\n.**prometheus**: Scales on any PromQL query result.** azure-servicebus**: Scales on Azure Service Bus topic or queue depth.\n\nKEDA also supports custom scalers through the External Scaler gRPC interface, so you can connect KEDA to any internal or proprietary metric source.\n\n## Scale to zero and cold starts\n\nScale-to-zero is what makes KEDA materially different from HPA in cost terms. Here is exactly how it works.\n\n### How scale-to-zero works\n\nWhen all triggers in a ScaledObject report zero events (empty queue, zero lag, no metrics above threshold), KEDA patches the Deployment replica count directly to 0. This deliberately bypasses HPA. Standard HPA enforces a minimum of 1 replica and cannot eliminate idle pods. KEDA bypasses that constraint at the controller level.\n\nWhen a new event arrives, KEDA detects it on the next polling interval. It then sets replicas to 1, and HPA takes over for further scale-out based on the metric value. Note that when a Deployment is at 0 replicas, only KEDA polls at `pollingInterval`\n\n. The managed HPA does not activate until the first replica exists. This means the maximum wait time on the first event after scale-to-zero is one `pollingInterval`\n\n(default: 30 seconds, or 10 seconds in the example YAML below).\n\n### Cold-start implications\n\nScaling from 0 to 1 requires Kubernetes to schedule a pod, pull the container image (if not cached on the node), and complete initialization before processing begins. For queue-based workloads, the first messages in a burst typically experience a delay of a few seconds to over a minute, depending on image size and startup behavior.\n\nThis trade-off is acceptable for batch workers and background consumers. However, it is not acceptable for latency-sensitive request processors. Know your workload before enabling scale-to-zero.\n\n### Mitigations\n\n**Set** for latency-sensitive workloads. Reserve scale-to-zero for batch jobs and background consumers.`minReplicaCount: 1`\n\n**Optimize container images**: Use multi-stage builds and minimize layer count. Pre-pull images using a DaemonSet or node image caching policy.** Tune**: A longer cooldown (60-300 seconds) prevents rapid oscillation during intermittent bursts.`cooldownPeriod`\n\n**Use the KEDA-HTTP add-on** for HTTP workloads: it proxies and buffers incoming requests during the cold-start window, preventing dropped connections.\n\n## KEDA vs HPA\n\nKEDA does not replace HPA. It wraps and extends HPA. When you deploy a ScaledObject, KEDA creates and manages an HPA resource in the background. You get HPA scaling mechanics plus KEDA event triggers and scale-to-zero capability.\n\nFor a deeper look at HPA mechanics, see [What Is Kubernetes HPA and How Can It Help You Save on the Cloud?](https://cast.ai/blog/what-is-kubernetes-hpa-and-how-can-it-help-you-save-on-the-cloud/)\n\n### Comparison table\n\n| Feature | HPA | KEDA |\n|---|---|---|\n| Scale to zero | No (minimum 1 replica) | Yes |\n| Scaling signals | CPU, memory, custom metrics | 70+ external sources (queues, Kafka, Prometheus, etc.) |\n| Event-driven triggers | No | Yes |\n| Requires installation | No (built-in to Kubernetes) | Yes (Helm chart or operator YAML) |\n| Manages HPA under the hood | N/A | Yes |\n| Works with Kubernetes Jobs | No | Yes (ScaledJob) |\n| Best for | HTTP services, CPU-correlated workloads | Queue consumers, batch jobs, bursty event workloads |\n\n### When to use HPA\n\nUse HPA when your workload is an HTTP service that scales predictably with traffic. If CPU or memory correlates well with load and you never need scale-to-zero, HPA’s zero-installation setup wins on simplicity. Stateless API services are the canonical example.\n\n### When to use KEDA\n\nUse KEDA when your workload consumes from a queue, Kafka topic, or SQS stream. Choose KEDA when your workload sits idle for hours or has unpredictable burst patterns: queue consumers, batch jobs, and webhook processors all fit this profile. For these patterns, scale-to-zero alone often justifies the additional setup cost. In contrast, forcing a queue-based consumer through HPA’s CPU-based scaling produces poor results. CPU does not rise until workers are already processing messages, introducing unnecessary lag in scaling response.\n\n## ScaledObject YAML\n\nThe following example configures KEDA to scale a RabbitMQ consumer Deployment based on queue length. It includes all required resources: the Kubernetes Secret for credentials, the TriggerAuthentication CRD, and the ScaledObject itself.\n\n### Installing KEDA\n\nBefore applying ScaledObject resources, install KEDA into your cluster with Helm:\n\n```\nhelm repo add kedacore https://kedacore.github.io/charts\n# Pin chart version to avoid breaking changes.\n# Check https://github.com/kedacore/charts/releases for the latest stable release.\nhelm install keda kedacore/keda --namespace keda --create-namespace --version 2.14.0\n```\n\nThis deploys all three KEDA pods into a dedicated `keda`\n\nnamespace. Run `kubectl get pods -n keda`\n\nto confirm the operator, metrics server, and admission webhook are all running before proceeding.\n\n### Step 1: Create the Secret\n\n```\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\n  namespace: default\ntype: Opaque\ndata:\n  # Base64-encoded AMQP URI: amqp://user:password@rabbitmq:5672/vhost\n  host: <base64-encoded-amqp-uri>\n```\n\n### Step 2: Create the TriggerAuthentication\n\n```\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host        # Maps 'host' field to the rabbitmq scaler\n      name: keda-rabbitmq-secret\n      key: host\n```\n\nThe Kubernetes Secret pattern works for most environments. In production environments that use AWS IRSA, GCP Workload Identity, or Azure Managed Identity, KEDA’s `TriggerAuthentication`\n\nalso supports pod identity authentication, eliminating the need to store credentials in a Secret.\n\n**Warning:** If you have an existing HPA on this Deployment, remove it before applying the ScaledObject. Two controllers targeting the same Deployment will produce conflicting replica counts.\n\n### Step 3: Create the ScaledObject\n\n```\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1        # Explicit apiVersion avoids ambiguity with custom resources\n    kind: Deployment\n    name: rabbitmq-consumer\n  minReplicaCount: 0              # Scale to zero when queue is empty\n  maxReplicaCount: 20             # Maximum workers during peak load\n  pollingInterval: 10             # Check queue depth every 10 seconds\n  cooldownPeriod: 60              # Wait 60s after queue empties before scaling to 0\n  fallback:\n    failureThreshold: 3           # After 3 consecutive scaler failures, activate fallback\n    replicas: 1                   # Hold 1 replica when the scaler cannot reach RabbitMQ\n  triggers:\n    - type: rabbitmq\n      metadata:\n        protocol: amqp\n        queueName: orders         # Target queue name\n        mode: QueueLength         # Scale on total messages in queue\n        value: \"5\"                # 1 replica per 5 messages in queue\n      authenticationRef:\n        name: keda-trigger-auth-rabbitmq-conn\n```\n\nWith this configuration, KEDA checks the `orders`\n\nqueue every 10 seconds. Each group of 5 messages drives 1 additional replica, capped at 20 by `maxReplicaCount`\n\n. An empty queue triggers scale-to-zero after the 60-second cooldown. The `fallback`\n\nblock is critical for production: if RabbitMQ becomes unreachable for 3 consecutive poll intervals, KEDA holds 1 replica instead of defaulting to the last-known count, preventing silent failure when your event source goes down.\n\n### Step 4: Verify the setup\n\nAfter applying the ScaledObject, confirm KEDA is polling and the managed HPA was created:\n\n```\n# Check ScaledObject status, active trigger metrics, and any errors\nkubectl describe scaledobject rabbitmq-scaledobject\n\n# Confirm KEDA created a managed HPA targeting your Deployment\nkubectl get hpa -n default\n```\n\nThe `describe`\n\noutput shows the current replica count, the last scaler poll result, and any errors reaching the event source. The HPA listing confirms KEDA created the managed HPA for your Deployment. If the HPA is absent, the ScaledObject likely failed admission; check `kubectl describe scaledobject`\n\nevents for the specific reason.\n\n## How Cast AI complements KEDA\n\nKEDA solves the pod-count problem. However, correct replica counts alone do not eliminate Kubernetes resource waste. Cast AI’s 2026 State of Kubernetes Optimization Report found average CPU utilization at just 8% across 23,000+ production clusters, with CPU overprovisioning at 69%. Those numbers reflect inflated resource requests that persist even when KEDA scales pod counts correctly.\n\n### The layered scaling model\n\nCast AI and KEDA address different layers of the same problem:\n\n**Layer 1 (pods): KEDA** scales replica count from 0 to N based on queue depth, Kafka lag, or other event signals.**Layer 2 (nodes): Cast AI** provisions and removes nodes in response to scheduling pressure from KEDA-driven pod changes, selects cheapest instance types, and places consumer workers on spot instances automatically.**Layer 3 (right-sizing): Cast AI Workload Autoscaler** continuously right-sizes CPU and memory requests, ensuring KEDA-scaled pods land on nodes with minimal waste.\n\nThe right-sizing layer matters more than it appears. If your consumer pods request 2 CPU but routinely use 0.3, KEDA scaling to 10 replicas drives the cluster autoscaler to provision far more node capacity than the workload actually needs. Correcting those requests closes the loop between pod-level and node-level efficiency. For more on how automated right-sizing works in practice, see [Automated Workload Rightsizing with PrecisionPack](https://cast.ai/blog/automated-workload-rightsizing-precisionpack/).\n\n### Spot instance synergy\n\nKEDA-driven scale-to-zero workloads are strong candidates for spot instance placement. Queue consumers that tolerate termination and restart map cleanly to spot instance lifecycle. Cast AI’s spot management places KEDA-scaled workers on spot automatically, with fallback to on-demand when spot capacity is unavailable. Two cost levers compound: scale-to-zero eliminates idle costs, while spot pricing cuts active compute costs by 50-80%. Savings vary by workload type, cloud provider, region, and instance family; consistently interruptible workloads on major clouds typically achieve this range versus on-demand.\n\nKEDA is also available as a built-in add-on for clusters managed by Cast AI. For teams running 10 or more clusters, this is a meaningful operational difference. Cast AI owns the KEDA Helm lifecycle, version upgrades, and cluster-by-cluster configuration across your fleet. That means KEDA does not become a separate dependency tracked through your own deployment pipelines, and version drift across clusters is not your problem to manage.\n\n## Conclusion\n\nKEDA addresses a structural gap in Kubernetes autoscaling: workloads that need external event signals to scale correctly and must reach zero replicas when idle. For queue consumers, Kafka processors, and batch workers, KEDA is the practical choice over HPA alone. The setup is a Helm install and a few dozen lines of YAML.\n\nThe broader Kubernetes cost problem requires multiple layers working together. KEDA drives replica count from 0 to N based on queue depth or event lag. Cast AI responds by provisioning nodes and placing workers on spot instances, typically 50-80% below on-demand rates. Beyond cost, offloading node lifecycle management to Cast AI frees platform teams to focus on application delivery rather than infrastructure maintenance. It also right-sizes CPU and memory requests, which directly reduces how many nodes KEDA-scaled pods require. The result is a scaling loop that closes from event signal to instance type, without manual tuning at any layer.\n\nFor a full overview of Kubernetes autoscaling, including HPA, VPA, and cluster autoscaling mechanics, see [Guide to Kubernetes Autoscaling for Cloud Cost Optimization](https://cast.ai/blog/guide-to-kubernetes-autoscaling-for-cloud-cost-optimization/).\n\n**What is KEDA?**\n\nKEDA (Kubernetes Event-Driven Autoscaling) is an open-source, CNCF-graduated component that scales Kubernetes workloads based on external event signals such as queue depth, Kafka consumer lag, Prometheus metrics, and 70+ other sources. Microsoft and Red Hat created it. KEDA graduated from the CNCF on August 22, 2023. It extends Kubernetes HPA by adding event-driven triggers and the ability to scale workloads to zero replicas when no events are pending.\n\n**KEDA vs HPA: what is the difference?**\n\nHPA scales workloads based on CPU and memory metrics built into the Kubernetes cluster. KEDA extends HPA to scale on external event sources such as queue depth and Kafka lag, and it adds scale-to-zero capability that HPA cannot provide. In practice, KEDA wraps HPA: when you create a ScaledObject, KEDA creates and manages an HPA resource under the hood. Use HPA for CPU-correlated HTTP services. Use KEDA for queue consumers, batch workers, and any workload that needs to scale to zero when idle.\n\n**Can KEDA scale to zero?**\n\nYes. When all triggers in a ScaledObject report zero events, KEDA patches the Deployment replica count directly to 0. This bypasses HPA’s minimum-1 replica constraint. When a new event arrives, KEDA detects it on the next polling interval and restores replicas to 1, after which HPA manages further scale-out. Note that scaling from zero introduces a cold-start delay while the new pod schedules and initializes.\n\n**What event sources does KEDA support?**\n\nKEDA includes 70+ built-in scalers. These cover messaging systems (RabbitMQ, Kafka, AWS SQS, Azure Service Bus, Google Pub/Sub), databases, CI/CD systems, observability tools (Prometheus, Datadog), HTTP traffic, and more. Custom event sources are also supported through the External Scaler gRPC interface, allowing integration with any internal or proprietary metric system.\n\n**Does KEDA replace HPA?**\n\nNo. KEDA wraps and extends HPA rather than replacing it. When you create a ScaledObject, KEDA creates a corresponding HPA resource and manages it automatically. You get all of HPA’s existing scaling mechanics plus KEDA’s external event triggers and scale-to-zero capability. For workloads already using HPA with CPU metrics, adding KEDA is additive, not disruptive.", "url": "https://wpnews.pro/news/keda-how-event-driven-autoscaling-cuts-kubernetes-cost", "canonical_source": "https://cast.ai/blog/keda-kubernetes-event-driven-autoscaling/", "published_at": "2026-07-15 09:50:38+00:00", "updated_at": "2026-07-15 09:51:48.890525+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools"], "entities": ["KEDA", "Microsoft", "Red Hat", "CNCF", "Cast AI", "Kubernetes", "HPA"], "alternates": {"html": "https://wpnews.pro/news/keda-how-event-driven-autoscaling-cuts-kubernetes-cost", "markdown": "https://wpnews.pro/news/keda-how-event-driven-autoscaling-cuts-kubernetes-cost.md", "text": "https://wpnews.pro/news/keda-how-event-driven-autoscaling-cuts-kubernetes-cost.txt", "jsonld": "https://wpnews.pro/news/keda-how-event-driven-autoscaling-cuts-kubernetes-cost.jsonld"}}