Right‑sizing Azure Savings Plans, one hour at a time

We’ve all been there—making a commitment feels a bit like ordering food for a team outing: you estimate, round it up, and hope nobody raises an eyebrow. While that method can work for pizza, it’s not the best approach for a three-year Savings Plan.

Luckily, Azure Cost Management provides commitment recommendations, which serve as an excellent starting point. However, the prominent dollar figure you see in the portal tends to obscure a vital insight for your FinOps team: the hourly Pay-As-You-Go (PAYG) usage that the recommendations were based on. Once you extract that information into a spreadsheet, the phrase “right-sized” goes from a vague concept to a concrete number you can justify in steering meetings.

This article explains how to extract that data from the Cost Management REST API and includes a handy PowerShell script that does the hard work for you, producing outputs in CSV and Markdown formats that are easy to interpret.

At its core, a Savings Plan recommendation is all about optimising your hourly compute expenses based on a historical lookback period. Generally, the portal shows just one commitment level that maximises savings under what it considers “reasonable utilisation.” While this is a good starting point, it only answers a single question.

As FinOps professionals, you probably have several other questions, such as:

• What does my PAYG demand look like on an hourly basis? Is it consistent or does it fluctuate?
• How would my coverage and savings change if I slightly increase or decrease my commitment?
• Will the suggested commitment result in excess capacity during weekends or off-hours?
• Can I relate the hourly usage to maintenance schedules, batch processes, or business hours?

You can’t address these queries with just a single dollar figure. However, you can answer them with the hourly series and various commitment levels—both of which the API provides.

To access this information, use the Benefit Recommendations – List endpoint (api-version=2025-03-01). By pointing it to any of the supported scopes—Billing Account (EA), Billing Profile (MCA), Subscription, or Resource Group—you can retrieve one or more recommendations based on your chosen lookback period (Last7Days, Last30Days, Last60Days) and term (P1Y, P3Y).

The two $expand options are the key:

• $expand=properties/allRecommendationDetails provides an array of alternative commitment levels (AllSavingsBenefitDetails). Each entry includes details like commitment amount, coverage percentage, benefit cost, overage cost, savings amount, savings percentage, wastage cost, and average utilisation percentage.
• $expand=properties/usage returns the hourly PAYG charges (usage.charges) that were used in the calculations. When combined with properties.firstConsumptionDate and properties.lastConsumptionDate, you gain a fully aligned view of your demand over time.

Both expansions are inexpensive to request and should be included every time. They convert a single recommendation into a comprehensive dataset.

To streamline this process, there’s a PowerShell script available on GitHub that wraps the API call and generates easily digestible files. It’s user-friendly, so there’s nothing overly complicated to remember:

=== Azure Benefit Recommendations Export ===

Select billing scope kind:
  * [1] Billing Account (EA)
  * [2] Billing Profile (MCA)
  * [3] Subscription
  * [4] Resource Group
Enter choice 1-4 (default 1): 1
Billing Account ID: 

Select lookback period:
    [1] Last7Days
  * [2] Last30Days
  * [3] Last60Days
Enter choice 1-3 (default 2): 3

Select term:
  * [1] P1Y
  * [2] P3Y
Enter choice 1-2 (default 1): 2
...
Retrieved 1 recommendation(s).

The script authenticates via the Az.Accounts module, always requests both $expand options, handles pagination, checks API access in advance (providing actionable hints for errors), and creates four output files with a clear naming structure:

• yyyy-MM-dd—-AllRecommendationDetails.csv — one row per commitment alternative, perfect for pivot tables.
• yyyy-MM-dd—-TopRecommendation.md — a Markdown summary of the top recommendation, featuring both the recommended commitment and the complete alternatives table.
• yyyy-MM-dd—-HourlyUsage.csv — hour-by-hour PAYG usage data for the recommended amount, aligned with the actual API data window (no extra padding or trailing blanks).
• yyyy-MM-dd—-Raw.json — a full JSON dump of the response for archiving or further processing.

The file naming convention is designed intentionally; place a set of these files into Power BI, and the dates, scopes, and terms will already be part of the filename.

Here’s a sample from a Last60Days / P3Y export using an EA billing account, showcasing four commitment alternatives in the AllRecommendationDetails CSV:

averageUtilizationPercentage,coveragePercentage,commitmentAmount,overageCost,benefitCost,savingsAmount,savingsPercentage,totalCost,wastageCost
100.000,28.868,4.124,30914.280,5889.072,6656.889,15.317,36803.352,0.000 
100.000,39.168,5.848,26437.791,8350.944,8671.506,19.953,34788.735,0.000
9.984,97.883,16.359,919.948,23360.652,19179.641,44.131,24280.600,3.767 
98.684,98.900,16.806,477.956,23998.968,18983.317,43.680,24476.924,315.907

You can interpret these rows interactively:

• Committing $4.124/hr yields 28.9% coverage, 15.3% savings, and no wastage—secure, though much of your expenses are still PAYG.
• Committing $5.848/hr results in 39.2% coverage and 19.9% savings, remaining a cautious choice.
• Committing $16.359/hr offers 97.9% coverage and 44.1% savings, with only ~$3.77 in wastage—this is the optimal point the engine identifies as recommended.
• Committing $16.806/hr gives 98.9% coverage and 43.7% savings, but wastage rises to $315.9 over the period—a sign you’ve paid for more coverage than necessary.

The hourly CSV is essential for justifying recommendations, containing 1,428 rows—one for each hour from 2026-04-11T00:00 to 2026-06-09T11:00 (the date range reported by the API, not simply “now minus 60 days”):

DateTime,HourlyPayGoUsage
2026-04-11T00:00,29.5350191832771
2026-04-11T01:00,29.566694701744
...
2026-06-09T11:00,32.7312920192344

Drop this data into Excel or Power BI, set a horizontal line at the recommended commitmentAmount ($16.359/hr), and you’ll quickly see how frequently demand exceeds this line (covered by PAYG overages) compared to when it dips below (where your commitment appears idle yet, given the savings rate, remains beneficial). You can also analyse it by hour to identify low-demand weekends or batch job spikes, aiding your understanding of “average utilisation.”

For more, you can check out the script and full documentation at github.com/DirkBrinkmann/azure-savingsplan-insights. Quickstart:

git clone https://github.com/DirkBrinkmann/azure-savingsplan-insights.git 
cd azure-savingsplan-insights 
Install-Module Az.Accounts -Scope CurrentUser  # if not already installed

#Connect to Azure
Connect-AzAccount
#Run the script 
.\Export-BenefitRecommendations.ps1

You’ll need read permissions on your selected scope—Cost Management Reader for subscriptions or Billing Reader at the billing account or profile level will suffice.

Try it out against your own scope and share your experience. The repository at github.com/DirkBrinkmann/azure-savingsplan-insights has sections for Issues and Discussions—feedback, anecdotal insights from plotting in Power BI, requests for new features, or any differences in the response shape you encounter are all very welcome. The script will only improve with real-world data, and we’d love to hear yours.

In FinOps terms, this activity falls firmly into the Inform phase: transforming what was once a black-box recommendation into a transparent dataset your team can analyse, chart, and agree upon. The API has been holding this data all along, and the script simply makes extraction straightforward—exactly what you want from a FinOps tool.

Gather a Last60Days / P3Y export for your highest-spending scope, chart the hourly line, and make a Savings Plan decision based on the numbers you can reference. Your future self—and your finance partner—will be grateful.