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 describe the SKUs that were used or purchased within your account. SKUs represent the goods and services that you’ll find within your cost and usage data. We’ll cover a lot of Microsoft-specific columns this week and talk a little about some future plans with FOCUS.

⮜ Previous post (Services)   ·   Next post (Purchases) ⮞

What is a SKU?

A SKU, or stock keeping unit, is a unique code used to identify and track a specific product within a business's inventory. SKUs allow businesses to differentiate between similar items based on attributes like size, color, style, or other variations. Retailers, warehouses, and e-commerce platforms often use SKUs to streamline inventory management, track sales, and improve customer service. The same applies with cloud computing.

FOCUS defines a SKU as a quantifiable good or service offering that represents specific functionality and technical specifications. Examples of SKUs include but are not limited to:

• Product licenses that are purchased or subscribed to.
• Professional services that are purchased or used over time.
• Usage of a deployed resource from direct user interaction (e.g., request count).
• Usage by a deployed resource based on the resource's configuration (e.g., running hours, storage space).

I find the last scenario most interesting because many people don’t think about the fact that most of your usage comes from your resource consuming a SKU rather than you directly consuming that SKU. For instance, if you have a running VM, then you’ll be charged compute hours. You didn’t do anything to incur each hour. Yes, you started the VM, but the fact that it was running is what you’re being charged for. Same for storage space. You added content once, but you’re being charged for that existing over time, regardless of whether you interact with the resource. In contrast, other services charge based on direct interaction, like requests or operations that you perform directly. When you stop, there won’t be any more charges.

Also interesting is that SKUs can be used across resource types. SKUs aren’t explicitly bound to a single service. Bandwidth is a great example since it applies to VMs, storage, App Service, app gateways, and so much more. Internalizing this, you start to recognize that SKUs don’t necessarily have a direct relationship to the services you use.

You interact with services through specific resource types. Separate from that, the cloud is monitoring those resources and how you interact with them and charging you based on predetermined, measurable “meters”.

The word “meter” is often confusing when you first hear it in this context. But think about it as you would the power or water meter you have at your house. Utility companies monitor your use of electricity, gas, and water via a device which tracks how much you’ve used. We often refer to the device as the “meter” but the word can also be applied to the measurement. In FOCUS, we’re referring to the measurement. Not the unit, but the thing being monitored and measured.

Of course, the meter is just one of the many properties of a SKU. We’ll cover what’s included in FOCUS today, what’s available in the Microsoft dataset, and what’s coming to FOCUS in the future in the next few sections.

Identifying SKUs and their unique price points

When you first think about a SKU, you might assume each SKU has a single price. To use a popular example from our internal FOCUS conversations, let’s say I sell notebooks. My “product” is a notebook, and I may offer many SKUs of notebooks – yellow, wide-ruled notebooks are different from blue, college-ruled, 5-section notebooks. Obviously, these would be sold at different price points. But now let’s take this a bit further.

Let’s say I sell my blue, college-ruled, 5-section notebook in Japan, Norway, and Brazil. Setting aside currency conversion, producing, shipping, and selling my notebooks in each country will incur different costs and therefore require being sold at different price points. Pretty straightforward. This is one of the simplest ways to see how we need to differentiate products, SKUs, and what FOCUS calls a “SKU price”.

To explore another example, let’s say I offer a subscription service for my notebooks. You can buy them as you need them (aka, “on-demand”) or you can subscribe to get a new notebook every month for a lower price – effectively, a commitment discount. While there’s a commitment to purchase more than one notebook, each notebook has a different effective unit price, which means it’s represented by a different “SKU price”.

FOCUS uses the SkuId and SkuPriceId columns to differentiate between each SKU and its individual price points. Unfortunately, the exact definition of the difference between these two columns is not very well defined in the current versions of FOCUS, but the underlying intent was for a SkuId to represent the specific functionality you’re using or purchasing and for SkuPriceId to account for the pricing variations that differ beyond the common functionality and technical specifications, such as:

• How the SKU is priced (e.g., pricing category).
• Where the SKU was used or purchased.
• Service level agreements for the SKU.
• Availability of the SKU (e.g., spot VMs).

The ultimate goal is to be able to evaluate all the pricing options for the functionality defined by the SkuId. Those pricing variations come with different decisions that may impact how you use the resource – like whether you’ll use it consistently throughout the year for commitment discounts or if you can tolerate inconsistent, interruptible use with spot VMs, as an example. Even regional availability requires forethought given the potential impact of inter-region communication (and added cost) within your architecture. Evaluating these options is conceptually enabled via SkuId.

That said, while this is the underlying intent of SkuId and SkuPriceId, the current definition and requirements aren’t as explicit as they should be, and providers have existing implementations that don’t cleanly line up to this desired outcome. For now, this is a bit of a future goal of the specification, which makes these columns a bit difficult to depend on consistently across providers. Because of this, I won’t use SkuId and SkuPriceId in any examples today. They simply aren’t ready for use at scale today, but it is still important to understand their intent as we discuss aspects of a SKU.

Understanding the properties of a SKU

The only SKU properties included in FOCUS 1.0 were SkuId and SkuPriceId. As such, I’ll mainly focus on Microsoft-specific columns here, but I’ll also call out what’s defined in FOCUS 1.1 and what’s coming in FOCUS 1.2 for additional context.

I’ll start with x_SkuDescription, which is a long-form text description of the SKU that was used or purchased. This holds the same value as ProductName in the native Cost Management datasets. A few examples include:

• Virtual Machines Ddv4 Series - D2d v4 - US West Central
• Premium SSD Managed Disks - P4 LRS - UK West
• SQL Database SingleDB/Elastic Pool Hyperscale - SQL License – vCore

Earlier, I mentioned the concept of a “meter”. If you’re familiar with Cost Management’s native datasets, you’re probably familiar with this construct. In the Microsoft FOCUS 1.0 dataset, you’ll find x_SkuMeterName and x_SkuMeterId for the name and identifier for the functionality being measured for the SKU. In FOCUS 1.1 and beyond, x_SkuMeterName will be renamed to SkuMeter. FOCUS doesn’t identify an identifier for the meter.

Those with Enterprise Agreement (EA) accounts will also recognize the x_SkuPartNumber column. While this column is available in FOCUS datasets for Microsoft Customer Agreement (MCA) accounts, it will always be empty as it is no longer applicable.

Next, I want to cover the set of columns that help differentiate the pricing variations of a logical SkuId:

• x_SkuRegion is the region assigned to the meter. Note that this may be different from the resource region in some cases, like cross-region networking scenarios.
• x_SkuTerm is the number of months the associated commitment discount was purchase for, if applicable.
• x_SkuTier is the pricing tier for SKUs that offer different prices based on how much you use within the billing period. This column is not currently specified but will be populated in the future.
• x_SkuOfferId is the EA offer ID for the subscription. This is used to identify when dev/test or production pricing are applied to a subscription. This column is empty and not applicable for MCA subscriptions.
• x_SkuOrderId is the MCA entitlement order ID for the subscription or commitment discount. For commitment discount usage and purchases, this is the commitment discount order ID. For other subscription rows, this is the internal ID that indicates whether the subscription has dev/test or production pricing (similar to x_SkuOfferId).
• x_SkuOrderName is a display name for x_SkuOrderId.
• x_SkuCreditEligible is a Boolean value that indicates whether the SKU is eligible to be deducted from credits, like monetary commitments or Microsoft Azure Consumption Commitments (MACC).

Lastly, the x_SkuDetails column is a JSON dictionary of properties applicable for the SKU. This is a list of key/value pairs that will be unique for each SKU. You will find various types of information, like SKU size or Hybrid Benefit usage, as examples. In FOCUS 1.1 and beyond, x_SkuDetails will be renamed to SkuPriceDetails.

Categorizing related SKUs

Now that we’ve covered the properties that make each SKU different, let’s look at how we can categorize and group related SKUs to monitor cost at scale. When we look at how enterprises monitor their costs historically before FOCUS, these are the most commonly used columns because they enable teams to track usage patterns across workloads and departments. With the introduction of ServiceCategory, ServiceSubcategory, and ServiceName, which we discussed in my last Learning FOCUS blog post, I do expect usage of these columns to drop off, but there’s still a need to categorize and monitor SKUs separate from the services that use the SKUs.

Microsoft Cost Management provides three columns to categorize SKUs. But as you look at using these columns, it’s important to acknowledge that their use may differ slightly from one service to another.

• x_SkuServiceFamily is the top-level grouping, which is the logical equivalent of ServiceCategory for SKUs. This will have values like Compute, Networking, and Storage. The values are not standardized or aligned with what you’ll find in ServiceCategory, but they are conceptually similar. This column is only available for MCA accounts.
• x_SkuMeterCategory is typically the name of the service the usage conceptually rolls up to. I say “conceptually” because some SKUs are used across services, so you may see meter categories reused across ServiceName values. Use ServiceName to track usage across categories (e.g., Compute, Networking, and Storage) for a single service and use x_SkuMeterCategory to track usage within a single category (e.g., Compute).
• x_SkuMeterSubcategory is a bit difficult to define because it’s used as a generic grouping mechanism within the context of each individual meter category. Some services use this column to group related SKU sizes into a SKU series or family, while others use this column to organize subcomponents of the meter category.

Despite the inconsistencies in how each service logically categorizes its usage, the one thing you can rely on is having a hierarchical organization of your SKUs, which is immensely important when you’re responsible for a broad spectrum of usage across deployed resources and services that you may not directly manage or even understand.

Aside from general usage reporting and monitoring, SKU categorization is most commonly used for anomaly management and rate optimization. Some organizations also forecast and define budgets to track usage patterns in support of rate negotiations.

A peek into the future of FOCUS

The road ahead for FOCUS has much more to come with respect to SKU details and how those SKUs are categorized. You’ll find changes coming in three areas with respect to SKUs:

• New columns, like SkuSize, for common constructs that apply across many SKUs.
• Well-defined properties in SkuPriceDetails, like CoreCount and DiskSpace, for common constructs within specific types of SKUs, but not necessarily across many SKUs.
• Categorization columns, like SkuCategory, to help organize SKUs into a logical hierarchy.

You’ll see the first two coming in FOCUS 1.2. Categorization columns have not been finalized and will be discussed for future FOCUS releases.

If you’re interested in participating in FOCUS or just want to vote on what you’d like to see next, please check out the FOCUS backlog and vote up 👍 anything you want to prioritize. Your vote matters and will be evaluated as we plan out the FOCUS 1.3 release for November 2025.

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

Due to the nature of SKUs being very specific to each resource, we don’t have many out-of-the-box views for SKU usage in the FinOps toolkit Power BI reports. Of course, we’re not opposed to adding them. We just haven’t received any direct feedback to indicate what areas are most critical to visualize. But that’s not to say we have none…

I briefly covered the Cost summary report’s Charge breakdown page in a previous blog post when discussing charge types and pricing models. I love this page because it offers a visual, interactive breakdown that spans all the hierarchical constructs within a FOCUS dataset. While we haven’t covered everything in the breakdown, we’ve now covered the top three hierarchies. When you look at the Charge breakdown page, you’ll see x_SkuMeterCategory and x_SkuMeterSubcategory are shown after ServiceName to help you break down your service charges into the specific usage categories. This is a great way to visually explore what’s driving costs within each service.

I mentioned earlier that SKUs are commonly used for rate optimization. To that end, the Rate optimization report’s Commitment discount savings page also shows x_SkuMeterCategory and x_SkuMeterSubcategory to help identify the product each reservation was purchased for.

Also in the Rate optimization report is the Hybrid Benefit page, which shows several SKU properties parsed out of x_SkuDetails, like the SKU size, core count, and Hybrid Benefit usage details. This is an example of what type of information you can find in x_SkuDetails.

And lastly, I’ll call out two pages that are in both the Cost summary and Rate optimization reports: Purchases and Prices. As the names imply, these show the SKUs you’ve purchased and the prices for each SKU that has been used or purchased. The difference between the two reports is that Cost summary shows everything while Rate optimization only shows the commitment discount purchases and prices.

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 with Data Explorer. We’ve covered a bunch in this blog post, so there’s a lot of potential queries we could cover. Let’s start with the high-level breakdown of SKUs:

Costs | summarize EffectiveCost = round(sum(EffectiveCost), 2) by x_SkuMeterCategory, x_SkuMeterSubcategory | as d | join kind=inner ( d | summarize CategoryCost = sum(EffectiveCost) by x_SkuMeterCategory ) on x_SkuMeterCategory | sort by CategoryCost desc, EffectiveCost desc | project-away x_SkuMeterCategory1, CategoryCost

Looking at the results, I see Fabric capacity is my top cost. Since I know Fabric capacity is eligible for reservations, let me check to see if that usage is on-demand or committed using PricingCategory:

Costs | where x_SkuMeterSubcategory == 'Fabric Capacity' | where ChargePeriodStart > ago(90d) | summarize EffectiveCost = round(sum(EffectiveCost), 2) by ChargePeriodStart, PricingCategory | render columnchart with ( kind=stacked )

This shows consistent usage every day with the “Standard” pricing category. For those who may not remember, “Standard” means the costs are all on-demand and not reserved. This gives me a good starting point to investigate resource-level usage and purchase reservations as appropriate.

I also saw a number of VM SKUs, so let me look into one of those. I could repeat the last query, but knowing there’ll be more resources involved here, I’ll look at costs broken down by resource and x_SkuMeterName, throwing in ServiceName to demonstrate how services and SKUs aren’t as hierarchical as they may initially seem.

Costs | where x_SkuMeterSubcategory == 'Dv2/DSv2 Series' | summarize EffectiveCost = round(sum(EffectiveCost), 2) by ServiceName, ResourceType, ResourceName, x_ResourceGroupName, x_SkuMeterName | order by EffectiveCost desc

From here, I can do additional investigation like looking at the daily usage for each of the resources, but I’ll skip that to share another example.

Since we’ve covered SKU categories and columns, now let’s look at parsing data out of x_SkuDetails. I’ll use the Azure Hybrid Benefit (AHB) example covered in the Power BI examples. To keep it simple, I’ll look at a summary of resource count, hours, and cost by AHB status and core counts.

Costs | where x_SkuMeterCategory in ('Virtual Machines', 'Virtual Machine Licenses') and ChargeCategory == 'Usage' | extend x_SkuCoreCount = toint(coalesce(x_SkuDetails.VCPUs, x_SkuDetails.vCores)) | extend x_ConsumedCoreHours = iff(isnotempty(x_SkuCoreCount), x_SkuCoreCount * ConsumedQuantity, todecimal('')) | extend x_SkuLicenseStatus = case( x_SkuDetails.ImageType contains 'Windows Server BYOL', 'Enabled', x_SkuMeterSubcategory contains 'Windows', 'Not enabled', 'Not Eligible' ) | extend x_SkuLicenseQuantity = case( isempty(x_SkuCoreCount), toint(''), x_SkuCoreCount <= 8, 8, x_SkuCoreCount > 8, x_SkuCoreCount, toint('') ) | extend x_SkuLicenseUnit = iff(isnotempty(x_SkuLicenseQuantity), 'Cores', '') | summarize x_ResourceCount = dcount(ResourceId), x_ConsumedCoreHours = round(sum(x_ConsumedCoreHours), 2), EffectiveCost = round(sum(EffectiveCost), 2) by x_SkuLicenseStatus, x_SkuCoreCount, x_SkuLicenseQuantity, x_SkuLicenseUnit | order by EffectiveCost desc

 

This tells me a few things:

1. I have 53 Linux and 3 Windows VMs.
2. Only 8 of my 32 cores for Windows VMs are covered by AHB.
3. The 2 VMs which each have 4 cores, are consuming 16 AHB cores.
4. My 2 Windows VMs (4 cores each) are underutilizing their licenses (8 cores each). They could be scaled up or the licenses could potentially be reassigned.
5. I have 1 VM using 24 cores that isn’t covered by AHB. I can confirm my available licenses to determine if I have more that can be used. If I have 8 more licenses, I can enable AHB on the larger VM and disable it on the smaller ones for better utilization and more savings.

Of course, there’s a lot more we could dig into with AHB and analyzing other SKU properties, but this should help get you started. We’ll continue to build on these columns in future blog posts to demonstrate more interesting scenarios as we go. Leave a comment if you’d like to see any specific queries and I’ll make sure to cover it.

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, and the underlying SKUs we were charged for. Next, we’ll cover the columns related to purchases.

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

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 (Services)   ·   Next post (Purchases) ⮞