• <1 minute

Azure cost forecast API and other updates

As your cloud spend starts to increase, being able to accurately forecast usage becomes a critical part of your plan. As the first step in enabling a forward looking view to your spend on a…

As your cloud spend starts to increase, being able to accurately forecast usage becomes a critical part of your plan. As the first step in enabling a forward looking view to your spend on a subscription we’re launching a forecast API. The forecast API today supports a daily or monthly grain forecast at a 95 percent confidence interval. The API also returns the last two months of actual usage that should help in looking at any trending scenarios. For future iterations of the API, we plan to support multiple other scopes up and down the hierarchy, like resource groups and enrollments, options for confidence intervals and longer range forecasts. Check out the documentation page for more details on calling the forecast API.

Location and service data normalization

Effective cost management for enterprise customers requires accurate and granular data that can be dimensionalized to support ad hoc queries and accurate rollups of costs in the enterprise hierarchy. As the first step to make the usage data adding more dimensions, we are normalizing the location (InstanceLocation) and service (ConsumedService) fields as there are a few data quality issues with multiple variants of data in these columns. The dimensions currently supported are tags and resource groups, with this release we will now be adding location and service as dimensions. Location will manifest as a new column called Location and service will manifest itself as two new columns, namely ServiceName and ServiceTier. This should ensure moving to the new API version is backward compatible. These changes will be available in the API version 2018-06-30.

Price sheet mapping to usage Details

The price sheet API is a union of the prices for each applicable meter for each offer. As a result for customers with multiple offers, there was no deterministic way to identify which specific instance of a meter was used to price a usage record in the usage details. This update to the APIs (version 2018-05-31) introduces a few new attributes on the usage details to correlate usage with the price sheet. For customers looking to map the price sheet to the usage details, joining the two datasets on the following columns will result in a unique match between the usage details row and the meter price.

New fields in usage details API

  • OfferId
  • PartNumber
  • ResourceGuid

New fields in price sheet API

  • OfferId

This change update affects both the key based API and the ARM API.

Monetary commit ineligible charges

Enterprise customers with a monetary commit have usage applied to the available credit first before an invoice is generated. In some instances, certain charges are not credit eligible and will be invoiced. The feedback we have received is that it’s cumbersome to try and determine which charges are monetary commit eligible. As a result, the usage details API is being updated to add an additional attribute to flag charges billed separately.

New field in the usage details API

  • ChargesBilledSeperately

Late Arriving Data

To accommodate third party services that have delays in reporting usage, the reported usage date (usage report date) is set to the time at which the usage data was sent as opposed to when the actual usage took place (i.e. consumption time). As a result, the usage will be rated for and applied to the reported time. In order to represent the actual consumption time, the properties.AdditionalProperties field will now contain two additional properties ConsumptionBeginTime and ConsumptionEndTime that correspond to the actual consumption time window.

These changes will result in a few scenarios that will need to be addressed when calling the usage details API:

  • Month End Reporting: For usage that occurred during a month but reported during the next month, customers will need to look at the AdditionalProperties field to allocate the usage to the appropriate month if needed.

When querying the usage details API by a date range, the query only applies to usage report date and not the consumption time. For customers looking to map usage details to invoices, this update does not affect the process as the invoice will process the usage based on the usage report date. For customers looking to map usage details to a specific calendar date/month, this update is a breaking change and for these scenarios the usage report date cannot be used  and the date that the usage occurred (i.e. the consumption date) in the additional properties section must be used.

PowerShell support

As the Cost Management APIs grow in complexity, we are adding support for PowerShell in addition to the supported SDKs (Python, NodeJS, .Net, and Ruby). The documentation page has additional details on the cmdlets.