Welcome to the Learning FOCUS blog series. If this is your first post, I recommend you start with Introducing an open billing data format to get a high-level picture of what the FinOps Open Cost and Usage Specification (FOCUS) is and what it covers. This week, I’ll cover the columns that explain how much you used or purchased, the price, and how to calculate each type of cost with these columns. While this topic may seem straightforward, I’ll get into a tiny bit of internal details to explain how our FOCUS dataset helps you understand and process details better than other datasets, so you may find this one interesting.

⮜ Previous post (Commitment discounts)   ·   Next post (Savings) ⮞

Understanding the different types of quantities

With respect to a “charge” or row in a FOCUS cost and usage dataset, a quantity is the decimal amount of the SKU that was used or purchased. The quantity is measured in “units,” but we’ll discuss that more in the next section. This seems fairly straightforward, but there are of course nuances, specifically in how each unit is measured and priced by the provider. I’ll start by outlining these differences with an analogy:

Let’s say you want to buy 10 notebooks. You can buy these notebooks individually for, let’s say $2 per notebook. That’s a quantity of 10 with a unit of “Notebooks” and a price of $2. Simple.

Now, let’s say there’s an option to buy a pack of 5 notebooks together for $8. You still want to buy 10, so now that’s a quantity of 2, The base unit is still “Notebooks”, but now you’re buying them in a pack of 5. We refer to this as the “block size”.

At the end of the day, you’re still going home with 10 notebooks. The only thing that changed in these examples is how they were packaged and priced. With this example, we can differentiate the “pricing” quantity of “blocks” that were purchased from the distinct number of units that we actually took home. In FOCUS, these are represented by the PricingQuantity and the ConsumedQuantity.

The PricingQuantity represents the amount of units that were used or purchased based on how the provider sizes and groups the units for that SKU.

The ConsumedQuantity represents the amount of distinct units that were actually used, regardless of how the provider offers them in bulk or individually. Note that ConsumedQuantity does not apply and will be null (or empty) for purchases.

For a real-world example, let’s say you use 24 hours of a VM, but the provider bills usage in 100 hour blocks. Your PricingQuantity would be 0.24 (blocks of 100 hours) and your ConsumedQuantity would be 24.

Okay, now let’s try something a little more complex… Let’s say you have a coupon or “credit” to buy these 10 notebooks, but the store offers some flexibility on how you buy them. Let’s say they also offer 5-section notebooks for $10 each and the store is willing to offer “size flexibility” for the notebooks you purchase by applying a sizing factor or “normalization ratio”. In this case, five single-section notebooks = one 5-section notebook. So, you can purchase 10 single-section notebooks or you can buy two 5-section notebooks with the same credit.

In the cloud, this is used with commitment discounts and is referred to as instance size flexibility (ISF) and the multiplier is sometimes referred to as a “normalization ratio”. This ratio is usually based on the specs of the SKU you used compared to a base or normalized SKU. In FOCUS 1.1, this quantity is known as the CommitmentDiscountQuantity.

The CommitmentDiscountQuantity represents the amount of units that were used or purchased after applying the sizing factor or normalization ratio for the SKU that was used. If size flexibility doesn’t apply, then CommitmentDiscountQuantity will be the same as ConsumedQuantity.

For a real-world example, let’s use the same 24 hours example from earlier. Imagine your commitment discount is for a 2-core SKU, but you use it with an 8-core SKU that has a 4x normalization ratio. This means that it would only take 6 hours to consume the 24 committed hours (6x4=24). Your ConsumedQuantity would be 6 and your CommitmentDiscountQuantity would be 24. The remaining 18 hours would be in a separate row that was not linked to the commitment discount, since you already exhausted the commitment for the day.

Note that CommitmentDiscountQuantity is not in the Cost Management FOCUS dataset yet. This will be available in a future FOCUS dataset update.

Understanding units in FOCUS

Each quantity column in FOCUS is coupled with a matching unit column. But before we look at the differences between those, let’s start by understanding what values you can expect to see within a unit column.

Each unit column indicates what type of measurement is used to generate each specific quantity. Units can be based on:

• Objects (e.g., Tokens, Requests, Cores)
• Data size (e.g., MB, GB, TB)
• Time intervals (e.g., Hours, Minutes, Seconds)
• Composite of object type or size with a time interval (e.g., Tokens/Hour or GB-Hours)

There is a less desirable affordance for numbers mixed into these, like “100 Hours” or “Units/3 Months”; however, we generally try to avoid these more complex units that are more difficult to break down into distinct units.

As I mentioned, each quantity is coupled with a specific unit, which describes what that number means:

• PricingUnit describes what is measured for pricing purposes.
• ConsumedUnit describes the distinct, real-world usage measure, which is usually the same as the PricingUnit.
• CommitmentDiscountUnit describes the normalized usage measure, if applicable. If normalization is applied, then the unit will indicate that it’s a normalized unit; and if not, it will be the same as ConsumedUnit.

Reusing our example from earlier, I may have a PricingQuantity of 0.24 “blocks” of 100 hours (where the PricingUnit is “Hours”), a ConsumedQuantity of 24 (where the ConsumedUnit is also “Hours”), and assuming the 4x size flexibility ration also applies for this SKU, we would see CommitmentDiscountQuantity of 6 and a CommitmentDiscountUnit of “Normalized Hours”. If size flexibility wasn’t applicable, then it would be “Hours”. And if we were looking at a spend commitment, like Azure savings plans, the CommitmentDiscountUnit would be the pricing currency (e.g., EUR, JPY, or USD).

Again, as a reminder, CommitmentDiscountQuantity and CommitmentDiscountUnit are part of the FOCUS 1.1 specification and are not available in Cost Management FOCUS 1.0 exports.

I suppose the only thing left to call out is that these units were actually parsed out of the native UnitOfMeasure column in the Cost Management actual and amortized datasets. In FOCUS, this is the x_PricingUnitDescription column, which generally contains both a number for the block size and the unit together in a single string. FOCUS splits these into the x_PricingBlockSize and PricingUnit columns where x_PricingBlockSize is the number of “blocks” the PricingQuantity is measured in. Given the pricing per 100 hours example, the x_PricingUnitDescription would be “100 Hours”, the x_PricingBlockSize would be 100, and the PricingUnit would be “Hours”.

Of course, not all UnitOfMeasure/x_PricingUnitDescription values are this straightforward. You also have values like “10K” or “10000 1,000s”. Our goal with the FOCUS dataset is to simplify these to make it easier for you to validate and work with the data across SKUs.

Comparing the different types of quantities

To sum everything up, PricingQuantity represents the amount of PricingUnit values that were used or purchased and x_PricingBlockSize indicates how many units were in each “block.” Using our example:

And if you want to look at the distinct units without block pricing, you can use ConsumedQuantity and ConsumedUnit:

Note that x_PricingBlockSize doesn’t apply here. It’s only applicable to the PricingQuantity and PricingUnit. That said, it is useful when comparing numbers:

PricingQuantity × x_PricingBlockSize = ConsumedQuantity

0.24 * 100 = 24

Or you can work backwards:

ConsumedQuantity / x_PricingBlockSize = PricingQuantity

24 / 100 = 0.24

When introduced, CommitmentDiscountQuantity should have a custom column paired with it for the normalization ratio to support converting to and from ConsumedQuantity. I’ll share more after Cost Management adds support for FOCUS 1.2.

Understanding the different prices

We already covered costs in one of the earliest blog posts in this series. FOCUS 1.0 includes prices for ListCost and ContractedCost, but not for BilledCost or EffectiveCost. We understand how important validating data is, so we also include prices for those in our FOCUS dataset. Remember that all prices are based on the PricingUnit and x_PricingBlockSize.

• ListUnitPrice is the public, retail price per pricing unit block. This is the price you would have paid without any discounts.
• ContractedUnitPrice is the on-demand price per pricing unit block. This is the price you would have paid after negotiated discounts, but without commitment discounts.
• x_BilledUnitPrice is the price you were billed for on your invoice. This matches what you would see within the actual cost dataset in Cost Management and would be 0 for amortized usage that doesn’t show up on the invoice.
• x_EffectiveUnitPrice is the logical price you would see after commitment discount purchases are amortized. This matches what you would see within the amortized costs dataset in Cost Management and will be 0 for commitment discount purchases that are amortized over time with usage rows.

We’ve already covered these concepts, so this part’s pretty simple.

Calculating cost (price × quantity)

Time for more math! This should seem basic, but calculating cost is as simple as multiplying price times quantity. The key in validating the costs is making sure you always use the PricingQuantity and match the right price and cost columns.

x_BilledUnitPrice × PricingQuantity = BilledCost

x_EffectiveUnitPrice × PricingQuantity = EffectiveCost

ContractedUnitPrice × PricingQuantity = ContractedCost

ListUnitPrice × PricingQuantity = ListCost

Of course, you can definitely use the ConsumedQuantity, but you will need to make sure to account for the x_PricingBlockSize to ensure the numbers add up correctly. But generally, we recommend using the PricingQuantity to avoid floating point math issues.

Transitioning to FOCUS

Whether you’re updating reports, transforming data, validating FOCUS, or simply curious about how FOCUS compares to the historical actual and amortized datasets, you’re probably looking for a more direct mapping of columns. We have separate articles covering each of these scenarios in more detail, but here’s a summary regarding the date columns I covered above.

For more details, refer to the following articles:

• Update reports to use FOCUS columns
• Convert cost and usage data to FOCUS
• Validate FOCUS data

Reviewing cost in Power BI

Despite how core quantities and prices are to FinOps, we generally don’t spend much time looking at either. We typically focus more on cost as the product of quantities and prices. But let’s look at a few places where quantities and prices are surfaced in the FinOps toolkit Power BI reports.

We’ll start with the new Usage analysis page coming to the Cost summary report. This page shows your consumed quantity over time broken down by meter category (x_SkuMeterCategory) with an overlay of the total cost during that period, plus the total cost, usage, and price for each type of charge in a table.

You’ll also notice the block size (x_SkuBlockSize) for each charge, which is important to validating the price times quantity math since we’re showing the consumed quantity. In this case, you can use x_EffectiveUnitPrice × ConsumedQuantity / x_PricingBlockSize.

Next, we’ll look at the Purchases page, which shows the price, quantity, and cost for each purchased SKU. The one special note on this page is that we’re using PricingQuantity since ConsumedQuantity only applies to usage charges.

And now, let’s look at the Prices page, which lists the SKUs that were used during the period with the list, contracted, and effective price; consumed quantity; consumed unit; block size; and cost for each.

You’ll also find the Purchases and Prices pages in the Rate optimization report where they focus exclusively on commitment discount SKUs.

To wrap things up, I’ll share a few pages from the new Invoicing and chargeback report coming out in the next FinOps toolkit release. There are two Invoice recon pages to facilitate reconciling billed charges on your EA or MCA invoice with cost details you see in Cost Management. Both pages have the same basic layout to visualize the services used during the billing period, but the table in each report attempts to align to the information available on the respective invoices, which includes the unit price, quantity, and cost.

To learn more about these and other reports, see FinOps toolkit Power BI reports.

Querying cost in FinOps hubs

Now let’s look at a few queries you can run using FinOps hubs. These are all fairly simple based on what we’ve covered already. The most important things you need to remember are:

• Quantities can only be summed when they represent the same unit and block size.
• ConsumedQuantity does not apply to purchases, so you will need to use PricingQuantity to measure purchases.
• Prices cannot be summed up or averaged.

With these points in mind, let’s start with a simple view of what we’re billed for:

Costs
| summarize
  PricingQuantity = sum(PricingQuantity),
  BilledCost = sum(BilledCost)
  by
  ChargeDescription,
  PricingUnit,
  x_PricingBlockSize,
  x_PricingUnitDescription,
  x_BilledUnitPrice
| project-reorder ChargeDescription, x_PricingUnitDescription, x_PricingBlockSize, PricingQuantity, PricingUnit, x_BilledUnitPrice, BilledCost
| order by BilledCost desc

You’re not seeing it in the screenshot, but there are a number of SKUs with a block size over one, so let’s look at the distinct usage of specific SKUs:

Costs
| where ChargeCategory == 'Usage'
| summarize
  ConsumedQuantity = sum(ConsumedQuantity),
  BilledCost = sum(BilledCost)
  by
  ChargeDescription,
  ConsumedUnit,
  x_PricingBlockSize,
  x_PricingUnitDescription,
  x_BilledUnitPrice
| project-reorder ChargeDescription, x_PricingUnitDescription, x_PricingBlockSize, ConsumedQuantity, ConsumedUnit, x_BilledUnitPrice, BilledCost
| order by BilledCost desc

This will look the same given my test account doesn’t have many purchases and the screenshot isn’t showing anything with a larger block size, so let’s filter it down to show the difference:

Costs
| where ChargeCategory == 'Usage'
| where x_PricingBlockSize > 1
| summarize
  PricingQuantity = sum(PricingQuantity),
  ConsumedQuantity = sum(ConsumedQuantity),
  BilledCost = sum(BilledCost)
  by
  ChargeDescription,
  PricingUnit,
  ConsumedUnit,
  x_PricingBlockSize,
  x_PricingUnitDescription,
  x_BilledUnitPrice
| project-reorder ChargeDescription, x_PricingUnitDescription, x_PricingBlockSize, PricingQuantity, PricingUnit, ConsumedQuantity, ConsumedUnit, x_BilledUnitPrice, BilledCost
| order by BilledCost desc

This is pretty straightforward. PricingQuantity is smaller based on the number of units per “block”. You may also notice there are some very small quantities, like in the first example which has “449” starting in the 15^th decimal place. These tiny numbers are most likely floating point math errors. This is the same as “rounding errors” you may see at the end of each month. They’re important because you may find that price times quantity doesn’t add up exactly because of these small decimal values. This is a general computing issue and not related to anything Microsoft is doing.

You can use the same queries with other prices and costs if you want to see the effective, contracted, or list cost. And of course, we can also compare prices to calculate per-SKU discounts, but I’ll save that for the next blog post where we talk about discounts and savings.

There’s a lot more we could cover using the same columns for different unique scenarios, like commitment discounts and Azure Hybrid Benefit. Let me know what you’d like to see covered and I’m happy to write dedicated blog posts to dig into anything.

What next?

At this point, we have a high-level understanding of the types of charges we’re incurring, how much we’re being charged, when we incurred those charges, what resources we deployed that incurred the charges, what services those resources rolled up to, the underlying SKUs we were charged for, how to identify and describe purchases, how to identify and measure commitment discounts, and how to verify prices and costs. Next, we’ll cover something everyone is interested in as part of our efficiency efforts: calculating discounts and savings.

If you need a refresher or have any questions about previous topics, this is a good time to review them. We’ll touch on a little of everything given the overlapping concepts.

• Introduction
• Costs
• Charge types and pricing models
• Dates
• Resources
• Services
• SKUs
• Purchases
• Commitment discounts

For a more directed walkthrough, the FinOps Foundation offers a free Introduction to FOCUS course. When you’re ready to dig into your own FOCUS data, check out the Power BI reports in the FinOps toolkit. These reports offer a great starting point that you can customize to meet your needs. And if you’re looking for more advanced analytics that can handle data at scale, check out FinOps hubs, which offer additional benefits, like pre-calculated savings for EA and MCA accounts.

 

⮜ Previous post (Commitment discounts)   ·   Next post (Savings) ⮞