Structuring Cloud Commitments: How to Blend Reserved Instances and Savings Plans for Maximum Coverage

Over the past few slightly chaotic months at work, a customer asked a really interesting question that I realized deserves a better, broader explanation. The term "Negotiated Discount" keeps coming up more and more — and honestly, the way each hyperscaler (AWS, Azure, GCP) talks about their discounts can make it confusing to figure out what's actually being offered and what strategy you should follow. I thought it might be helpful to share a few thoughts and hopefully, the FinOps world according to Shan gives you some useful perspectives as you dig deeper into the art (and science) of FinOps!

Managing cloud costs efficiently often comes down to one key strategy: lock in discounts wherever you can, without giving up too much flexibility.

That's exactly where Reserved Instances (RIs) and Savings Plans come into play. If you're running a significant amount of workloads on AWS, Azure, or GCP, getting the right mix between these two configurations can dramatically improve your cloud financial management.

First up, the question from my customer: Why would I need both Reserved Instances and Savings Plans?

The customer of mine who asked has chosen Azure as their primary cloud, so Reserved Instances and Savings Plans are the appropriate terminology to use (interestingly enough, there is variety in these terms from Azure to AWS to GCP...GCP being the outlier). To quickly level set, there are terms each hyperscaler uses and I'll quickly cover them here:

Reserved Instances vs. Savings Plans: What’s the Difference?

Reserved Instances are exactly what they sound like — you’re reserving specific compute capacity for a set term (typically 1 or 3 years) in exchange for a significant discount compared to on-demand prices. The trade-off? They are rigid: you're locking into a specific instance type, region, and operating system.

Savings Plans (or their equivalents) offer a more flexible approach. Instead of reserving a specific instance, you're committing to spend a certain amount per hour on compute, across instance types, families, or even services (Web Apps, Logic Apps, Lambda Functions, etc. all count for a Savings Plan).

Key difference:

Reserved Instances are capacity and configuration specific.
Savings Plans are dollar-commitment based and more flexible across your entire environment.

How to Blend Them for Maximum Coverage

Back to my customer's question: there's a way to blend both and give you the most coverage. Here’s a practical strategy many organizations use to structure their commitments:

1. Anchor Your Core with Reserved Instances

Start by identifying workloads that are stable and predictable — think production databases, critical app servers, baseline Kubernetes nodes, etc. These are perfect candidates for Reserved Instances because you’re not expecting them to disappear or change substantially over the next year or three. Locking these down with RIs gets you the highest possible discount.

2. Layer on Savings Plans for Flexibility

Once your core is covered, move up the stack to workloads that have a consistent spend pattern but might evolve — maybe they’ll scale up, scale down, move to different instance types, or even shift regions. Savings Plans (or flexible CUDs in GCP) allow you to catch all that variable but generally steady usage without the risk of getting stuck in the wrong instance commitment. Savings Plans effectively "float" over whatever compute resources you’re running, applying the discount where it fits best.

3. Leave Some Headroom

No matter how much you model, there will always be unexpected growth, shrinkage, or project shifts. It’s smart to leave a little bit of your environment on on-demand rates, especially for short-term, experimental, or highly seasonal workloads. Then revisit your patterns regularly — quarterly or semi-annually — and layer in additional commitments as your environment stabilizes.

Why Blending Works

When you mix Reserved Instances for your "known-knowns" and Savings Plans for your "known-unknowns," you maximize discounts without putting yourself into a corner.

You're not overcommitting, you're not leaving too much on-demand, and you're making it easier for your finance and engineering teams to collaborate without constant renegotiations. It’s also a natural step toward a FinOps practice — making financial accountability part of day-to-day cloud management.

Final Thoughts

Getting the right coverage across your cloud footprint isn’t a one-time exercise. It’s a living, breathing process that grows with your environment. The good news? Once you have your blend in place, you’ve built a strong foundation for predictable, optimized cloud spend — and freed up more budget for innovation instead of infrastructure.

Further Reading:

CLOUDY MUSINGS

If I can do it, you can, too!