India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Commitment Planning for Savings Plans, Reservations and CUDs
Commitment and discount planning is the practice of deciding how much cloud usage to commit to, in which instrument and for how long, to buy it below on-demand rates without stranding unused commitments. NTSPL builds a laddered portfolio of AWS Savings Plans and reservations, Azure reservations and savings plans, and Google Cloud CUDs, sized against post-optimisation baseline usage and finance's risk tolerance.
Delivered on
In scope
Why Commitment Coverage Is Either Too Low or Badly Timed
Commitments are where cloud savings are largest and mistakes most expensive. Buy too little and steady workloads pay on-demand rates 30-60% above what they could; buy too much, or the wrong type, and the company pays for capacity it does not use for one to three years. Most Indian enterprises we see sit at one of two extremes: coverage under 30% because nobody will sign a three-year commitment, or a cluster of large purchases made in one month by one engineer, now expiring together and leaving a cliff in the budget.
NTSPL treats commitments as a portfolio managed by finance and engineering together. We size the committable baseline from the lowest sustained hourly usage after waste is removed, split it across flexible and specific instruments, and ladder purchases monthly or quarterly so no more than 15-20% of the portfolio expires in any quarter. Finance sees the payback, cash-flow and stranding risk of each tranche in INR.
Commitment Portfolio Warning Signs
Signals you need Commitment & Discount Planning
- Effective savings rate on compute is under 15%, or coverage of steady compute is under 50%.
- More than 30% of existing commitments expire within the same quarter.
- Commitment utilisation has fallen below 90% after a migration, rightsizing or architecture change.
- Finance is negotiating an enterprise agreement or consumption commitment and needs a usage forecast.
- Workloads are shifting between instance families, regions or to containers and serverless, making specific reservations risky.
When to choose something else
- Waste has not been removed yet: commit after rightsizing and idle cleanup, or you lock in oversized capacity.
- Usage is under ₹5 lakh a month and highly variable: a single one-year Compute Savings Plan or Azure savings plan at 50% of minimum usage is enough without a planning engagement.
- The workload will leave the provider within 12 months, for example during a repatriation or provider switch.
Discount Instruments in the Planning Model
Committable baseline
Hourly usage over 6-13 months analysed per service and region to find the floor that persists through nights, weekends and seasonal troughs.
Compute instruments
AWS Compute and EC2 Instance Savings Plans, Azure savings plan for compute and VM reservations, Google Cloud resource-based and spend-based CUDs.
Database and service reservations
RDS, ElastiCache, OpenSearch, Azure SQL and Cosmos DB reservations, Cloud SQL CUDs and similar service-specific commitments.
Licence benefits
Azure Hybrid Benefit for Windows Server and SQL Server and bring-your-own-licence options combined with compute commitments.
Spot and preemptible capacity
Interruptible capacity for fault-tolerant batch and CI, sized so it sits above the committed floor rather than inside it.
Expiry and renewal ladder
A 36-month calendar of every commitment with renewal decision dates 60 days ahead of expiry.
How Commitment & Discount Planning Works, Step by Step
Baseline-to-Ladder Commitment Model
Hourly usage history is cleaned of known waste and planned changes to produce a committable baseline, which an optimiser splits across instruments by flexibility and discount depth. Purchases are laddered over time and tracked monthly for utilisation, coverage and expiry exposure.
Select any component
Baseline-to-Ladder Commitment Model: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Commitment Instruments on AWS, Azure and Google Cloud
Compute Savings Plans apply across EC2 families, regions, Fargate and Lambda; NTSPL uses them for most of the portfolio and keeps EC2 Instance Savings Plans for families that have been stable for over a year.
Reservations apply before the savings plan, so NTSPL reserves the most stable VM and database usage first and fills the remaining flexible compute with a savings plan.
Resource-based CUDs are region- and machine-series-specific; spend-based CUDs follow usage across series and regions. NTSPL often combines both with sustained use discounts on N-series machines.
Coverage, Term and Flexibility Choices
Target coverage level
Aim for 70-85% coverage of the adjusted committable floor, not of average usage. Covering average usage strands commitment every night and weekend. Volatile estates, such as e-commerce with festive peaks, sit at the lower end; steady ERP or core banking estates can go above 85%. NTSPL sets the target with finance and reviews it quarterly, not once.
One-year or three-year terms
Three-year terms give roughly double the additional discount of one-year terms, but carry two more years of forecast risk. Use three-year terms only for workloads that have been stable for over 12 months with no planned re-architecture, typically 30-50% of the portfolio. Keep the rest on one-year terms so the portfolio can follow container, serverless and Arm migrations.
Upfront payment
All-upfront gives the highest discount; no-upfront preserves cash. Compare the extra discount with the company's cost of capital: for many Indian growth companies with capital costs above 12%, no-upfront or partial-upfront is the better financial choice. Profitable enterprises with surplus cash often benefit from all-upfront. NTSPL presents each tranche with an IRR-style comparison for the CFO.
Flexible versus specific instruments
Specific instruments (EC2 Instance Savings Plans, VM reservations, resource-based CUDs) discount more but lock family and region. Flexible instruments discount less but follow change. If the next 12 months include a Graviton migration, region move to Hyderabad, or containerisation, keep at least 60% of the portfolio flexible. Stable databases are usually the safest specific commitments.
Commitment Planning and Purchase Cadence
Baseline and backlog adjustment
Hourly usage analysed and adjusted for the rightsizing, cleanup and decommission backlog.
Existing portfolio review
Current commitments mapped by instrument, utilisation, coverage and expiry; stranded or underused ones flagged for exchange or sharing changes.
Portfolio design
Target coverage, term mix and flexible-versus-specific split agreed with finance and platform leads.
First tranche purchase
Initial tranche, typically 30-50% of the target, purchased with finance approval.
Laddered tranches and tracking
Further tranches monthly or quarterly as optimisation lowers and stabilises the baseline; utilisation tracked daily.
What you receive
Portfolio Health Indicators
| KPI | Typical target |
|---|---|
| Effective savings rate on compute | 25-40% depending on volatility |
| Commitment utilisation | Above 95% |
| Coverage of committable floor | 70-85% |
| Share of portfolio expiring in any one quarter | Below 20% |
Commitment Risks and How They Are Contained
| Risk | How NTSPL prevents it |
|---|---|
| Commitments bought before rightsizing lock in oversized capacity. | The committable floor is adjusted for the optimisation backlog, and the first tranche covers only 30-50% of target. |
| Architecture changes strand specific reservations. | Planned migrations feed the model; at least 60% stays flexible when significant change is expected. |
| Benefit applied to the wrong business unit, causing chargeback disputes. | Sharing scope and allocation of commitment benefit agreed upfront and reported by business unit monthly. |
| Large simultaneous expiries create a budget cliff. | The ladder caps quarterly expiry exposure at 20% and renewal decisions are scheduled 60 days ahead. |
Azure reservations or Azure savings plan for compute: which should we buy?
Buy reservations for usage that will not change: a specific VM series in a specific region, or databases such as Azure SQL and Cosmos DB, which savings plans do not cover. Buy the savings plan for compute that moves between VM series, regions or services such as App Service and Container Apps. Reservations give deeper discounts; the savings plan gives flexibility. Because reservations are applied first, the right answer is usually both: reserve the stable core, then add a savings plan sized to the remaining steady compute. Do not buy a savings plan to cover usage already well covered by reservations.
Key facts: Commitment & Discount Planning
Commitment & Discount Planning in Practice
2 Commitment & Discount Planning scenarios, from Media streaming (subscription OTT with live sports) and Online travel portal (flights, hotels and holiday packages), plus related platform case studies.
Streaming service rebuilds its commitment portfolio and lifts savings rate to 31%
Travel portal blends resource and spend-based CUDs around peak holiday seasons
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
Audit firm moves 22 Windows servers to Azure and serves 180 staff via Virtual Desktop
Commitment & Discount Planning: Frequently Asked Questions
What does commitment planning cost compared with what it saves?
The planning engagement runs four weeks, then monthly tracking. NTSPL prices it as a fixed fee or as a share of the first year's verified savings. On a ₹50 lakh monthly compute bill moving from 20% to 75% coverage, the annual saving is typically ₹1-1.5 crore, so the fee is small relative to the value at stake.
Should we buy commitments through our reseller or directly?
Either works technically; what matters is who holds purchase authority and how benefits are allocated. Under a reseller or CSP arrangement, confirm that the reseller passes through the full commitment discount and that utilisation reports are available to you. NTSPL reviews the commercial terms alongside the portfolio design.
Can unused commitments be returned or exchanged?
Rules differ by provider and instrument. Some Azure reservations can be exchanged or refunded within limits, AWS Convertible Reserved Instances can be exchanged, and Savings Plans and Google Cloud CUDs generally cannot be cancelled. That is why NTSPL ladders purchases and keeps a flexible share instead of relying on exchanges.
Are commitments region-specific for Indian regions?
Some are. EC2 Instance Savings Plans, Azure VM reservations scoped to a region, and resource-based CUDs apply only in their region, such as AWS Mumbai or Google Cloud Delhi. Compute Savings Plans, Azure savings plan and spend-based CUDs apply across regions, which matters if DR or a second-region expansion is planned.
How do commitments work with Spot instances?
Spot and preemptible capacity is already heavily discounted and cannot be covered by commitments. NTSPL sizes commitments to the steady floor, runs fault-tolerant batch and CI on Spot above that floor, and uses on-demand only for the unpredictable peak in between.
Who should approve commitment purchases?
Finance should hold authority, with platform engineering confirming the baseline. A typical policy: tranches under ₹10 lakh annual value approved by the FinOps lead, larger ones by the CFO. This prevents individual engineers making large, poorly timed purchases, which is the most common cause of expiry cliffs.