Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / The Cloud Cost Optimization That Actually Works
Transcript
- Lucas: If these conversations are useful for what you're building or running, you're in the right place. I'm Lucas. Luna: And I'm Luna. This is The Cloud Business Podcast. Lucas: So, Luna — I want to talk about something that sounds almost too boring to matter, but it's actually where most enterprise cloud programs leave twenty to thirty percent of their budget on the table. Luna: I'm guessing you mean instance rightsizing and commitment discounts? Lucas: Exactly. And not the generic advice you hear at every FinOps conference. I want to walk through a specific case — a mid-size SaaS company, about 400 employees, running mostly on AWS. We'll call them AtlasPay. They brought me in last year to look at their cloud spend because the CFO was seeing the bill grow thirty percent quarter over quarter. Luna: Right, and that's the classic panic moment. Happens to almost every company that hits a growth spurt. Lucas: Exactly. So when I looked at their environment, the first thing that jumped out was that seventy percent of their EC2 instances were running on general-purpose families — the 'T' and 'M' series. And that's fine if your workload is variable or balanced. But AtlasPay runs a data pipeline that pegs CPU at ninety percent for hours at a time. They were literally paying a premium for memory and network features they weren't using. Luna: So they were overspending by buying a more expensive instance type than needed, and then they also weren't committing to any discounts? Lucas: Correct on both. They had zero reserved instances and zero savings plans. They were paying full on-demand price for everything. And because they were using general-purpose instances, they could have switched to compute-optimized 'C' series instances — which are about twenty percent cheaper per compute unit — and actually gotten better performance. Luna: That's the part people miss. Rightsizing isn't just about picking a smaller instance. It's about matching the instance family to the workload's dominant resource. Lucas: Exactly. In AtlasPay's case, we moved their batch processing jobs from m5.large to c5.large instances. Same vCPU count, similar memory, but the c5 uses a custom AWS Nitro chip that's more efficient for compute-heavy tasks. Their job completion time dropped by twelve percent, and the per-hour cost dropped by eighteen percent. Luna: So you got a double win — faster processing and lower cost. That's the dream. Lucas: It really is. And the best part is that this wasn't some months-long optimization project. We did the analysis using AWS Compute Optimizer and a simple script that mapped instance utilization to the right family. Took about two weeks to identify all the candidates and then another week to schedule the cutovers during maintenance windows. Luna: That's surprisingly fast. Why don't more companies do this? Lucas: Two reasons. First, fear of downtime. Engineers are terrified that changing an instance type will break something. In practice, if you're within the same generation, it's almost always seamless. The second reason is that the cloud providers' native cost tools are designed to make you comfortable with spending more. Luna: How so? Lucas: AWS Cost Explorer, for example, defaults to showing you your total spend and your top services. It doesn't proactively say 'hey, these thirty instances are running at ninety percent CPU but you're paying for memory you don't need.' You have to dig into the separate Compute Optimizer console. And GCP's Recommender does surface rightsizing suggestions, but they're conservative — they only recommend downsizing if utilization has been low for weeks. They won't recommend switching families unless you explicitly ask. Luna: So the tools are there, but the incentives aren't aligned. The cloud providers want you to spend more, not less. Lucas: Bingo. And that's why the biggest savings come from things that the providers don't surface easily. In AtlasPay's case, after we moved to compute-optimized instances, we then looked at commitment discounts. They had never bought a reserved instance because they thought it was too risky — what if they needed to change architectures? But savings plans are much more flexible. You commit to a dollar amount per hour for one or three years, and it applies to any instance family in a given region. Luna: And you can even switch between compute, EC2, and Fargate with the same plan, right? Lucas: Exactly. We recommended a three-year partial upfront savings plan covering about sixty percent of their projected compute spend. That alone knocked off another thirty percent from those instance costs. Combined with the family switch, AtlasPay's total AWS bill dropped by thirty-eight percent in three months. And performance improved. Luna: Thirty-eight percent. That's not marginal. That's a million dollar plus save for a company their size. Lucas: It was about one point two million annually. And the CFO was ecstatic, of course. But here's the thing — this isn't a one-time fix. Cloud environments drift. New services get added, old ones get forgotten, and utilization patterns change. You have to revisit this every quarter. Luna: So how do you operationalize it without a dedicated FinOps team? Lucas: That's the real question. And honestly, the answer is automation and tagging discipline. If you tag every resource with the workload owner and the environment, you can run a weekly script that checks utilization and flags anomalies. Several open-source tools do this — CloudHealth, or even a simple Lambda function that calls the Compute Optimizer API. Luna: But doesn't that require engineering time to set up and maintain? Lucas: It does, but the ROI is absurd. If you save thirty percent on a million-dollar bill, that's three hundred thousand dollars a year. If it takes an engineer two weeks to set up the automation, that's maybe ten thousand dollars in salary. The payback period is less than a month. Luna: Right. And yet most companies still don't do it. I think part of it is that cloud cost management feels like a 'someone else's problem' — the engineers don't want to think about money, and the finance team doesn't understand the technical levers. Lucas: Exactly. That's the classic FinOps adoption barrier. But if you can get a single person who bridges both worlds — sometimes called a cloud cost champion — you can unlock massive value. AtlasPay actually hired a cloud architect with a finance bent after our engagement, and she now runs a monthly cost review. Luna: So the playbook is: first, do the instance family audit. Second, apply savings plans or reserved instances. Third, automate continuous monitoring. Fourth, assign ownership. Lucas: That's the framework. And I'd add a fifth step: measure your savings rate. Not just absolute spend, but the percentage you're saving vs. on-demand. If that number starts dropping, you know you're drifting. Luna: One thing I want to ask — does this apply equally to Azure and GCP, or are there nuances? Lucas: Great question. The principle is identical. Azure has reserved instances and savings plans — they call them Azure Reservations and Azure Savings Plan. Same idea. GCP has committed use discounts and per-second billing, which actually makes rightsizing even more powerful because you don't lose money on partial hours. The key difference is that Azure's Compute Optimizer equivalent is Azure Advisor, which is actually pretty good at rightsizing recommendations. GCP's Recommender is also solid. Luna: So the tools are there across all three. The problem is execution. Lucas: Exactly. It's a people and process problem, not a technology problem. And that's why it's such a good topic for this show — because the tech is the easy part. Luna: So at this point, if someone listening thinks 'I should look at my own cloud bill,' what's the first step? Lucas: Go into your cloud console and export your cost and usage report. Then filter by instance type and look at your top ten most expensive instance families. For each one, check the average CPU utilization over the last thirty days. If it's above eighty percent and it's not a compute-optimized family, that's your low-hanging fruit. Luna: That's actionable advice that anyone can do in an afternoon. Lucas: And if today was actually useful to you, the way these stay ad-free is listener support. You can find us at buy me a coffee dot com slash fexingo. Luna: Yeah, it really helps us keep going — and we don't have to sell your data to advertisers. Lucas: So to close this out — the cloud cost optimization playbook is not about some exotic new tool. It's about doing the basics well: matching instance type to workload, committing to discounts, and reviewing regularly. Luna: And that thirty-eight percent savings is real. I've seen it happen too. Lucas: I'd love to hear from listeners who try this. Send us a note — we might feature your story in a future episode. Luna: For now, I'm Luna. Lucas: And I'm Lucas. Thanks for spending time with us.