Hybrid commitment strategy: coordinating RIs, Savings Plans, and on-prem hardware cycles.

The double-pay pattern

A pattern repeats in enterprises with both cloud and on-prem footprints.

A procurement team refreshes an on-prem rack on a 4-year cycle, buying new hardware in Q2 against a depreciation schedule that extends through 2030. In Q3 of the same year, the cloud FinOps team buys a 3-year Reserved Instance to cover a workload running in AWS, assuming steady-state consumption through 2028. In Q1 of the following year, an application architect decides the workload should migrate back to on-prem to take advantage of the new hardware. The RI is stuck. The rack is stuck. The organization is paying for capacity it is not using, in two venues, for reasons that each made local sense and together made no sense at all.

This is not an exotic failure mode. It is the default mode when commitment planning is venue-scoped. The fix is to treat commitments and refresh cycles as one portfolio.

The commitment instruments, in one frame

Any unified model has to start with the instruments themselves. Seven show up in hybrid estates.

Standard Reserved Instances

Per Hyperglance's 2026 comparison, Standard RIs on AWS offer up to 72% discount off on-demand for a 3-year all-upfront commitment on a specific instance family and region. They are the deepest-discount instrument and the most brittle; they do not accommodate family changes.

Convertible Reserved Instances

Convertible RIs offer 31–54% discount and allow exchange for a different instance family of equal or greater value during the term. They trade some discount for flexibility — particularly against technology-refresh cycles where you expect instance families to evolve.

Compute Savings Plans

A commitment to a fixed hourly spend for 1 or 3 years, applied automatically across EC2, Fargate, and Lambda across regions and instance families. Less discount than Standard RIs; much more flexibility. Per CloudZero's RI vs. SP roadmap, the correct mental model is that SPs absorb flexibility RIs cannot provide.

EC2 Instance Savings Plans

A narrower Savings Plan tied to a specific instance family in a region. Discount sits between Compute SP and Standard RI. Used when you want instance-family commitment with some size flexibility.

Azure Reservations + Savings Plans

Azure's analogous structure, with additional complexity because Azure couples reservations to software licensing. Per ProsperOps' Azure RI analysis, Azure Reservations cover the VM; Azure Savings Plans cover broader compute at lower discount.

Azure Hybrid Benefit

Allows organizations with Software Assurance on Windows Server or SQL Server to apply those licenses to Azure VMs, reducing the license-included portion of cloud compute. In hybrid estates it should be modeled alongside RIs and SPs, not in the on-prem licensing team's separate spreadsheet.

On-prem depreciation and refresh

The instrument nobody labels as a commitment but that behaves like one. Hardware purchased on a 3-year or 5-year depreciation schedule is a committed capacity bet against a future workload profile. It has the same planning characteristics as an RI — a term, a strike price, a break-even, and a shelfware risk — and it belongs on the same ledger.

The unified commitment model

Five components make the model work end-to-end.

1. Forecast combined trough, not venue peak

Separately-planned commitments size each venue to its peak to avoid on-demand burst. Together, trough-sized commitments cover what will certainly run across both venues for the term, leaving burst to on-demand in either direction. Trough forecasting beats peak forecasting because it concentrates commitments where certainty is highest.

2. Layer, do not stack

Per AWS documentation, the billing engine applies RIs before Savings Plans. Layer accordingly:

• Standard RIs for the deepest, most certain baseline on known instance families.
• Convertible RIs for the near-baseline where refresh risk exists.
• EC2 Savings Plans for specific family commitments with size flexibility.
• Compute Savings Plans as the top layer, absorbing broader compute including Fargate and Lambda.

The ordering matters because discount rates compound differently across instruments, and because SPs applied first leave no room for RIs to land.

3. Align commitment terms with the refresh cadence

If your on-prem refresh runs on a 4-year cycle and you are buying 3-year cloud commitments, every new commitment has a 75% chance of outlasting the workload assumption it was sized against. Align. A 1-year commitment during a refresh year preserves flexibility; a 3-year commitment after the refresh decision captures maximum discount.

4. Model Hybrid Benefit and passthrough together

Azure Hybrid Benefit and on-prem software licensing interact. If you cancel Software Assurance, you lose the benefit; if you over-buy cloud reservations with the benefit applied and later move back on-prem, the license economics flip. Same for Databricks passthrough against EC2 RIs — the passthrough compute can be RI-covered, but only if the RI portfolio knew about it.

5. Publish a coverage ratio per venue and combined

The coverage ratio is observed commitments divided by observed demand. Publish it monthly:

• Per cloud region.
• Per on-prem facility.
• Combined across venues.

The combined number is the one that drives decisions. A cloud-only coverage ratio of 85% looks fine until the combined ratio reveals that on-prem is running at 50% utilization on refreshed hardware the workload never migrated to.

Target coverage: 60–80% of trough

Coverage ratios above 80% of trough are where shelfware risk spikes. Coverage below 60% leaves significant discount on the table. The band is not a hard rule — it depends on workload volatility — but it is where mature practices converge. A 60% floor captures meaningful discount; an 80% ceiling preserves the optionality to migrate, decompose, or retire workloads without paying for commitments that no longer serve them.

The common error is calculating coverage against average demand rather than trough demand. Average-based coverage looks reasonable and systematically overcommits, because any workload that varies month-to-month has months below average where the commitment is underutilized.

Convertible RIs and the refresh bet

Standard RIs are the deepest discount instrument and the most brittle. They assume the instance family you buy today is the instance family the workload runs on through the entire term. In a hybrid estate with an active refresh cycle, that assumption breaks routinely. New on-prem hardware means new workload placement choices; new cloud instance generations mean the old family may be deprecated before the term ends.

Convertible RIs are the hedge. The discount is lower, but the right to exchange for a different family of equal value is worth real money when the instance landscape shifts under you. For any workload where you are not highly confident about the family through the term, Convertible is the risk-adjusted choice. Per nOps' RI vs. SP guide, the convertible premium usually pays for itself over a 3-year term for any workload with material refresh exposure.

The quarterly review cadence

A unified commitment portfolio needs a quarterly review that brings cloud FinOps, infrastructure procurement, and application architects into the same room. The agenda is tight.

1. Coverage ratio per venue and combined.
2. Shelfware: committed capacity under-utilized, by venue.
3. Refresh calendar for the next six quarters.
4. Workload migration plans in either direction.
5. Expiring commitments and renewal posture (extend, convert, drop).
6. Hybrid Benefit and license economics delta.

Run this review quarterly and the double-pay pattern dies. The commitment decisions start being made against combined forecasts instead of venue peaks. The procurement team stops refreshing on a cadence that ignores cloud exposure. The cloud team stops buying 3-year commitments in the teeth of a refresh cycle.

Three common mistakes

Mistake 1: venue-scoped planning. Covered above. The default and the biggest driver of double-pay.

Mistake 2: 100% coverage as an aspiration. Committing to 100% of trough looks fiscally disciplined and is in fact fragile. Every workload that migrates, retires, or decomposes erodes coverage; the commitment cannot follow. The 80% ceiling exists because the world changes.

Mistake 3: ignoring Hybrid Benefit. The benefit is worth 30–40% off Windows Server and SQL Server cloud compute. If your on-prem licensing team maintains Software Assurance and the cloud team is not applying the benefit, you are leaving large sums on the table — and if the cloud team is applying it while the on-prem team is canceling SA, you are about to be surprised.

What this looks like when it works

A hybrid-FinOps mature organization runs a single commitment ledger that tracks cloud RIs, cloud SPs, Azure Hybrid Benefit utilization, and on-prem depreciation against a combined capacity forecast. The ledger is updated monthly, reviewed quarterly by cloud, procurement, and application architecture together, and referenced whenever a workload migration is proposed in either direction. Coverage ratios stay in the 60–80% band, commitment terms are aligned with the refresh cadence, and shelfware stays below 5% of committed spend.

What disappears is the quiet double-pay. What appears is a portfolio that treats capacity as a single balance sheet with two venues, both earning their discount, neither paying for the other's blind spot.