Kubernetes HPA on Amazon EKS: Scaling from 2 to 6 Pods Under Load

What happens when your application receives more traffic than its current capacity can handle?

While building LibraryCorner, my AWS Cloud/DevOps project, I tested Kubernetes Horizontal Pod Autoscaler (HPA) on Amazon EKS to see how the application would respond to increasing CPU utilization.

The result was more interesting than simply watching pods appear: the test demonstrated automatic scaling, observable performance changes, and a clearly defined capacity limit.

Here's what happened.

1. The setup

I configured Kubernetes HPA to scale the application between 2 and 6 pods, targeting 55% average CPU utilization.

The test followed the complete lifecycle:

• Start with two pods at rest.
• Gradually increase the load.
• Observe CPU utilization and application latency.
• Watch HPA scale out.
• Reach the configured capacity limit.
• Stop the load and observe recovery.

The objective wasn't just to increase the replica count. It was to verify that the system reacted to real metrics and returned to its initial state afterward.

2. From 2 pods to 6

At rest, the application ran with two pods and low resource utilization.

As the load increased, CPU utilization rose significantly. At the peak, it reached 216%, and HPA increased the number of replicas to four, then six.

The scaling process looked like this:

       Increasing traffic
               |
               v
       CPU utilization rises
               |
               v
       Kubernetes HPA reacts
               |
               v
          2 → 4 → 6 pods
               |
               v
       More application capacity

HPA uses observed metrics to calculate the desired replica count. Kubernetes then schedules and starts additional pods, provided the cluster has enough capacity.

The important detail is that scaling isn't instantaneous. New pods need time to start and become ready, so application latency can temporarily increase while demand rises.

That was visible in my test: latency degraded around the traffic peak, then returned to normal as additional pods became available.

3. The results: 15,000+ requests, zero failures

The load test produced encouraging results:

• 15,000+ requests
• Zero failed requests
• CPU utilization reached 216% at the peak
• Pod count increased from 2 to 6
• Latency remained below the configured alert threshold at the 95th percentile

The dashboard captured the entire sequence: traffic increased, latency rose, additional pods started, and performance recovered as the system scaled.

This is why I consider observability essential to autoscaling. The dashboard helped connect the HPA decisions to actual application behavior rather than just showing a changing replica count.

4. Why stop at six pods?

Six wasn't an arbitrary number.

At the time of the experiment, the cluster's node networking capacity limited the number of pods that could be scheduled. Increasing the HPA maximum beyond the available capacity could have left new pods pending.

I therefore configured the maximum at six and added an alert to signal when the workload reached that limit.

At peak load, the alert fired and a notification was emitted.

One important distinction: the alert did not trigger scaling. CPU metrics drove HPA. The alert simply indicated that the configured maximum had been reached and that additional capacity might be needed.

This is a useful operational signal: autoscaling can work exactly as configured and still reach a point where it cannot scale further.

5. Scaling back down

When the load stopped, the alert resolved automatically, and HPA returned the workload to two pods after the stabilization window.

That final step matters.

Autoscaling isn't just about adding replicas under pressure. It also needs to remove unnecessary replicas without reacting too aggressively to short-lived changes.

The complete lifecycle was:

Rest → Load → Scale out → Capacity alert → Recovery → Scale down

This validated three aspects of the project together: elasticity, observability, and automatic reactions based on metrics.

What I learned

This experiment reinforced three lessons:

1. Autoscaling depends on capacity. HPA can request more pods, but the cluster must have enough networking and compute resources to run them.

2. Monitoring makes behavior explainable. CPU, replica count, latency and alerts helped me understand what happened throughout the test.

3. Scaling needs end-to-end validation. Reaching six pods is not enough. You also need to check application errors, latency, recovery, and what happens when the maximum is reached.

Coming from QA and validation, this last point feels natural to me: I want to verify the complete behavior, not just whether a Kubernetes resource has the expected status.

Final thoughts

My LibraryCorner load test demonstrated that HPA could scale the application from two to six pods, handle more than 15,000 requests without failures, and return to two pods after the load ended.

It also exposed an important constraint: application autoscaling cannot compensate indefinitely for limited cluster capacity.

Autoscaling isn't simply about adding pods. It's about responding to demand, observing the result, and knowing when you've reached your limits.