The Horizontal Pod Autoscaler (HPA) changes a pod’s replica count in response to load, while the Vertical Pod Autoscaler (VPA) changes a single pod’s CPU and memory allocation. Both only cut infrastructure cost when application load actually varies over time — for steady traffic, autoscaling adds operational complexity without real savings.
Quick Overview
What you’ll learn from this article:
- How HPA and VPA work, and how horizontal scaling differs from vertical scaling
- What implementing autoscaling really costs — in engineering time, not just infrastructure
- When autoscaling pays off, and when it’s unnecessary complexity
- A step-by-step plan for rolling out HPA/VPA on an existing cluster
Who this article is for: DevOps and SRE engineers responsible for Kubernetes infrastructure cost, architects planning application scalability, platform team leads evaluating autoscaling ROI.
Reading time: 7 minutes
Kubernetes autoscaling with HPA and VPA: what it really costs — and whether it’s worth it
HPA watches a metric (CPU usage by default, optionally memory or a custom metric from Prometheus) and increases or decreases pod replica count to keep that metric near a target value. VPA does something different — it doesn’t change pod count, it recommends (or automatically sets) the CPU and memory allocated to a single pod, based on the history of its actual usage. HPA and VPA shouldn’t both drive the same metric on the same resource at once (typically both on CPU) — that leads to a conflict where VPA resizes the pod and HPA reacts to that change with another scaling decision.
The cost of implementing autoscaling isn’t just the time it takes to configure an HPA or VPA object in the cluster — it’s mainly the engineering time spent choosing the right thresholds, testing behavior under real load, and building alerts for situations where the autoscaler reacts too aggressively (so-called flapping — continuous scaling up and down when load oscillates around a threshold). Teams that roll out HPA with default settings and no load testing often end up with an autoscaler that reacts too slowly to sudden traffic spikes or too aggressively to normal daily fluctuations.
When autoscaling pays off — and when it doesn’t
| Situation | Does autoscaling pay off? | Reasoning |
|---|---|---|
| Traffic with clear daily seasonality (e.g. a B2C application) | Yes | Replica count at night can drop several times over compared to the daily peak |
| Steady, predictable traffic (e.g. an internal company system) | No | Operational configuration cost exceeds the savings from a handful of extra pods |
| Application with a long startup time (cold start measured in minutes) | Partially | HPA reacts too slowly to sudden spikes — a buffer of minimum replicas is needed |
| Team without mature custom metrics monitoring | Not yet | Start with HPA on CPU/memory before rolling out Prometheus-based custom metrics |
How to roll out HPA and VPA step by step
- Start with HPA on a basic metric (CPU) for services with visible load variability over time — the simplest and best-documented scenario.
- Set a minimum and maximum replica count with a safety margin, not just a target metric value — no upper limit combined with an application bug can trigger uncontrolled cost growth.
- Test behavior under simulated load before deploying to production, watching for whether the autoscaler flaps under typical traffic fluctuations.
- Add VPA in recommendation-only mode (
OfforInitial) before enabling automatic mode — this lets you evaluate whether the suggested CPU/memory values make sense before VPA starts restarting pods to resize them. - Monitor infrastructure cost before and after rollout for at least one full load cycle (typically a week), to measure the real saving, not just the theoretical one.
VPA in automatic mode restarts a pod to apply the new resource allocation — an important difference from HPA, which adds or removes replicas without interrupting existing pods. Restarting a pod means a brief availability gap for that specific pod, which is why VPA in automatic mode requires enough replicas for traffic to be handled by the remaining pods during the restart — in practice, VPA is rarely used without HPA running alongside it, or at least a fixed minimum replica count greater than one.
Read Also
- Kubernetes and Docker: Automating Cloud Application Management - A Guide
- Production Kubernetes cluster rollout: A Complete Guide
Develop Your Skills
Want to roll out autoscaling on your Kubernetes cluster without costly configuration mistakes? Check out our training led by experienced EITT instructors.
➡️ Docker and Kubernetes: Building and Scaling Container Applications — EITT training ➡️ Kubernetes from Basics to Advanced Techniques — EITT training
Frequently Asked Questions (FAQ)
Can you use HPA and VPA at the same time on the same resource?
Not on the same metric — if both mechanisms drive CPU on the same container, the scaling decisions conflict. A safe pattern is VPA driving memory while HPA drives CPU (or a custom metric), or running VPA in recommendation-only mode.
How long does it take to roll out autoscaling on an existing cluster?
Configuring the HPA object itself is a matter of minutes, but choosing the right thresholds and testing behavior under real load usually takes a few days to two weeks, depending on the availability of a test environment and traffic-simulation tools.
Why does autoscaling sometimes increase cost instead of lowering it?
When thresholds are set too aggressively, or without an upper limit, the autoscaler can spin up far more replicas than actually needed — especially during an application bug that generates artificial load. Skipping load tests before rollout is the most common cause of unexpected cost.
Is VPA suitable for stateful applications?
With caution — the pod restart required by VPA in automatic mode can be costly for applications with a long state-initialization time (e.g. databases). For such workloads, recommendation-only mode with manually applied changes during a maintenance window is safer.