How Increasing Pod Size Helped Me Save Money on Cloud Costs

Okay, grab a seat because I’m about to drop some knowledge that’s gonna make you go, “Wait, what?” You know how everyone always tells you to downscale everything when you’re trying to save money on cloud costs? Well, I did the opposite. I actually increased the pod size—and guess what? My costs dropped. Seriously. And the best part? The whole team was absolutely baffled.

But first, let’s set the stage…

The Problem: Cloud Bills Are Scary, but Also Avoidable

If you’ve ever worked in a cloud environment, you know that cloud bills have a way of creeping up on you like an unpaid Netflix subscription. So, I was handed this task to optimize costs in our Kubernetes environment. The goal: Make sure everything is still running smoothly, but stop the unnecessary cash hemorrhage. Seems simple enough, right?

Well, I looked at the pods and said, “Alright, how do we shrink these bad boys and still keep things humming?” The typical answer would be: Reduce the number of pods. Easy. Downscale the workers, downscale the pods, downscale the memory… you get the drift.

Another issue is that it is all part of a controlled environment and it would be a tedious process to convice the team to ask for a downsize, which I also had to do eventually. But before that I had to do a different approach of increasing the pod size to save the cost !!

But here’s the twist: I didn’t do that. In fact, I did the exact opposite because it is much easier to convince the team.

The Big Idea: Increase Pod Size (and Watch the Magic Happen)

You see, in one of our environments, the application pods were scaling up to 25 replicas—even when the system wasn’t doing anything. I dove in, looked under the hood, and realized something: The Unicorn processes (not the magical kind, sadly) running on the Python Flask app had been set to 20 workers by default. The logic? “Let’s just throw more workers at the problem, and performance will magically improve!”

Spoiler alert: More workers = more cost, but not necessarily better performance.

So, I thought, “What if I did the unthinkable? What if I increased the size of the pod itself, rather than reducing the worker count?” This is where everyone would freak out if I said it out loud. Think about it: Reducing pod count sounds like a reasonable, cost-saving move, right? But increasing the pod size—that’s practically heresy in the world of Kubernetes cost optimization. It goes against everything you’ve ever been told.

But here’s what I proposed:

1. Increase the pod size (more memory, more power in a single pod).
2. Reduce the worker count (because we didn’t need 20 Unicorns running around for nothing).
3. Adjust the memory requests to keep everything nice and efficient during idle times.

And guess what? It actually worked. The pod count scaled down, the overall threshold increased, and my cloud costs went down.

Why This Worked (and Why No One Saw It Coming)

The reason this worked is all about the relationship between pod size, scaling thresholds, and overall efficiency. By increasing the pod size, I was able to handle more load with fewer pods. Normally, you’d think that would make things worse—more resources equals more costs, right? But the trick here is that larger pods with fewer replicas mean less overhead when scaling. It’s like saying, “I’m going to pack more into fewer boxes, so there’s less clutter and fewer shipping costs.” The pods themselves didn’t need to scale up and down as often, and that saved a ton of money in the long run.

This didn’t just surprise me—it shocked the team. Everyone assumed I was about to drop the worker count down and start eliminating pods left and right. But no—I was the mad genius who said, “More is less.”

The Result? Less Scaling, More Savings

Here’s the kicker: By increasing the pod size, the pods scaled down, and the application still performed just fine. We ended up with fewer pods running, less resource wastage, and a nice little cost reduction in the cloud bills.

Everyone was shocked. I mean, I literally got approval to increase the pod size, and no one blinked. But if I had said, “Hey, I’m going to reduce the pod count,” there would have been a full-on team meeting to discuss the impending apocalypse of “what if we break something?” But instead, we reduced the pod count by increasing the pod size—and saved money. Talk about a win-win.

Final Thoughts: It’s All About Smarter Resource Management, Not Just Downsizing

So, yeah, the big lesson here is that cost optimization isn’t always about shrinking things down. Sometimes it’s about managing your resources in a smarter way. I’m talking about adjusting pod sizes, fine-tuning memory settings, and rethinking how you scale. It’s a delicate balance, and if you get it right, you can have your cake and eat it too—save money and keep things running smoothly.

Next time you’re thinking about cost optimization, don’t just automatically downscale everything. Maybe it’s time to get a little more creative. And hey, if you surprise the team while doing it, even better.