Avoid buying cloud commitments from a single busy week
On this page
This check is due for a source refresh. Confirm the current documentation before you rely on provider-specific details.
You risk paying for unused commitments, so reduce or defer a purchase that depends on a temporary peak. Approve only the amount workload owners expect to use throughout the term, after checking scope and recent-purchase updates.
What you need first
- Tool
- Use a read-only worksheet with provider recommendation details. Azure Advisor is Azure's recommendation service, and the Azure portal also provides savings plan recommendations. Google Cloud Billing provides committed use discount recommendations in FinOps hub or Recommendations.
- Access
- For Google Cloud billing-account recommendations, Billing Account Viewer (roles/billing.viewer) supports viewing. For AWS and Azure, ask an authorized cloud cost colleague for recommendation details for the intended scope.
- If you do not use that tool
- Send an authorized cloud cost colleague the provider, benefit type, billing account, subscription, or project scope, and term. Request the recommendation details, lookback, units, current commitments, recent purchase status, and owner forecast.
Why this is worth a look
Skipping this review can turn a historical usage pattern into a term-long commitment that demand no longer supports. AWS says recommendations do not forecast usage. Azure savings plans commit spend per hour, so lower hourly utilization can reduce savings. Google Cloud's optimal-savings model can include intermittent usage, so a recommendation may include bursts rather than continuous demand.
Run this check
CHECKLISTComplete this document for one proposed purchase using recommendation details or an authorized colleague's read-only results. Record scope, units, historical window, overlapping commitments, and future demand separately.
COMMITMENT APPROVAL WORKSHEET
Read-only review. Do not purchase, dismiss recommendations, or change settings.
SCOPE AND INPUTS
[ ] Record provider, benefit type, proposed term, recommendation date, and intended scope.
[ ] Record the access used, or the authorized colleague who supplied the result.
[ ] Copy the recommended amount and exact unit. Record currency for spend amounts; do not compare spend and resource quantities as the same measure.
[ ] Record the historical lookback and sharing setting. Label unavailable fields.
HISTORY VERSUS FUTURE DEMAND
[ ] Mark temporary peaks, retirements, and migrations that change eligible demand during the term.
[ ] Ask owners to document low and expected demand in units comparable to the recommendation.
[ ] For Google Cloud, identify stable-usage versus optimal-savings recommendations.
OVERLAP AND FRESHNESS
[ ] List current commitments and recent or planned purchases that could cover the same usage.
[ ] Apply provider-specific refresh or waiting rules before approval.
DECISION RECORD
[ ] Record approve, reduce, or defer, with amount, unit, and reason.
[ ] Use the documented low-demand case as the ceiling unless finance accepts underuse risk.
[ ] Name the workload owner and finance reviewer. Keep purchase execution separate.
How to confirm it
- 01
Fix the purchase scope
Record the benefit type, term, and scope before comparing amounts. For AWS, include discount-sharing preferences because management-account and member-account recommendations use different scopes. For Azure, check the benefit scope instead of accepting the default billing scope.
- 02
Compare historical windows
Compare AWS's 7-, 30-, and 60-day lookbacks with expected demand. Azure analyzes 7, 30, and 60 days, while portal and Advisor recommendations use 30 days and also use a three-day simulation after significant reductions. For Google Cloud, compare 30-day stable usage with optimal savings, which can include bursts above a financial break-even threshold.
- 03
Remove demand that will not last
Ask workload owners which peaks, retirements, or migrations affect eligible demand during the term. Document low and expected demand in comparable units. Defer the purchase if owners cannot explain why the demand will remain in scope.
- 04
Wait for overlapping purchases
Refresh AWS recommendations after purchases, returns, or expirations, and account separately for queued purchases because recommendations omit them. Do not add Compute and EC2 Instance Savings Plans recommendations together. In Azure, wait at least seven days after buying a reservation or savings plan before considering the other. Updates for other scopes can take up to 25 days.
- 05
Approve a bounded amount
Use the low-demand case as the approval ceiling unless finance accepts underuse risk. Record why any intermittent demand is expected to remain economical. For Google Cloud scenario comparisons, note that scenarios use the latest data while standard recommendations use daily snapshots. Keep approval separate from purchase.
Before making changes
The low-demand ceiling is an internal conservative approval rule, not the provider's maximum-savings recommendation. It may leave some usage uncommitted. This review assumes a defined benefit, scope, term, and owner forecast in comparable units. Confirm eligibility and current terms for the selected benefit before approval; this is not a cross-cloud pricing comparison.