Autoscaling a .NET API sounds simple:
Traffic increases
↓
More CPU
↓
More Pods
But CPU is not always the best signal for application demand.
Consider an API that accepts requests and places work onto a message queue:
Client
↓
ASP.NET Core API
↓
Message Queue
↓
Background Worker
↓
Database
The API may have relatively low CPU utilization while the queue is growing rapidly.
A CPU-based Horizontal Pod Autoscaler (HPA) may therefore have little reason to add replicas.
This is where event-driven autoscaling becomes useful.
KEDA, or Kubernetes Event-driven Autoscaling, integrates external event sources with Kubernetes autoscaling. KEDA can monitor event sources and feed metrics to the Kubernetes HPA; it also handles activation and deactivation around zero replicas.
This article compares a native Kubernetes HPA approach with KEDA for an event-driven .NET workload and develops a benchmark methodology based on:
Scaling latency
Queue backlog
Request latency
Throughput
Replica count
CPU and memory
Scale-down behavior
Resource consumption
The goal is not to claim that KEDA is universally faster.
The goal is to determine which scaling signal produces better behavior for a particular workload.
HPA and KEDA Solve Different Problems
Kubernetes HPA automatically adjusts the replica count of a scalable workload according to configured metrics. The autoscaling/v2 API supports resource, custom, and external metrics.
A traditional HPA might look like:
CPU utilization
↓
HPA
↓
Deployment replicas
KEDA introduces an event-aware layer:
Queue / Event Source
↓
KEDA
↓
HPA
↓
Deployment replicas
KEDA's current architecture uses its operator for 0-to-1 and 1-to-0 activation/deactivation, while the Kubernetes HPA handles 1-to-N scaling based on metrics exposed by KEDA.
Therefore, a fair comparison is:
| Approach | Primary Scaling Signal | Scale to Zero | Best Fit |
|---|---|---|---|
| HPA | CPU, memory, custom/external metrics | Possible in specific configurations | Resource-driven workloads |
| KEDA | Event-source metrics | Yes, for supported ScaledObject scenarios | Event-driven workloads |
| HPA + custom metrics | Application/event metric | Depends on configuration | Custom application demand |
| KEDA + HPA | Event metric exposed through KEDA | Yes | Queue/event workloads |
The Benchmark Workload
Use a simple .NET architecture:
┌──────────────┐
│ Load Generator│
└──────┬───────┘
↓
┌──────────────┐
│ ASP.NET Core │
│ API │
└──────┬───────┘
↓
┌──────────────┐
│ Message Queue│
└──────┬───────┘
↓
┌──────────────┐
│ .NET Worker │
└──────┬───────┘
↓
┌──────────────┐
│ PostgreSQL │
└──────────────┘
For the benchmark, the worker is the important component.
The worker consumes messages from the queue and performs a controlled amount of processing.
This makes queue depth a meaningful scaling signal.
Why CPU Alone Can Be Misleading
Suppose the queue contains:
10,000 messages
but the worker is waiting on I/O.
CPU might remain relatively low:
CPU = 25%
Queue = 10,000
An HPA configured for:
CPU target = 70%
may not scale.
KEDA can instead use the queue depth as the scaling signal.
Conceptually:
Queue:
10,000 messages
↓
KEDA
↓
Desired replicas increase
↓
More workers
↓
Queue drains faster
This is the central hypothesis of the benchmark.
Build the .NET Worker
A simplified worker could use the .NET BackgroundService abstraction:
public sealed class OrderWorker(
IMessageConsumer consumer,
IOrderProcessor processor)
: BackgroundService
{
protected override async Task ExecuteAsync(
CancellationToken stoppingToken)
{
await foreach (
var message in consumer.ReadAsync(
stoppingToken))
{
await processor.ProcessAsync(
message,
stoppingToken);
}
}
}
The production implementation depends on the selected queue technology.
The benchmark should keep the worker implementation identical between HPA and KEDA experiments.
Only the scaling mechanism should change.
Add Controlled Processing Time
For a reproducible experiment, the worker can perform deterministic work.
For example:
public sealed class OrderProcessor
{
public async Task ProcessAsync(
OrderMessage message,
CancellationToken cancellationToken)
{
await Task.Delay(
TimeSpan.FromMilliseconds(100),
cancellationToken);
// Perform deterministic test work.
}
}
This is a benchmark mechanism, not a recommendation for production processing.
The purpose is to create a controllable service time.
Define the HPA Configuration
A resource-based HPA can target CPU utilization:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: order-worker
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: order-worker
minReplicas: 1
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
The autoscaling/v2 API supports configurable scaling behavior and multiple metrics. Kubernetes calculates the desired replica count from the relationship between the observed metric and configured target.
Resource Requests Matter
CPU utilization-based HPA depends on CPU resource requests.
For example:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
If resource requests are missing, CPU utilization may not be defined for the relevant HPA calculation. Kubernetes explicitly documents this behavior.
Therefore, resource requests must be part of the benchmark configuration.
Define the KEDA ScaledObject
KEDA uses a ScaledObject to connect a workload to an event source.
A simplified structure is:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-worker
spec:
scaleTargetRef:
name: order-worker
minReplicaCount: 0
maxReplicaCount: 20
pollingInterval: 5
triggers:
- type: rabbitmq
metadata:
queueName: orders
mode: QueueLength
value: "10"
The exact trigger metadata depends on the event source and KEDA scaler being used.
KEDA's ScaledObject defines the target workload, replica bounds, polling behavior, and triggers. The current KEDA documentation describes pollingInterval as the interval used to check trigger sources, with a default of 30 seconds.
For benchmarking, explicitly configure the interval instead of relying on an implicit default.
KEDA's Two Scaling Phases
Understanding KEDA's scaling model is essential.
There are effectively two phases:
0 ↔ 1 replicas
↓
KEDA activation
1 ↔ N replicas
↓
Kubernetes HPA
KEDA handles activation around zero replicas, while HPA handles scaling after the workload is active.
This makes KEDA particularly interesting for workloads that can remain idle.
Benchmark Question #1: How Fast Does Scaling Begin?
The first metric should be:
Scale-up latency
Define:
T0 = load spike begins
T1 = scaling signal becomes active
T2 = new Pod starts
T3 = new Pod becomes Ready
T4 = new Pod processes useful work
Then measure:
T4 - T0
This is more useful than measuring only:
HPA updated replicas
because a desired replica count does not mean the new Pod is ready to process requests.
Benchmark Question #2: How Fast Does the Queue Drain?
Record:
Initial queue depth
Peak queue depth
Queue depth over time
Time to return below threshold
For example:
Queue Depth
│
│ █
│ █ █
│ █ █
│ █ █
│____█_______█________
Time
The important measurement is not simply the maximum number of replicas.
It is how effectively the system responds to backlog.
Benchmark Question #3: Does CPU HPA React Too Late?
Consider:
Queue:
0 → 10,000
CPU:
30% → 40%
A CPU-based HPA may not scale aggressively.
KEDA sees:
Queue:
10,000
and can use that event metric directly.
The experiment should determine whether this translates into:
Lower queue latency
+
Faster backlog recovery
without causing excessive resource usage.
Benchmark Question #4: Does KEDA Over-Scale?
Event metrics can also create aggressive scaling.
Suppose:
Queue = 10,000
and:
Target = 10 messages/replica
The autoscaler can request a large number of replicas, bounded by the configured maximum.
KEDA's documentation explains that trigger metrics ultimately feed HPA calculations, with AverageValue and Value metric types producing different replica calculations.
Therefore, measure:
Desired replicas
Actual replicas
Queue depth
Processing throughput
together.
Benchmark Question #5: What Happens When the Load Stops?
Scale-down behavior is equally important.
Create:
Load spike
↓
Queue grows
↓
Workers scale out
↓
Load stops
↓
Queue drains
↓
Workers scale down
Measure:
Last message processed
↓
Replica reduction
↓
Minimum replica count
Kubernetes HPA has configurable scale-down behavior and stabilization windows. The documented default scale-down stabilization window is 300 seconds when no custom behavior is specified.
KEDA can pass HPA behavior configuration through its ScaledObject.
Benchmark Question #6: Does Scale-to-Zero Save Resources?
For an intermittent workload, compare:
HPA:
minReplicas = 1
with:
KEDA:
minReplicaCount = 0
Measure:
Idle CPU
Idle memory
Replica-hours
Startup latency
First-message latency
Do not claim a universal cost saving.
The actual result depends on:
Pod resource requests
Cluster capacity
Workload frequency
Cloud pricing
Startup time
Minimum replicas
Benchmark the Cold Start
Scale-to-zero introduces a trade-off.
Before the event:
Replicas = 0
A new event arrives:
Event
↓
KEDA detects activity
↓
Deployment scales
↓
Pod starts
↓
Readiness passes
↓
Work begins
The first event can therefore experience additional latency.
Measure:
Event arrival
↓
First Pod ready
↓
First successful processing
This is one of the most important metrics in the KEDA benchmark.
Benchmark Warm Scaling
Then repeat the experiment with:
minReplicaCount = 1
Now there is already a running worker.
Compare:
Cold:
0 → 1
Warm:
1 → N
This separates scale-to-zero startup cost from ordinary horizontal scaling.
Test Different Queue Depths
Do not test one backlog size.
Use a matrix such as:
100 messages
1,000 messages
10,000 messages
100,000 messages
The exact values should be chosen based on the capacity of the test environment.
For each run, measure:
Scale-up time
Peak replicas
Drain time
P95 processing latency
CPU
Memory
Test Different Arrival Rates
Queue depth is not the only variable.
Test:
10 messages/sec
100 messages/sec
500 messages/sec
1,000 messages/sec
The appropriate rates depend on the workload.
The important relationship is:
Arrival rate
vs
Processing rate
If:
Arrival rate > Processing rate
the queue will continue growing unless scaling increases capacity.
Calculate Required Processing Capacity
Suppose one worker processes:
10 messages/sec
and incoming traffic is:
100 messages/sec
The theoretical steady-state requirement is:
100 / 10 = 10 workers
This is not a production capacity guarantee.
It is simply a baseline for the experiment.
Real systems also need to account for:
Startup time
Failures
Retries
I/O latency
Uneven work
Queue semantics
Database capacity
Benchmark With Database Pressure
A worker often does more than consume messages.
It may execute:
Read
Transform
Write
against a database.
Therefore, add PostgreSQL or another production-relevant datastore to the benchmark.
Measure:
Worker replicas
+
Database CPU
+
Database connections
+
Query latency
An autoscaler can improve queue throughput while simultaneously overwhelming the database.
That is an autoscaling failure, not a success.
The Database Connection Trap
Suppose each .NET worker creates:
10 database connections
and autoscaling produces:
20 workers
The database may suddenly receive:
200 connections
Scaling the application does not automatically mean the database can scale at the same rate.
Therefore, include database connection pressure in the benchmark.
Benchmark Backpressure
A production system needs a maximum sustainable rate.
Consider:
Queue
↓
Worker
↓
Database
If the database becomes saturated:
Database latency ↑
↓
Worker throughput ↓
↓
Queue depth ↑
↓
Autoscaler adds workers
↓
Database pressure ↑
This is a positive feedback loop.
More replicas can make the problem worse.
Therefore, the benchmark should test the system near and beyond its sustainable capacity.
Benchmark Maximum Replica Limits
Configure:
maxReplicaCount: 20
Then create a load that requires more than 20 replicas.
Observe:
Queue continues growing
+
Replicas remain capped
This verifies that the safety boundary works.
A maximum replica count is not merely a cost-control setting.
It can protect downstream systems.
Benchmark HPA Behavior
Kubernetes HPA operates as a control loop. The default controller synchronization period is 15 seconds, although this is configurable.
Therefore, do not interpret autoscaling as instantaneous.
A useful timeline is:
Load changes
↓
Metric changes
↓
Metric becomes observable
↓
HPA evaluates
↓
Desired replicas change
↓
Scheduler places Pods
↓
Container starts
↓
Readiness passes
↓
Traffic/work distribution changes
Every stage contributes latency.
Benchmark KEDA Polling
KEDA's default pollingInterval is 30 seconds, but it can be configured per ScaledObject.
For example:
spec:
pollingInterval: 5
This does not mean the complete scaling operation will always finish within five seconds.
It means KEDA checks the trigger according to that polling configuration.
The rest of the control path still matters.
Do Not Set Polling to an Arbitrarily Low Value
Lower polling intervals can increase responsiveness, but they can also increase load on the event source and KEDA infrastructure.
Test:
5 seconds
10 seconds
30 seconds
and measure:
Scale latency
Event-source query rate
KEDA resource consumption
Choose the lowest interval that provides meaningful operational value.
Benchmark the HPA Metrics Path
For CPU-based HPA, verify that metrics are actually available.
Run:
kubectl top pods
Then inspect:
kubectl get hpa
For more detail:
kubectl describe hpa order-worker
Look for:
Current Metrics
Desired Replicas
Current Replicas
Conditions
Events
Kubernetes documents that HPA commonly obtains resource metrics through the Metrics Server and can also consume custom and external metrics through the corresponding APIs.
Inspect KEDA Metrics
KEDA exposes external metrics through its metrics API.
For example:
kubectl get --raw \
"/apis/external.metrics.k8s.io/v1beta1/namespaces/default/..."
KEDA documents this API path for inspecting external metrics associated with ScaledObject resources.
This is useful when:
Queue grows
but
replicas do not increase
You can determine whether the problem is:
Event source
↓
KEDA scaler
↓
External metric
↓
HPA
↓
Deployment
Create a Failure Scenario
A good benchmark should include failure injection.
For example:
Queue service unavailable
Then observe:
KEDA metric unavailable
HPA behavior
Fallback behavior
Replica count
Application availability
KEDA supports fallback configuration for scaler failures, allowing a defined replica behavior after a configured number of consecutive scaler failures.
Do not enable fallback blindly.
Define what behavior is safe for the particular workload.
Test Queue Recovery
Simulate:
Queue available
↓
Traffic spike
↓
KEDA scales
↓
Queue becomes unavailable
↓
Queue recovers
Measure:
Recovery detection
Replica behavior
Message processing
Error rate
A production autoscaler should not merely handle the happy path.
Test Duplicate Scalers
Do not accidentally configure:
HPA
+
KEDA ScaledObject
to independently manage the same workload.
KEDA's documentation warns against having multiple autoscaling resources compete for the same workload. Its current documentation also provides a mechanism to transfer ownership of an existing HPA to a ScaledObject when migrating to KEDA.
A clean architecture is:
One workload
↓
One scaling authority
with KEDA managing the generated HPA when KEDA is being used for that workload.
Compare the Two Configurations
HPA Configuration
Deployment
↓
CPU metric
↓
HPA
↓
Replica count
KEDA Configuration
Deployment
↓
ScaledObject
↓
Event source
↓
KEDA
↓
External metric
↓
HPA
↓
Replica count
The KEDA architecture introduces additional components, but it provides event-aware scaling capabilities.
Benchmark Matrix
Use a matrix like this:
| Test | HPA CPU | KEDA Queue |
|---|---|---|
| Idle replicas | Measure | Measure |
| 100-message burst | Measure | Measure |
| 1,000-message burst | Measure | Measure |
| Large burst | Measure | Measure |
| Sustained arrival | Measure | Measure |
| Scale-up latency | Measure | Measure |
| Queue drain time | Measure | Measure |
| P95 processing latency | Measure | Measure |
| Peak replicas | Measure | Measure |
| CPU | Measure | Measure |
| Memory | Measure | Measure |
| Scale-down time | Measure | Measure |
| Cold-start latency | N/A if min=1 | Measure |
| Event-source overhead | N/A | Measure |
This gives you a much stronger comparison than simply recording replica counts.
Example Results Template
Do not publish fabricated benchmark numbers.
Populate the table from your environment:
| Scenario | Strategy | Scale-Up Time | Peak Pods | Queue Drain | P95 Latency | CPU | Memory |
|---|---|---|---|---|---|---|---|
| Small burst | HPA | Measure | Measure | Measure | Measure | Measure | Measure |
| Small burst | KEDA | Measure | Measure | Measure | Measure | Measure | Measure |
| Large burst | HPA | Measure | Measure | Measure | Measure | Measure | Measure |
| Large burst | KEDA | Measure | Measure | Measure | Measure | Measure | Measure |
| Sustained load | HPA | Measure | Measure | Measure | Measure | Measure | Measure |
| Sustained load | KEDA | Measure | Measure | Measure | Measure | Measure | Measure |
The environment should be documented alongside the results.
How to Interpret the Results
Suppose the benchmark shows:
KEDA
Lower queue drain time
Higher peak replicas
Higher CPU consumption
That does not automatically mean KEDA is better.
It means KEDA responded more aggressively.
Whether that is desirable depends on the application's objective.
If the priority is:
Minimize queue latency
the result may be positive.
If the priority is:
Minimize compute cost
the same result may be undesirable.
Use SLOs Instead of "Fastest"
Define the objective before running the benchmark.
For example:
P95 processing latency < target
Queue age < target
Error rate < target
Maximum replicas <= limit
Then compare each strategy against those constraints.
This turns the benchmark into an engineering decision rather than a feature competition.
When HPA Is the Better Choice
Native HPA is often appropriate when workload demand correlates strongly with:
CPU
Memory
Custom application metrics
External metrics
For example:
HTTP API
↓
CPU increases with request volume
↓
HPA
Kubernetes HPA already supports resource, custom, and external metrics.
If CPU is a reliable proxy for demand, adding KEDA may provide little additional value.
When KEDA Is the Better Choice
KEDA becomes particularly attractive when demand is naturally represented by an event source:
Queue depth
Message lag
Stream backlog
External event count
KEDA maintains a large collection of built-in scalers for different event sources and also supports custom scaler integrations.
For a queue-driven worker:
Queue depth
can be much more meaningful than:
CPU utilization
When KEDA Is Not the Right Answer
Do not introduce KEDA simply because it is popular.
If your workload is:
HTTP request driven
CPU bound
Always active
native HPA may be sufficient.
Similarly, if the application requires:
Low cold-start latency
scale-to-zero may not be appropriate.
Autoscaling strategy should follow workload characteristics.
Production Considerations
Database Capacity
More workers can create more database connections and queries.
Message Ordering
Scaling consumers can affect ordering semantics.
Retry Behavior
More replicas can increase retry traffic during dependency failures.
Dead-Letter Queues
A failed scaling or processing scenario should not create uncontrolled retry loops.
Idempotency
Messages may be delivered more than once depending on the messaging system.
Startup Time
Cold-start latency directly affects scale-to-zero usefulness.
Maximum Replicas
Protect downstream dependencies with sensible limits.
Observability
Monitor the queue, replicas, processing latency, and dependencies together.
Common Mistakes
Comparing Replica Counts Only
More replicas are not automatically better.
Using CPU for an Event-Driven Workload
CPU may be a poor proxy for backlog.
Ignoring Queue Age
Queue depth alone can be misleading if messages have different processing times.
Ignoring Cold Starts
Scale-to-zero can introduce startup latency.
Setting Polling Too Aggressively
More frequent event-source polling can create unnecessary overhead.
Running HPA and KEDA Independently
Two controllers competing for the same workload can create unpredictable scaling behavior.
Ignoring Downstream Capacity
Autoscaling workers can overload the database or another dependency.
Testing Only Small Bursts
Large sustained workloads reveal different scaling behavior.
Measuring Only Average Latency
Tail latency often exposes overload conditions.
Publishing Unreproducible Numbers
Benchmark results require hardware, software, workload, and configuration details.
Troubleshooting
HPA Does Not Scale
Check:
kubectl describe hpa order-worker
Then verify:
Metrics available
CPU requests configured
Target utilization
Current utilization
Maximum replicas
Kubernetes documents that CPU utilization calculations depend on resource requests.
KEDA Does Not Scale
Check:
kubectl get scaledobject
Then:
kubectl describe scaledobject order-worker
Inspect:
Ready
Active
Fallback
Trigger
Metric
Queue Is Growing but Replicas Stay Constant
Trace the complete path:
Queue
↓
KEDA scaler
↓
External metric
↓
HPA
↓
Deployment
KEDA's metrics API can help determine whether the event metric is actually being exposed.
KEDA Scales Too Aggressively
Check:
Target metric
Polling interval
Max replicas
HPA behavior
Queue characteristics
Also inspect whether multiple triggers are producing different desired replica counts.
KEDA can use multiple triggers in a ScaledObject, with HPA ultimately selecting the highest desired replica recommendation among the metrics.
Pods Scale but Queue Does Not Drain
Investigate the downstream bottleneck:
Database
External API
CPU
Network
Message broker
More replicas do not help if every replica waits on the same constrained dependency.
Best Practices
Choose a scaling signal that represents actual workload demand.
Use CPU-based HPA when CPU is a reliable demand proxy.
Use KEDA when external events are the better signal.
Measure scale-up latency.
Measure time-to-first-useful-work.
Measure queue drain time.
Measure P95 and P99 processing latency.
Measure peak replica count.
Measure CPU and memory consumption.
Test cold and warm scaling separately.
Test sustained load as well as bursts.
Test multiple queue depths.
Test multiple arrival rates.
Configure sensible maximum replicas.
Protect downstream dependencies.
Test scaler failure behavior.
Avoid competing HPA and KEDA controllers.
Keep the application implementation identical between benchmark scenarios.
Document polling intervals and HPA behavior.
Never publish benchmark numbers without documenting the environment.
Frequently Asked Questions
Is KEDA a replacement for HPA?
Not exactly.
KEDA commonly integrates with Kubernetes HPA. KEDA handles event-source integration and activation around zero, while HPA handles scaling decisions for active workloads.
Can HPA scale based on queue length?
HPA supports custom and external metrics through Kubernetes metrics APIs. Therefore, queue-related metrics can be integrated with HPA if the required metrics infrastructure exists.
KEDA simplifies many event-source integrations by providing scalers for external systems.
Why would I use KEDA instead of CPU-based HPA?
Because CPU may not represent demand accurately.
For queue processing:
Queue depth
can be a more direct indicator of pending work than:
CPU utilization
Can KEDA scale to zero?
Yes, KEDA's activation model supports scaling workloads between zero and one replica for supported ScaledObject scenarios.
CPU and memory triggers have different limitations because metrics are unavailable when no Pods are running.
Does KEDA create an HPA?
For ScaledObject-based workload scaling, KEDA manages an HPA for the target workload and feeds it metrics.
Should I use HPA and KEDA on the same Deployment?
Do not configure them as independent controllers for the same workload.
If migrating an existing HPA to KEDA, KEDA provides an ownership-transfer mechanism documented for that scenario.
What should I benchmark first?
Start with:
Scale-up latency
Queue drain time
P95 processing latency
Peak replicas
CPU
Memory
Then add failure and recovery scenarios.
Is KEDA always faster?
No.
Scaling performance depends on:
Metric source
Polling
HPA synchronization
Pod startup
Container image size
Application startup
Cluster capacity
Workload
Measure the complete path.
Does scale-to-zero always reduce cost?
Not necessarily.
It can reduce idle compute, but cold-start latency and workload frequency may make it inappropriate for some services.
Can KEDA overload my database?
Yes.
If queue depth causes aggressive scaling, every additional worker may create additional database traffic.
Database capacity must therefore be included in the scaling design.
Conclusion
KEDA and Kubernetes HPA should not be treated as competing products where one is universally better.
They provide different mechanisms for translating workload demand into Kubernetes replica counts.
Native HPA works well when metrics such as CPU, memory, or application-level metrics represent demand accurately. Kubernetes supports configurable scaling behavior and multiple metric sources through autoscaling/v2.
KEDA becomes particularly valuable when demand originates from external event sources such as queues and streams. Its architecture combines event-source monitoring with Kubernetes HPA and adds an activation path for scaling between zero and one replica.
For a .NET event-processing workload, the comparison should look like:
Workload
↓
┌───────────────┐
│ Event / Queue │
└───────┬───────┘
↓
┌─────────────────┐
│ Scaling Signal │
└───────┬─────────┘
↓
┌──────────────────────────┐
│ │
HPA CPU KEDA
│ │
↓ ↓
CPU utilization Queue/event metric
│ │
└──────────┬───────────────┘
↓
HPA
↓
.NET Workers
↓
Dependencies
The strongest benchmark does not ask:
"Which autoscaler is faster?"
It asks:
"Which scaling strategy keeps my workload
within its SLO while using an acceptable
amount of infrastructure?"
That means measuring:
Scale-up latency
Queue drain time
P95/P99 latency
Peak replicas
CPU
Memory
Cold-start latency
Scale-down behavior
Dependency pressure
Failure recovery
Most importantly, do not optimize the autoscaler in isolation.
If adding replicas reduces queue depth but overwhelms PostgreSQL, the system has not become more resilient.
If scale-to-zero reduces idle resources but introduces unacceptable first-request latency, the configuration may not be appropriate.
The correct result is therefore workload-specific.
Benchmark the signal, the scaling loop, the application, and its dependencies together.
That is the difference between configuring autoscaling and engineering an autoscaling system.
Join the conversation! Your thoughts help the community grow.