TL;DR
Cloud commitments don’t fail because the math is wrong.
They fail when teams chase flexibility instead of designing for it.
In this short blog, I will walk you through a multi-cloud strategy (AWS and Azure) that uses Savings Plans, Reservations, and Marketplace Reserved Instances, without getting locked in.
It’s built for real organizations with changing architectures, evolving product demands, and limited appetite for risk, drawing from my own experience, working with hundreds of multi-cloud environments.
Commitments Are an Organizational Decision
Savings Plans and Reservations aren’t a FinOps trick.
They’re a reflection of long-term product and engineering intent.
If Product, Engineering, and Finance don’t co-own the commitment strategy, 3-year terms will always feel too risky, and usually be avoided.
Why this matters:
Cloud providers offer their biggest discounts to those willing to commit. But those savings depend on:
- Product roadmap stability
- Architectural maturity
- Technology standardization
- Long-term demand confidence
This requires cross-team planning, not one-off purchases by a single team.
Think in Baselines, Not Instances.
The most important question to answer before buying any commitment:
What’s your structural demand?
Mature organizations first define:
- What usage is unavoidable and stable
- What usage is elastic, experimental, or subject to change
Only the baseline is eligible for long-term commitments.
Everything else stays flexible, on purpose.
This mindset shift is what separates FinOps maturity levels.
Use-Case: Practical Multi-Cloud Strategy (AWS & Azure)
Let’s look at how a mature customer approached this across AWS and Azure:
50% Reservations: For What’s Stable
These cover the most predictable, well-understood workloads.
The mix includes:
- Standard Reserved Instances (AWS) / Azure Reservations
- Marketplace RIs (AWS) – shortens lock-in for legacy workloads or transitional projects
Marketplace Reserved Instances help:
- Minimize commitment duration
- Improve pricing for workloads being refactored or decommissioned
- Add flexibility to the portfolio
More on that here:
🔗 How to use AWS Marketplace for short-term RI discounts
50% Savings Plans: Bought Gradually
Instead of making a massive upfront purchase, this customer buys compute Savings Plans in small chunks – monthly.
Each month:
- Some plans expire
- Others are renewed or scaled
- Confidence informs coverage
This allows for dynamic tuning:
- Ramp up as product certainty grows
- Scale down if demand drops
- Always keep decision points open
High utilization is achieved progressively, not aggressively.
Why This Model Works
- Reservations capture deep discounts on stable demand
- Savings Plans absorb architecture and usage evolution
- Marketplace adds short-term flexibility, reducing lock-in anxiety
- Monthly expirations enforce ongoing review and governance
None of this relies on chance.
Flexibility is engineered, by design.
The Hidden Enabler: Standardization
You can’t scale this model without instance-level discipline.
- Stick to a small number of instance families
- Use size flexibility features (both AWS and Azure support it)
- Reduce architectural sprawl across products
This isn’t just about operations, it’s a financial policy.
FinOps Maturity: What It Actually Looks Like
Low Maturity:
- One-time purchases
- Avoidance of 3-year terms
- No exit strategy
High Maturity:
- Portfolio-based planning
- Staggered commitments
- Marketplace used strategically
- Monthly reviews built into process
Final Thought
The goal isn’t to get the highest discount.
It’s to commit in a way that preserves optionality.
This is how engineering-led companies make 3-year commitments, without losing control.
If you have questions about Savings Plans, Reservations, or how to model a mixed-commitment strategy across AWS and Azure, feel free to reach out:
— Udi Limor, FinOps Engineer @ 2bcloud
[email protected]
