Kubernetes autoscaling cost optimization is not a single dial you turn. It operates at three distinct levels, and each one either saves money or leaks it depending on how well it is configured. According to the Cast AI 2026 State of Kubernetes Optimization Report, the average production cluster runs at 8% CPU utilization. That number reveals the problem clearly: autoscaling is running, but it is not cutting idle capacity fast enough to matter.
88% of organizations report a year-over-year rise in Kubernetes total cost of ownership (Spectro Cloud/Adience 2025), and 42% cite cost as their top Kubernetes challenge. The tooling exists to fix this. HPA, VPA, Cluster Autoscaler, Karpenter, and KEDA each solve a distinct part of the scaling problem. Used together and configured correctly, they can deliver 40-70% compute cost reduction. Used at defaults, they amplify waste instead of eliminating it.
This guide explains how each autoscaler works, when to use it, and how to configure it for cost efficiency without compromising reliability.
Key takeaways #
- Kubernetes autoscaling operates at three levels: pod (HPA, VPA), node (Cluster Autoscaler, Karpenter ), and event-driven (KEDA). Each layer is necessary; none is sufficient alone.
- The average production cluster over-provisions CPU by 69% and memory by 79%. Fixing resource requests before tuning autoscalers is the highest-leverage action available.
- HPA with Karpenter is the most common production baseline for stateless workloads. Karpenter provisions nodes in 45-60 seconds versus 3-4 minutes for Cluster Autoscaler.
- VPA is safest in
Offmode for recommendations only.Recreatemode evicts pods and can disrupt production traffic without careful PodDisruptionBudget configuration. - KEDA enables true scale-to-zero for event-driven workloads using 70+ built-in scalers. It graduated from CNCF in August 2023.
- Wrong resource requests make every autoscaler less effective. HPA targets a percentage of requested resources, not actual cluster capacity.
- With proper autoscaling and rightsizing combined, 40-70% compute cost reduction is achievable in production clusters.
The three levels of Kubernetes autoscaling #
Kubernetes autoscaling operates on three distinct planes. Understanding the boundary of each prevents configuration mistakes that waste money.
Pod scaling adjusts what runs inside a node. HPA adds or removes pod replicas based on observed metrics. VPA adjusts the CPU and memory requests for individual pods without changing replica count. Both act on existing node capacity first.
Node scaling adjusts the infrastructure underneath your pods. Cluster Autoscaler and Karpenter add or remove nodes based on pending pods and utilization. Node autoscaling without pod autoscaling produces over-provisioned nodes. Pod autoscaling without node autoscaling produces pending pods and delayed scale-up.
Event-driven scaling bridges workloads to external signals. KEDA watches queues, streams, and custom metrics to scale workloads that do not map well to CPU or memory targets. This level enables scale-to-zero, which neither HPA nor VPA can achieve on their own.
The practical takeaway: run all three layers for most production clusters. Pod autoscaling ensures efficient bin packing. Node autoscaling ensures infrastructure matches actual demand. Event-driven scaling handles workloads that fall outside the CPU-centric model.
HPA: Horizontal Pod Autoscaler #
How HPA works
Kubernetes HPA watches metrics and adjusts replica count to keep those metrics near a configured target. The control loop runs every 15 seconds by default.
The core algorithm is straightforward: desiredReplicas = ceil(currentMetricValue / desiredMetricValue × currentReplicas). For example, if 3 replicas run at 80% CPU and the target is 60%, HPA scales to ceil(80/60 × 3) = 4 replicas.
HPA supports three metric types. Resource metrics (CPU and memory as a percentage of requests) are the default. Custom metrics expose application-level signals like request latency or queue depth. External metrics bring in data from outside the cluster, such as cloud provider load balancer metrics.
The critical detail: HPA targets a percentage of requested resources, not actual cluster capacity. Therefore, if a pod requests 100m CPU but consistently uses 2 CPUs, HPA reacts to the 100m baseline. Over-provisioned requests make HPA blind to real load changes.
HPA YAML: autoscaling/v2 with behavior policies
Prerequisites: metrics-server must be installed and healthy (kubectl top pods should return data). Many distributions omit it — install via: helm upgrade --install metrics-server metrics-server/metrics-server -n kube-system
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: api-server-hpa
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api-service
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 25
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
The behavior block is the most important part for cost control. The 300-second stabilization window prevents premature scale-down during transient load drops. The 25% per-minute scale-down rate limits how aggressively replicas drain. Scale-up keeps a zero stabilization window so the response to real load spikes stays immediate.
Verify
kubectl get hpa -n production
kubectl get pods -n kube-system -l k8s-app=metrics-server
Common HPA mistakes
Setting a 100% CPU target is the most common mistake. At 100% utilization, there is no headroom to absorb new requests before latency spikes. A target of 60-70% for web services and 70-80% for batch workloads gives HPA room to respond without over-reacting.
Setting minReplicas: 1 on a service that must handle traffic creates a single point of failure during node disruptions. Additionally, skipping maxReplicas allows runaway scaling during metric spikes caused by bugs rather than genuine load. Set both values intentionally.
Skipping the behavior block entirely leaves HPA with aggressive default scale-down. The default allows dropping to minReplicas as fast as the stabilization window permits, which causes thrashing during irregular traffic patterns and wastes node capacity in the process.
VPA: Vertical Pod Autoscaler #
VPA modes
Pod requests and limits change over time as VPA responds to actual resource consumption. Understanding the operating modes determines whether VPA becomes a useful advisor or a production risk. There are four modes to know, and one that should no longer be used.
Off: VPA generates recommendations but applies nothing. This is the safest starting mode. Use it to audit over-provisioning before committing to automation.
Initial: VPA applies recommendations only when pods start. Existing pods keep their current requests. This avoids mid-traffic evictions and works well for workloads that restart frequently or run in CI pipelines.
Recreate: VPA evicts pods when their current requests differ significantly from the recommendation. The eviction triggers a restart with updated requests. This is the current standard eviction-based update mode. However, it can disrupt production traffic if PodDisruptionBudgets are not configured correctly — define PDBs before enabling Recreate.
InPlaceOrRecreate: The InPlaceOrRecreate mode was introduced as an alpha feature in VPA 1.4.0+ and is described as alpha in VPA 1.7.0 by kubernetes.io. It requires Kubernetes 1.33+ (where the InPlacePodVerticalScaling cluster feature gate is beta and enabled by default), but also requires enabling the InPlaceOrRecreate feature gate on both the VPA updater and admission controller components. It reached stable in Kubernetes 1.35 for the underlying in-place resize capability. Auto mode was deprecated in VPA 1.4.0. For clusters on VPA below 1.4.0, use Recreate mode.
Auto (deprecated): Auto mode was deprecated in VPA 1.4.0. Do not use it in new clusters. It was superseded by InPlaceOrRecreate, which provides equivalent behavior with explicit semantics.
VPA Off-mode example: collect recommendations before applying
To start with VPA in Off mode and collect recommendations without applying them:
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: api-server-vpa
namespace: production
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: api-server
updatePolicy:
updateMode: "Off"
resourcePolicy:
containerPolicies:
- containerName: "*"
minAllowed:
cpu: 50m
memory: 64Mi
maxAllowed:
cpu: 4
memory: 4Gi
After 48 hours, check recommendations with:
kubectl describe vpa api-server-vpa -n production | grep -A 10 Recommendation
Running HPA and VPA together
For a detailed breakdown of when to use each tool individually, see the full HPA vs VPA comparison. For running them simultaneously, the key constraint is that HPA and VPA must not target the same metric. If HPA scales on CPU utilization and VPA adjusts CPU requests simultaneously, both tools chase each other’s changes and produce unstable replica counts.
The working pattern: set VPA to Off or Initial to manage request sizing, and configure HPA on custom application metrics (request rate, queue depth) rather than CPU. This gives VPA ownership of the resource baseline and gives HPA a stable, request-independent signal to react to.
Cluster Autoscaler vs Karpenter: Which Node Autoscaler Fits Your Cluster #
Cluster Autoscaler
The Kubernetes Cluster Autoscaler watches for pods stuck in Pending state and triggers node provisioning in the configured node group or auto-scaling group. It also removes underutilized nodes when their pods can be rescheduled elsewhere without violating constraints.
Cluster Autoscaler has two production-relevant constraints. First, it is node-group-aware: it must choose among pre-defined instance types per group, which limits bin-packing efficiency. Second, provisioning takes 3-4 minutes end-to-end across most cloud providers, which means Pending pods wait while HPA is already responding at the replica level.
However, Cluster Autoscaler is stable, widely supported, and integrates with every major managed Kubernetes service out of the box. For teams without capacity planning complexity, it remains a reasonable and fully supported default.
Karpenter
Picture a spike: 200 pods go Pending simultaneously after a traffic surge, and your node autoscaler needs 3-4 minutes to provision the first replacement node. That gap – between pod autoscaler reacting and new node capacity arriving – is precisely the problem Karpenter was built to close. Rather than polling pre-defined node groups, Karpenter watches pod scheduling constraints directly, selects the best-fit instance type from a wide pool at provisioning time, and computes bin-packing across all pending pods simultaneously. On AWS, it provisions in 45-60 seconds.
Karpenter’s consolidation feature removes underutilized nodes proactively. WhenEmptyOrUnderutilized consolidation merges workloads onto fewer nodes, terminates the vacated ones, and does so continuously rather than only when new pods are Pending. For clusters with variable workloads, this cuts idle node costs significantly.
Additionally, Karpenter’s spot instance handling is purpose-built. It selects from multiple instance families to maximize spot availability, handles interruption signals, and replaces spot instances with on-demand when necessary, all within a single NodePool configuration.
Comparison table: five-way decision matrix
For a full analysis of node autoscaler differences, see the Karpenter vs Cluster Autoscaler breakdown. The table below covers the decision-relevant differences across all five tools.
| Tool | What it scales | Trigger | Scale to zero | Best for | Key limitation |
|---|---|---|---|---|---|
| HPA | Pod replicas | CPU, memory, custom metrics | No (min 1 replica) | Stateless web services, APIs | Needs accurate resource requests to function correctly |
| VPA | Pod resource requests | Historical usage patterns | No | Right-sizing batch and stateful workloads | Evicts pods in Recreate mode; conflicts with CPU-based HPA |
| Cluster Autoscaler | Nodes | Pending pods, underutilization | Yes (to 0 nodes in a group; requires minCount=0 in node group – not the default on EKS, GKE, or AKS managed services) | Managed K8s (EKS, GKE, AKS) with simple node groups | 3-4 min provisioning; limited instance selection per group |
| Karpenter | Nodes | Pod scheduling constraints | Yes | AWS workloads needing fast provisioning and spot optimization | AWS-primary; requires more initial NodePool configuration |
| KEDA | Pod replicas (including to 0) | External event sources: queues, streams, cron | Yes (minReplica Count: 0) | Event-driven, batch, and async workloads | Requires external metric source; not designed for general CPU scaling |
Karpenter NodePool YAML
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: node.kubernetes.io/instance-type
operator: In
values: ["m5.xlarge", "m5.2xlarge", "m6i.xlarge", "m6i.2xlarge", "c5.xlarge", "c5.2xlarge"]
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 30s
budgets:
- nodes: "10%"
limits:
cpu: 1000
memory: 2000Gi
The budgets field limits concurrent disruptions to 10% of the NodePool at any time, protecting workloads during consolidation cycles. The consolidateAfter: 30s value triggers consolidation quickly after underutilization is detected, rather than waiting through a long idle period. When both spot and on-demand are included in the capacity-type requirement, Karpenter selects spot first because its provisioner applies cost-based optimization at scheduling time – the least-cost compatible instance type wins.
The NodePool above references an EC2NodeClass named default. That resource must also exist in your cluster. Here is a minimal EC2NodeClass with the required fields:
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2023
amiSelectorTerms:
- alias: al2023@latest # Amazon Linux 2023; pin to a specific AMI ID in production
role: "KarpenterNodeRole-${CLUSTER_NAME}"
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: "${CLUSTER_NAME}"
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: "${CLUSTER_NAME}"
Replace ${CLUSTER_NAME} with your actual cluster name before applying. The amiFamily, amiSelectorTerms, subnetSelectorTerms, securityGroupSelectorTerms, and role fields are all required. Consult the EC2NodeClass documentation for the full field reference.
Verify
kubectl get nodepool default
kubectl get nodes -l karpenter.sh/nodepool=default
KEDA: Kubernetes Event-Driven Autoscaling #
How KEDA works
KEDA extends Kubernetes scaling beyond CPU and memory. It graduated as a CNCF project in August 2023 and ships with 70+ built-in scalers covering AWS SQS, Azure Service Bus, Kafka, Prometheus, Redis, cron schedules, and more.
KEDA installs as a Kubernetes operator and creates an HPA object on your behalf. The KEDA operator polls the external metric source, converts the result to a Kubernetes metric, and lets the HPA control loop handle the actual scaling. Therefore, KEDA does not replace HPA; it extends HPA with external signal sources that the native controller cannot reach.
The most cost-relevant feature is scale-to-zero. By setting minReplicaCount: 0, a deployment drops to zero replicas when the queue or stream is empty. Karpenter or Cluster Autoscaler then removes the now-empty node. For batch and async workloads that run a few hours per day, this eliminates the cost of idle compute entirely. Scale-to-zero is covered in more detail in the FAQ section below.
The trade-off is cold-start latency: when scaling from zero, the first request waits for node provisioning (45-90 seconds with Karpenter) plus pod startup. For latency-sensitive services, keep minReplicaCount: 1. Reserve minReplicaCount: 0 for async batch and inference workloads where cold-start is acceptable.
KEDA ScaledObject YAML: SQS example
Prerequisites for the SQS example: identityOwner: operator delegates IAM to the KEDA operator’s ServiceAccount. Before applying this ScaledObject, configure IRSA for the KEDA operator:
- Create an IAM role with
sqs:ReceiveMessageandsqs:GetQueueAttributespermissions. - Annotate the KEDA operator’s ServiceAccount:
kubectl annotate serviceaccount keda-operator -n keda eks.amazonaws.com/role-arn=arn:aws:iam::ACCOUNT:role/keda-sqs-role - Restart the KEDA operator pods.
Alternatively, use identityOwner: pod to delegate IAM to the worker pods’ ServiceAccount instead.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: sqs-consumer-scaler
namespace: batch-jobs
spec:
scaleTargetRef:
name: sqs-consumer
minReplicaCount: 0
maxReplicaCount: 50
cooldownPeriod: 300
triggers:
- type: aws-sqs-queue
metadata:
queueURL: https://sqs.us-east-1.amazonaws.com/123456789/worker-queue
queueLength: "5"
awsRegion: us-east-1
identityOwner: operator
This configuration scales one replica per 5 messages in the queue, drops to zero when the queue empties, and waits 300 seconds before scaling down to avoid thrashing on intermittent message bursts. The identityOwner: operator setting uses KEDA’s own IAM role for SQS polling rather than the workload’s identity, which simplifies IAM policy management.
Verify
kubectl get scaledobject sqs-consumer-scaler -n batch-jobs
kubectl describe scaledobject sqs-consumer-scaler -n batch-jobs
Predictive and scheduled autoscaling #
Reactive autoscaling responds after demand arrives. For workloads with predictable patterns such as business hours traffic, end-of-month batch runs, or weekly report generation, predictive and scheduled scaling pre-provisions capacity before demand hits.
KEDA’s cron scaler is the simplest path to scheduled scaling. Define a cron expression and a target replica count, and KEDA sets that minimum before the traffic window opens. No custom metrics or external dependencies are required.
For more sophisticated prediction, the Kubernetes Predictive Horizontal Pod Autoscaler (PHPA) project fits historical metric patterns to forecast future demand and pre-scales accordingly. However, it requires careful tuning and works best when traffic follows consistent cycles with low variance.
Cast AI’s Workload Autoscaler includes predictive scaling as a managed capability. It analyzes workload history and pre-provisions replicas before anticipated spikes, which means the cluster absorbs load increases without the latency of reactive scale-up. For teams that want predictive behavior without operating a separate controller, this is a practical alternative to self-managed PHPA.
Kubernetes autoscaling cost optimization anti-patterns #
Most Kubernetes cost problems come from misconfiguration, not missing tools. These six anti-patterns are the most common causes of wasted compute in clusters that already have autoscaling running.
1. Setting CPU target at 100%. HPA needs headroom to respond before latency degrades. A 100% target means pods are saturated before HPA adds replicas. Use 60-70% for latency-sensitive services and 70-80% for batch workloads.
2. Autoscaling with wrong resource requests. HPA targets utilization relative to requested resources. If a pod requests 100m CPU but regularly uses 2 CPUs, HPA sees 2000% utilization and scales aggressively on metric noise. Conversely, a request bloated to 4 CPUs against 200m actual usage causes HPA to underreact during real load increases.
3. No scale-down stabilization window. Without a behavior block, HPA can scale down replicas during a 60-second load dip and trigger an immediate scale-up when load returns. The resulting thrashing wastes node capacity and causes latency spikes on every traffic fluctuation.
4. Ignoring node consolidation. Pod autoscaling reduces replica count, but nodes remain until Cluster Autoscaler or Karpenter removes them. Nodes in a scaled-down state that are never consolidated accumulate idle cost indefinitely. Enable consolidation explicitly; it is not active by default in most configurations.
5. Running VPA in Recreate mode without PodDisruptionBudgets. VPA in Recreate mode evicts pods immediately when it applies updated recommendations. Without PDBs specifying minAvailable, this can take down more replicas simultaneously than your service can tolerate. Define PDBs before enabling Recreate mode.
6. Treating autoscaling as a substitute for rightsizing. Autoscalers scale what you give them. If each pod is over-provisioned by 69% on CPU (the production average from Cast AI 2026 data), adding more pods multiplies the waste proportionally. Autoscaling and rightsizing are complementary, and rightsizing comes first.
Rightsize before you autoscale #
The Cast AI 2026 State of Kubernetes Optimization Report puts average CPU over-provisioning at 69% and memory over-provisioning at 79%. Average cluster CPU utilization across production environments sits at 8%. For GPU clusters, average utilization is 5%. These numbers reveal that most clusters pay for 10x or more compute than workloads actually consume.
Autoscaling on top of over-provisioned requests does not fix this. HPA reacts to utilization as a fraction of requested resources, not cluster capacity. If requests are 5x above actual consumption, HPA keeps replica counts lower than optimal and misses real demand signals. Karpenter provisions nodes sized to requested resources, not actual usage, so over-provisioned pods produce over-sized nodes regardless of how consolidation is configured.
The correct sequence: audit requests with VPA in Off mode, apply rightsized requests, then tune autoscaler targets against the corrected baselines. For teams that want this handled automatically, automated workload rightsizing adjusts requests continuously as workload patterns change, rather than requiring periodic manual audits that go stale between reviews.
With accurate requests in place, every downstream autoscaler works correctly. HPA sees real utilization signals. Karpenter provisions appropriately sized nodes. KEDA scales to zero on actual queue depth rather than on inflated CPU metrics. In practice, the improvement in autoscaler behavior from fixing requests typically exceeds the improvement from tuning the autoscalers themselves.
How Cast AI addresses the root cause #
Every autoscaler in this guide reacts to resource requests. If those requests are inaccurate, the autoscalers produce inaccurate results. Cast AI’s Workload Autoscaler solves the root cause: it continuously right-sizes CPU and memory requests based on actual workload behavior, so HPA, VPA, and Karpenter all operate on accurate baselines from the start.
For node autoscaling, Cast AI provides a managed Karpenter integration. It configures NodePools for spot-first provisioning, handles interruption management, and applies consolidation policies tuned to actual cluster workload patterns rather than static defaults. The result is faster provisioning, higher spot utilization, and continuous consolidation without manual NodePool tuning cycles.
For event-driven workloads, Cast AI integrates natively with KEDA. When KEDA scales a deployment to zero, Cast AI’s node autoscaler removes the underlying nodes. When KEDA scales back up, nodes provision in under a minute. Together, the two tools eliminate the idle compute cost that persists when scale-to-zero at the pod level is not matched by scale-to-zero at the node level.
Teams that combine Cast AI’s workload rightsizing with Karpenter-managed node autoscaling typically achieve 40-70% compute cost reduction without changes to application code or deployment pipelines. Learn more at the Cast AI Karpenter optimization page.
Conclusion #
The teams achieving 40-70% cost reduction are not running exotic tooling – they run standard Kubernetes autoscalers configured correctly, on top of accurate resource requests.
Start with resource request accuracy: deploy VPA in Off mode on your highest-cost workloads and review the recommendations after 48 hours. Then configure HPA or KEDA on your highest-traffic services using the decision table above. Finally, enable Karpenter or tune your Cluster Autoscaler’s scale-down thresholds. Each step compounds: rightsizing reduces node autoscaler overhead, HPA reduces peak replica count, and node consolidation eliminates the idle capacity that remains.
Kubernetes cost optimization
Monitor organization-wide and cluster-level resource spending. Automate resource allocation and scale instantly with zero downtime.
Frequently asked questions #
HPA vs VPA vs Cluster Autoscaler: what is the difference?
HPA scales pod replicas horizontally based on metrics like CPU utilization. VPA adjusts the CPU and memory requests of individual pods vertically, without changing replica count. Cluster Autoscaler operates at the infrastructure layer, adding and removing nodes based on pending pods and utilization. All three solve different parts of the capacity problem and are designed to run together in production clusters.
Karpenter vs Cluster Autoscaler: which should you use?
Karpenter provisions nodes in 45-60 seconds and selects the optimal instance type from a wide pool at provisioning time. Cluster Autoscaler takes 3-4 minutes and is constrained to pre-defined node groups. For AWS workloads requiring fast scale-up, spot optimization, and continuous consolidation, Karpenter is the better choice. Cluster Autoscaler remains suitable for teams on managed Kubernetes services who need a simple, fully supported option with minimal configuration.
Can you run HPA and VPA together?
Yes, but they must not target the same metric. If both HPA and VPA act on CPU simultaneously, they produce conflicting adjustments and unstable replica counts. The working pattern: set VPA to Off or Initial mode for request sizing, and configure HPA to scale on custom application metrics rather than CPU. This gives each tool a distinct domain and avoids interference.
What is KEDA?
KEDA (Kubernetes Event-Driven Autoscaling) is a CNCF graduated project that extends Kubernetes scaling to external event sources. It supports 70+ scalers including AWS SQS, Kafka, Azure Service Bus, Prometheus, and cron schedules. KEDA enables scale-to-zero by setting minReplicaCount to 0, which neither HPA nor VPA support natively. It works by creating and managing an HPA object using external metric values as the scaling signal.
Why is Kubernetes still expensive with autoscaling enabled?
The most common cause is over-provisioned resource requests. Autoscalers react to utilization as a percentage of requested resources, not actual cluster capacity. When requests are set 5x above actual usage (average CPU utilization across production clusters is 8% per Cast AI 2026 data), autoscalers underreact to real demand and overreact to metric noise. Additionally, node consolidation is often not enabled, leaving underutilized nodes running indefinitely after pods scale down.
What is scale to zero in Kubernetes?
Scale to zero means reducing a workload’s replica count to 0 when there is no demand, eliminating its compute cost entirely. Native HPA enforces a minimum of 1 replica. KEDA enables scale-to-zero by setting minReplicaCount: 0 in a ScaledObject. When combined with Karpenter’s node consolidation, scale-to-zero at the pod level triggers node removal as well, cutting cost to zero for idle event-driven workloads.