Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / The AWS Reserved Instance Trap Enterprise Buyers Face
Transcript
- Lucas: If these conversations are useful for what you're building or running — welcome to The Cloud Business Podcast. I'm Lucas. Luna: And I'm Luna. Lucas: So I want to talk about something that sounds boring on paper but costs enterprises real money every single quarter — AWS Reserved Instances. Luna: Reserved Instances — the thing every cloud bill review says you should buy, but nobody tells you how easy it is to get wrong. Lucas: Exactly. And I say 'easy to get wrong' because I just looked at a case — a mid-market SaaS company, let's call them DataSync — that committed to three-year, partial upfront RIs for a big chunk of their compute. And after a workload migration, they ended up paying 12 percent more than on-demand would have cost. Luna: Wait — 12 percent more? That's the opposite of what RIs are supposed to do. How does that happen? Lucas: It happens because of two things: utilization rate and instance-family lock. DataSync was running a mix of m5 and c5 instances when they bought the RIs. Then they migrated some workloads to containers and switched to m6i and c6i — newer generation, better price-performance. But their RIs were locked to m5 and c5. So they were paying for capacity they couldn't use. Luna: Right — they were paying for reserved slots that sat idle, while their actual usage ran on-demand at the new instance types. That's the classic RI trap. Lucas: Exactly. And it's remarkably common. A 2025 survey from the FinOps Foundation found that about three out of five enterprises with significant RI portfolios have utilization rates below 70 percent. That means they're paying for compute they're not even consuming. Luna: And the worst part is, the AWS console shows you a utilization percentage, but it's easy to miss if you're not looking at it per instance family. The aggregate number can look fine while individual families are bleeding money. Lucas: That is exactly the blind spot. DataSync's aggregate utilization was like 85 percent — but that was because their database RIs were heavily utilized. The compute RIs were at 55 percent. And the savings from the database RIs masked the compute waste. Luna: So what's the alternative? Convertible RIs, right? Those let you change instance family. Lucas: They do, but there's a catch. Convertible RIs give you flexibility to change instance family, but at a lower discount — typically 10 to 15 percent less than standard RIs. And even then, you can only exchange for an instance of equal or greater value. So if you move to a cheaper instance type, you lose the difference. Luna: Huh. So Convertible RIs are not a free pass. They're a trade-off: flexibility for lower savings. What about the newer Savings Plans? Are those better? Lucas: AWS Savings Plans, launched in 2019, are more flexible — they apply to any compute usage across EC2, Fargate, and Lambda, as long as you commit to a dollar amount per hour. But they still have lock-in. If your compute spend drops — say you migrate some workloads to on-prem or to another cloud — you're still on the hook for that hourly commitment. Luna: That's a real risk in today's environment, where companies are actively rightsizing and even repatriating workloads. A one-size-fits-all commitment doesn't fit. Lucas: Exactly. And that's why a lot of FinOps teams are now advocating for a mix — short-term RIs or Savings Plans paired with Spot Instances for the variable part of the workload. One fintech I spoke to — they run risk modeling jobs that are fault-tolerant — they use a blend of one-year, no-upfront Convertible RIs for the baseline, and Spot for the spikes. They cut costs by 34 percent without locking themselves into anything longer than a year. Luna: And that's the model that makes sense for a lot of enterprises: commit to what you know you'll use, but keep the commitment short and convertible. The three-year, all-upfront RI — that's almost never the right call unless you have a truly static workload. Lucas: Right. And I think that's the key takeaway — don't treat RIs as a set-it-and-forget-it savings lever. They require ongoing management. You need to track utilization per instance family, review your workload roadmap, and adjust commitments as you go. Luna: Speaking of ongoing value — if today's episode helped you think about cloud commitments differently, that's exactly why this podcast exists. And the way we keep it ad-free is through listener support. If you'd like to help, you can find us at buy me a coffee dot com slash fexingo. Lucas: Yeah, it's a small way to keep these conversations going without any sponsors. Really appreciate anyone who does. Luna: Alright, back to the numbers — you mentioned the 34 percent savings from the fintech. How did they actually structure that? Lucas: Sure. They broke their compute into two buckets. Bucket one — the baseline — was about 60 percent of their peak load. That they covered with one-year, no-upfront Convertible RIs. They got a 30 percent discount versus on-demand, and they knew they could exchange if they changed instance families. Bucket two — the remaining 40 percent, which was spiky — they ran on Spot Instances. Spot pricing fluctuates, but on average they paid about 70 percent less than on-demand. Luna: So the blended discount was around 34 percent — that's a weighted average of the RI discount on 60 percent and the Spot discount on 40 percent. Lucas: Exactly. And they managed the Spot interruptions by designing their jobs to checkpoint — so if a Spot instance got reclaimed, they'd resume from the last save point. That's not trivial, but for batch workloads it's very doable. Luna: So the lesson here is: don't buy RIs in isolation. Design your procurement strategy around how your workloads actually run. Lucas: And that means having a clear picture of your workload characteristics — is it steady state or variable? Is it fault-tolerant or latency-sensitive? Can it handle Spot interruptions? For steady, non-fault-tolerant workloads, RIs make sense. For everything else, you need a more dynamic approach. Luna: What about the new AWS Capacity Blocks for ML? Those are a different kind of commitment — you reserve GPU capacity for a specific time window. Do you see those as similar traps? Lucas: Great question. Capacity Blocks are different — they're not about discount; they're about guaranteed access to scarce GPU instances. The trade-off is you pay a premium for that guarantee. If you over-reserve, you lose the money. But at least the commitment is short — typically one to seven days. So the risk is much smaller than a three-year RI. Luna: Still, the same principle applies: only reserve what you know you'll use. And monitor your actual usage against commitments. Lucas: Exactly. And that's where tooling comes in. AWS Cost Explorer can show you utilization per RI, but you have to set up the right views. Third-party FinOps platforms like CloudHealth or Vantage can give you more granular alerts. Luna: A lot of enterprises are also using the AWS Well-Architected Framework's Cost Optimization pillar to review their RI strategy quarterly. That's a good discipline. Lucas: Yeah, quarterly reviews are key. Because workloads change. A new migration, a new application, a move to containers — any of those can make your RIs obsolete. If you're not reviewing, you're leaving money on the table. Luna: So to wrap up: RIs are a tool, not a strategy. Use them for the right workloads, keep commitments short, and review often. Lucas: And if you're currently sitting on a portfolio of underutilized RIs, don't panic — you can sell them on the AWS Reserved Instance Marketplace. You'll take a discount, but it's better than letting them expire unused. Luna: Good point. There's an exit route. But it's smarter to avoid the trap in the first place. Lucas: Exactly. And that's the cloud business — it's not just about the tech, it's about the financial engineering that makes it sustainable. Luna: Thanks for listening, and we'll see you next time on The Cloud Business Podcast.