Committing to three-year Reserved Instances while your architecture is still changing is not FinOps — it's betting your infrastructure roadmap on decisions you made before the product was stable. I've seen this mistake cost companies north of €400k in stranded commitments. The sales rep calls it "guaranteed savings." The P&L calls it sunk cost.
Let me tell you what actually happens.
The Promise vs. The Reality
Cloud providers love Reserved Instances (RIs) and Savings Plans. They should — they get guaranteed revenue regardless of whether you actually use the capacity. The headline number is attractive: 30–40% off on-demand pricing for Azure compute, locked in for one or three years.
The catch is embedded in the assumption. Reservations work when:
- You know which VM series you'll use in 12 months
- You know how many you'll need
- You're confident the workload won't be containerised, serverless, or migrated to a managed service
During hypergrowth, none of those three are safe assumptions.
The math is brutal. A 35% discount on 65% utilisation nets you a 23% effective saving — less than Compute Savings Plans offer with no architecture lock-in whatsoever. I have seen companies that were paying more per effective compute hour than their on-demand counterparts, because their utilisation had collapsed after a Kubernetes migration and they were still holding three-year Standard Reserved Instances they couldn't exit.
Why Growing Companies Are Especially Vulnerable
A company burning €80k/month on Azure compute at Series A looks very different at Series B. The engineering team is larger. The product surface is wider. The architect who specified Standard_D4s_v3 instances in Q3 2024 is now pushing a containerisation roadmap that will replace 60% of those VMs with AKS node pools running Standard_D8ds_v5. The reservation portfolio doesn't port automatically. You either pay to migrate the reservations (partial credit, admin overhead), or you carry both the reservation cost and the new node pool cost simultaneously during the transition.
This is the hypergrowth trap: you buy reservations based on today's architecture, your architecture changes faster than the reservation term, and you're left holding commitments that don't map to anything you're running.
The architecture change that voids your reservation math
The most dangerous period for reservation commitments is 6–18 months before a significant re-platform: monolith to microservices, VM workloads to AKS, self-managed databases to PaaS. If that migration is on your roadmap and you can't be certain it won't happen inside the reservation window — don't commit.
What the Alternative Actually Looks Like
I'm not saying never commit. I'm saying commit precisely, and only after you've done the work to de-risk the commitment.
The FinOps posture I recommend for growing companies has three tiers:
Tier 1: Compute Savings Plans (Flexible Commitment)
Azure's equivalent is Azure Savings Plans for Compute — a spend-based commitment (e.g., €5,000/month) that applies across VM series, regions, and even AKS and Azure Functions. You're committing to a spend floor, not a specific SKU. If your architecture changes, the savings plan follows the compute, not the instance type.
Discount: 15–20% off on-demand. Less than Standard RIs. But the utilisation rate is close to 100% because the commitment doesn't depend on specific VMs surviving intact.
Tier 2: Reserved Instances on Stable, Long-Lived Workloads Only
Some workloads genuinely are stable: production databases on Azure SQL Managed Instance, data warehouse clusters, observability infrastructure. These are good candidates for one-year Reserved Instances — not three-year. The discount is smaller (around 5–8% less than three-year), but the optionality is worth more than the marginal saving when you're still scaling.
The rule I use: if you can't write a credible justification for why this specific resource will still be running in the same SKU in 24 months, don't buy a three-year reservation.
Tier 3: On-Demand + Spot/Preemptible for Variable Workloads
Development environments, batch processing, CI/CD pipelines, ML training jobs — these should run on Spot VMs (Azure) or Preemptible VMs (GCP). The discount is 60–90% off on-demand. Yes, instances can be evicted. Build workloads that tolerate eviction and you've solved 40–60% of your cloud spend on those workload types without any long-term commitment.
The decision of which tier to apply to a given workload can be reduced to a simple check:
The Actual Comparison
| Strategy | Discount | Lock-in | Utilisation Risk | Suitable Stage |
|---|---|---|---|---|
| 3-Year Standard RI | 35–42% | 36 months, specific SKU | High — tied to VM series | Late-stage, stable workloads |
| 1-Year Standard RI | 25–30% | 12 months, specific SKU | Medium | Post-Series B, stable workloads |
| Azure Savings Plan | 15–20% | 1–3 years, spend-based | Low — follows any compute | Series A–C, growing teams |
| Spot/Preemptible | 60–90% | None | None | Dev, batch, ML training |
| On-Demand | 0% | None | None | Stateful, eviction-intolerant |
The instinct to chase the biggest discount number is understandable. The problem is that a 42% discount on a mismatched reservation is worse than a 17% discount on a commitment you'll fully utilise.
The FinOps Process That Actually Works
Optimisation is not a one-time purchase decision. It's a quarterly cadence. Here is what I implement for clients:
You cannot optimise what you cannot see. Before touching a single reservation, instrument cost allocation properly. Every resource tagged by team, environment, and workload. Azure Cost Management filtered by those tags. Anomaly detection alerts configured. Until you can answer "which team owns this €12k/month VM cluster and what does it do," you are flying blind. Reservation decisions made without this context create the exact stranded commitments I described above.
Most cloud estates are 20–40% oversized. Run Azure Advisor recommendations and cross-reference with 30 days of actual CPU and memory utilisation data. Right-sizing a fleet of Standard_D8s_v3 instances to Standard_D4s_v3 before buying reservations halves your commitment cost and doubles your effective discount rate. Reservations on oversized instances lock in waste. Right-size first, then commit.
Start with Azure Savings Plans for the base load. Add one-year RIs for the workloads you've confirmed are stable and correctly sized. Review every 90 days. As the business matures and architecture stabilises, the RI proportion of the portfolio can grow. But don't front-load three-year commitments during a period of architectural flux.
Set a calendar appointment. Every 90 days: review reservation utilisation in Azure Cost Management, identify underperforming commitments, exchange or scope-adjust where Azure's exchange policy allows, and reassess the roadmap for the next 12 months against current commitments. FinOps is a practice, not a project.
The Number Your CFO Should Be Watching
Reservation utilisation rate. Not the savings. The utilisation.
A reservation showing €15k/month in "savings" on your Azure cost management dashboard may be running at 55% utilisation. That means you're paying for 45% of committed capacity you're not using. The actual net saving after adjusting for stranded capacity is often negative versus a Savings Plan at full utilisation.
Track utilisation by reservation, monthly. Any reservation running below 80% utilisation for two consecutive months needs an explanation or an exchange request.
The metric that reveals stranded commitments instantly
In Azure Cost Management, navigate to Reservations under Billing, select your reservation scope, and filter by "Under-utilized reservations" — Microsoft defines this as below 100% utilisation for the last 7 days. The list you see is your stranded commitment portfolio. In most growing companies I audit, this list is longer than anyone expected.
What Stable Looks Like — and When to Lock In
The inflection point for aggressive reservation purchasing is after a major re-platform completes and the architecture has been stable for two or three quarters. At that point:
- You know which VM families you're on and why
- You've right-sized against actual production utilisation
- The roadmap doesn't have a major architectural shift in the next 18 months
That's when a three-year RI makes sense. You're not gambling — you're locking in a known discount on a known workload. Before that point, flexibility has measurable economic value that the extra 15–20% RI discount doesn't cover.
The cloud providers don't publicise this. Their sales teams are incentivised to close commitment contracts early and large. Push back. Run the utilisation-adjusted numbers. In a growing company, optionality is worth real money.
Cloud cost strategy is one of the areas where the gap between "what the vendor recommends" and "what actually saves money" is widest. If you want an independent view of your Azure or multi-cloud commitment portfolio, let's talk — book a 30-minute discovery call.