How to Set Up Data Collection Rules (DCR) for Azure Kubernetes Service (AKS)
May 7, 2025Monthly news – May 2025
May 7, 2025Welcome 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 identify and describe commitment discounts. This might be one of the most interesting topics in a FOCUS dataset given how critical rate optimization is for FinOps practitioners. There’s a lot more here, so buckle up…
⮜ Previous post (Purchases) · Next post (Prices + quantities) ⮞
What is a commitment discount?
Simply put, a commitment discount is a reduced unit price applied to specific SKUs when you commit to using a specific amount. Each commitment is measured over a specific period for the duration of the commitment term. And by “committing,” you are promising to use that amount. And this isn’t like how my kids “promise” to clean their room when they get home from school. In this case, you will be charged for the amount regardless of whether you use it or not. This is where the period comes in. You have the entire length of the period to use the agreed upon amount. And to facilitate tracking and eliminating waste, you can also identify the “used” and “unused” amounts, but we’ll get to that later.
But all of that was a bit abstract. Let’s look at a few examples to clarify…
Let’s say you commit to using a virtual machine for a year, where the billing is quantified by compute hours. The specific amount is 1 hour, the specific period is hourly, and the commitment term is 1 year. When you use the full hour, you’ve “utilized” the entire commitment. This is perfect. But maybe you don’t need it, so you shut it down. This is tracked as an unused amount, but that isn’t necessarily a bad thing. We’ll discuss this more later. The important thing to understand is the amount that you’re committing to for each period over the term. When you don’t use the full amount in a period, the remainder is an “unused” charge.
Another example might be committing to Azure Databricks. Azure Databricks usage is billed as “Databricks units” or DBUs and commitments work different than the virtual machine example. In this case, you’re committing to using a specific amount – let’s say 300,000 DBUs – for the entire term. For Azure Databricks, the period is the entire commitment term. So, the specific amount is 300,000 DBUs, the specific period is 3 years, and the commitment term is 3 years. Unlike virtual machines, where you’re charged for using 1 hour every hour, you have the full term (3 years) to use DBUs. In our example of 300,000 DBUs, let’s say you use that in the first 3 months. Great! 100% utilization and the commitment is fulfilled. But let’s say you only use 100,000 DBUs by the end of the 3 years. The remainder (200,000 DBUs) will be charged as an unused amount after the commitment discount expires. (Side note: To be precise, non-committed usage is referred to as DBUs and committed usage is referred to as DBCUs or “Databricks commit units.”)
And I can’t leave out the newest option: Let’s say you want to commit to spending a certain amount, but you want the freedom to choose what service you use. Since different services may be measured by different units, you’re actually committing money rather than usage. So, let’s say you commit to spending $10 per hour on compute usage for 3 years. The specific amount is $10, the specific period is hourly, and the specific commitment term is 3 years. This works the same as the virtual machine example except that you’re measuring cost rather than usage quantity. So, in this case, let’s say you spend $15 in an hour, $10 will be covered by the commitment discount and the remaining $5 will be standard, on-demand amount. But if you only spend $5 in an hour, your commitment is only 50% utilized and you will see an extra $5 charge for the unused amount.
I won’t go into the specifics of each of these options, but in Microsoft Cloud we refer to them as:
- Reservations – Per-period usage commitments, like virtual machine hours.
- Pre-purchase plans – Term-wide usage commitments, like Azure Databricks DBUs.
- Savings plans – Per-period spend commitments, like hourly compute spend.
(You’ll generally see pre-purchase plans managed from the reservations experience in the Azure portal, so that term may be less familiar to some.)
Differentiating from negotiated discounts
I don’t want to take much time on this, but it’s important to distinguish between commitment discounts and negotiated discounts. Commitment discounts are publicly available and usually published offerings that any customer can take advantage of, typically by “purchasing” the commitment discount. Negotiated discounts are typically private agreements between the provider and the customer and apply directly to the customer’s billing account. Commitment discounts are typically predetermined based on list prices while negotiated discounts are – well, negotiated based on varying factors, like potential future spend, loyalty, or other agreements.
Both negotiated and commitment discounts are part of Rate optimization, but they are treated differently in a FOCUS dataset, so it’s worth noting the difference.
Usage, purchases, and amortization
We’ve talked about usage and purchases already. In fact, I think I even mentioned amortization in passing. But when we get into commitment discounts, there are some special behaviors that start to be applied to the data. If you’re familiar with how reservations and savings plans are handled in Cost Management actual and amortized datasets, this will all be very familiar to you. If you’re more familiar with other providers, this is important to understand as how commitment discount usage and amortization is handled in FOCUS may differ from what you’re used to.
Commitment discounts start with a purchase. To keep it simple, let’s say you purchase a virtual machine reservation (usage commitment) for 1 year. Let’s say you purchase the commitment discount for $365 on January 1, paying everything upfront. This part is straightforward. You’ll see a single row for the $365 purchase with a ChargePeriodStart of January 1. The only thing unique about this row is that you will see a BilledCost of $365 and an EffectiveCost of $0. I’ll come back to this.
Assuming you use the virtual machine every day, you’ll also see one usage charge per day (for daily grain data). But since you prepaid for the usage, your BilledCost is $0. And this is where it starts to get fun: Your EffectiveCost for that daily charge is $1.
This means, if you have consistent usage throughout the year, you’ll see 1 purchase row for a BilledCost of $365 and EffectiveCost of $0 and 365 usage rows for a total BilledCost of $0 and a total EffectiveCost of $365. The beauty of this is that the sum of both BilledCost and EffectiveCost are the same when added up over the duration of the commitment discount. This is referred to as “amortization.”
If you’re familiar with Cost Management actual and amortized datasets, you’ve probably deduced that BilledCost is what you get in the actual cost dataset and EffectiveCost is what you get with the amortized cost dataset. This is a very important distinction about the FOCUS dataset, since both of these datapoints are included in a single dataset.
It’s important to note that some providers may allow you to pay for your commitment discount over time rather than all upfront. The only difference is that, instead of a single purchase record on January 1 for $365 with a ChargeFrequency of “One-Time”, you will see $31 on January 1, $28 on February 1, and so on. Each of the monthly purchase rows will have a ChargeFrequency of “Recurring”.
Lastly, let’s also cover how unused amounts work. (This is one that differs across providers.) The purchase is the same, whether one-time or recurring. But let’s say you only use 18 of the 24 hours. You will see two charges – one $0.75 charge for the virtual machine usage and one $0.25 charge for the amount that was not used. The unused amount is tied to the commitment discount rather than a virtual machine, since there was no usage. We’ll see examples in a bit.
I suppose it may be worth calling out that commitment discounts are not bound to a specific resource. While you can scope them down to a specific resource group, which may only have a single applicable resource, they are still not tied to that resource directly. Commitment discounts can hypothetically be applied to multiple resources, even within a single hour. This is why the unused amount isn’t linked to a single resource.
Identifying commitment discounts
We’ve pretty much covered the basics of everything. And this is probably enough for a single blog post, but since we’re learning FOCUS, let’s get into the columns…
Every row that applies to a commitment discount has a unique identifier specified in the CommitmentDiscountId column and a friendly name in the CommitmentDiscountName column. These are the same as BenefitId and BenefitName in actual and amortized datasets and logically similar to ReservationId and ReservationName, although the ID columns differ.
One important distinction about CommitmentDiscountId and CommitmentDiscountName in Microsoft Cloud, which may differ from other providers, is that purchases use the commitment discount order rather than the instance. This simplifies splitting and exchanging subsets of a commitment discount order, which can cover many instances (e.g., 100 virtual machines). This distinction is important because the total BilledCost for a specific CommitmentDiscountId will not have matching EffectiveCost rows. If you need to map purchase and usage records, use the x_SkuOrderId and x_SkuOrderName columns for commitment discount rows. These represent the unique ID and name of the entitlement purchase, which we discussed in the last post on purchase columns.
Differentiating types of commitment discounts
There are two types of commitment discounts available today: usage-based or spend-based commitments. FOCUS refers to this as the CommitmentDiscountCategory. CommitmentDiscountCategory is a standardized, provider-agnostic type that describes how the commitment discount is measured with two possible values: “Usage” and “Spend”. Usage-based commitment discounts involve committing to a specific quantity of usage, like 24 hours per day or 300,000 DBCUs over 3 years, using the examples we discussed earlier. Spend-based commitment discounts involve committing to a specific cost (or “spend”) per hour.
Usage commitment discounts are referred to as reservations in Microsoft cloud and spend commitment discounts are referred to as savings plans. This provider-specific display name is known as the CommitmentDiscountType in FOCUS. This is similar to ResourceType for resources.
When you need a specific type descriptor, use CommitmentDiscountType. When you need to summarize data across providers, use CommitmentDiscountCategory.
Tracking commitment discount utilization
Perhaps the most important aspect of commitment discounts is whether they’re being used or “utilized”. FOCUS tracks utilization using the CommitmentDiscountStatus column.
When CommitmentDiscountStatus is “Used”, ResourceId and related columns refer to the resource that was covered by the commitment discount benefit. You’ll see $0 BilledCost and a lower EffectiveCost than you would normally see based on the amount of usage.
When CommitmentDiscountStatus is “Unused”, ResourceId and related columns refer to the commitment discount instance (not the order). Again, you’ll see $0 BilledCost, since that’s covered by the purchase, and EffectiveCost represents the amount that wasn’t covered by other usage. So, if you used a virtual machine for 18 hours, then the unused portion would be 6 hours since the commitment was for 24 hours.
One last important thing to keep in mind regarding the unused portion of commitment discounts is that the unused amount is only available when exporting data at a billing account or billing profile scope. When you export data at a subscription or even a department or invoice section scope, the unused records are not included, so cost and savings calculations are not complete.
You can probably deduce how to calculate utilization, but I’ll save that for later, when we start to dig into some sample queries.
Additional details about commitment discounts
We’ve already covered these in previous blog posts, but as a refresher, here are a few other columns that relate to commitment discounts:
- x_SkuTerm represents the number of months for the commitment discount. This can be 1, 12, 36, or 60.
- x_SkuOrderId and x_SkuOrderName represent the commitment discount order ID and name. I mentioned this above but want to reiterate that this will help you map the purchase and usage records together.
- ChargeFrequency will indicate whether the purchase is a one-time or recurring, monthly payment. This can be helpful when tuning a custom forecasting algorithm.
- PricingCategory is always “Committed” for commitment discount usage and “Standard” for the purchases (since the purchases themselves were not committed to).
- x_PricingSubcategory is either “Committed Usage” or “Committed Spend” for usage depending on what type of commitment discount was purchased. Purchases are “Standard”. This column can be helpful for breaking down usage to get a high-level, simple breakdown of committed vs. spot vs. on-demand usage.
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.
Cost Management |
FOCUS |
BenefitId / ReservationId |
CommitmentDiscountId |
BenefitName / ReservationName |
CommitmentDiscountName |
ChargeType |
CommitmentDiscountStatus |
(none) |
CommitmentDiscountCategory |
(none) |
CommitmentDiscountType |
Frequency |
ChargeFrequency |
PricingModel |
PricingCategory |
PricingModel |
PricingSubcategory |
ProductOrderId (MCA only) |
x_SkuOrderId |
ProductOrderName (MCA only) |
x_SkuOrderName |
Term |
x_SkuTerm |
For more details, refer to the following articles:
Reviewing cost in Power BI
Since we’re covering commitment discounts, we’ll focus on the FinOps toolkit Rate optimization report.
Starting from the top, we’ll first look at the Summary page. This page shows a high-level breakdown of the different types of cost covered in a FOCUS dataset and shows the negotiated discount and commitment discount savings by comparing ListCost, ContractedCost, and EffectiveCost. I won’t go into detail about about this page today, but I wanted to share it because one important aspect of commitment discounts is understanding how much you’ve saved. If you look at the second row of KPIs, you’ll see that ContractedCost – EffectiveCost gives you your commitment discount savings. Of course, it’s not quite that simple. We need to filter out the commitment discount purchases to ensure savings are calculated correctly. I’ll discuss this in a future blog post.
Next, let’s jump to the Commitment discount savings page. This page shows commitment discount savings achieved over time, broken down by commitment discount type in the chart and by commitment discount instance in the table.
Next, we’ll look at the Commitment discounts page, which shows the list of commitment discount instances and a chart of used vs. unused costs. This page also shows utilization and savings per commitment discount instance.
Next, is the Chargeback page. This page shows commitment discount usage broken down by subscription and resource group. This page, like many others, is a starting point and is meant to be customized. While it starts with a matrix visual grouped by subscription and resource group, maybe you only need one of those levels. Maybe you need tags. Customize the page to meet your unique needs.
Next up is the Reservation recommendations page, which joins the FOCUS cost with reservation recommendations from Cost Management. The FOCUS data is used to show cost over time, break-even point, and CPU hours for the virtual machines that would be covered by the recommendations.
Lastly is a page I’ve shared a few times: the Purchases page. This page lists all commitment discount purchases for the selected period, showing the date, publisher, SKU description, charge frequency, and a few other columns.
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. Let’s start with a simple list of commitment discount purchases:
Costs
| where ChargeCategory == ‘Purchase’
| where isnotempty(CommitmentDiscountCategory)
| summarize
BilledCost = round(sum(BilledCost), 2)
by
ChargePeriodStart,
ChargeClass,
x_SkuDescription,
x_SkuTerm
| order by ChargePeriodStart desc
We used BilledCost in the previous query since we were looking at purchases. You’ll see $0 EffectiveCost since the cost is amortized across usage records.
Since purchases are reservation orders and usage is tracked at a reservation instance level, let’s look at all the reservation instances within an order. Note that this can change over time if reservations are split or exchanged.
Costs
| where ChargeCategory == ‘Usage’
| where isnotempty(CommitmentDiscountCategory)
| summarize
EffectiveCost = round(sum(EffectiveCost), 2),
ChargePeriod = datestring(
min(ChargePeriodStart),
max(ChargePeriodStart)
)
by
CommitmentDiscountType,
x_SkuOrderName,
CommitmentDiscountName,
x_SkuDescription,
x_SkuTerm
| order by EffectiveCost desc
And let’s say we want to see the resources covered by a specific commitment discount:
Costs
| where ChargeCategory == ‘Usage’
| where isnotempty(CommitmentDiscountId)
| summarize
EffectiveCost = round(sum(EffectiveCost), 2)
by
CommitmentDiscountType,
CommitmentDiscountName,
CommitmentDiscountStatus,
ResourceName,
ResourceType
| order by
CommitmentDiscountName,
EffectiveCost desc
You may notice some rows where the ResourceName is the same as the CommitmentDiscountName column. These are the unused amounts.
Now let’s calculate utilization based on the CommitmentDiscountStatus column:
Costs
| where ChargeCategory == ‘Usage’
| where isnotempty(CommitmentDiscountId)
| summarize
x_CommitmentDiscountUtilization = round(
sumif(EffectiveCost, CommitmentDiscountStatus == ‘Used’)
/ sum(EffectiveCost) * 100, 2),
EffectiveCost = round(sum(EffectiveCost), 2)
by
CommitmentDiscountType,
CommitmentDiscountName
| order by
x_CommitmentDiscountUtilization asc,
CommitmentDiscountName asc
The next consideration is probably calculating savings, but I’ll save that for a future blog post.
There’s a ton in this space and I’m not covering everything here. 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, and how to identify and measure commitment discounts. Next, we’ll cover prices, quantities, and calculating costs.
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.
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 (Purchases) · Next post (Prices + quantities) ⮞