FinOps Blog articles

Announcing savings plan for databases: flexible savings for modern, evolving workloads

kyleikeda — Wed, 22 Apr 2026 20:09:03 GMT

As organizations modernize their data platforms, database environments are constantly changing. Teams migrate between services, scale across regions, and evolve architectures to support new applications and AI driven workloads. But optimizing costs in these environments can be challenging, especially when savings options require locking into specific services, regions, or configurations.

To help with these challenges, we’re introducing savings plan for databases, a new way to save on eligible database services while maintaining the flexibility needed to modernize and grow your business.

Savings plan for databases helps IT, engineering, and FinOps teams reduce database costs with a simple, spend based commitment—without slowing down architectural change.

What is savings plan for databases?

Savings plan for databases is a spend based pricing model that enables customers to save on eligible database services by committing to a fixed hourly spend for one year. In return, customers receive lower prices—up to 35% compared to pay-as-you go pricing on select services*.

Instead of committing to a specific database service, region, or configuration, customers commit to an hourly dollar amount (for example, $5 per hour). The plan automatically applies savings to eligible database usage each hour, prioritizing the usage that delivers the greatest savings first—across services and regions—until the hourly commitment is met.

Any usage beyond the commitment continues at pay-as-you go rates, ensuring flexibility as needs change.

Benefits designed for modern database workloads

Flexibility as environments evolve

Savings plan for databases is designed for change. Savings continue to apply as workloads modernize or move across regions—without requiring customers to repurchase or reconfigure commitments. This makes it well suited for dynamic environments where architectures are expected to evolve over time.

Automatic cost optimization

With a single hourly commitment, customers unlock discounted prices on eligible database usage. Savings are applied automatically each hour, ensuring customers get the most value from their commitment without manual management or constant tuning.

Predictable budgeting and forecasting

A fixed hourly spend replaces variable pay-as-you-go costs with a predictable commitment, making it easier for FinOps and IT finance teams to forecast spend, plan budgets, and manage cloud investments with confidence.

What services that are covered with the savings plan for databases:

Savings plan for databases pricing

Savings based on pay as you go list price. Savings calculated by comparing committed plan price to pay-as-you-go list price for the same usage. Savings calculations are based on list prices and do not vary by region. Pricing as of March 2026. Actual savings may vary based on usage. Pricing Calculator and Pricing Pages will be updated in future date to reflect savings plan for databases pricing and savings.

How to purchase a savings plan for databases

Getting started is simple:

Review personalized recommendations in the Azure portal based on recent database usage.
Choose an hourly commitment and scope it into a subscription, resource group, management group, or entire account.
Select a payment option—pay monthly or upfront at no additional cost—and optionally enable auto‑renewal.

Once purchased, savings are applied automatically to eligible database usage every hour. Learn more here on how to purchase a savings plans here.

Example: saving while modernizing

Consider a team running a global application that uses Azure SQL Database and Azure Database for PostgreSQL today, with plans to expand into additional regions over the next year.

Instead of purchasing individual reservations tied to specific services or regions, the team purchases a 1‑year savings plan for databases with a $5/hour commitment. As usage shifts across database services and regions, Azure automatically applies discounted prices to eligible usage up to the hourly commitment. The team continues modernizing without disruption—while benefiting from predictable savings.

Summary

Savings plan for databases provides a new way to optimize database costs —without locking into fixed architectures. With hourly commitments, automatic optimization, and predictable costs, it’s designed to support modernization today and continued growth tomorrow.

Get started

You can begin saving today:

View your recommendation in Azure Advisor
Purchase a plan in Azure portal
Visit the Savings plan homepage
Review the Microsoft Documentation
Watch demo videos at the Azure Essentials Show

*Customers may see savings estimated to be between 0% and 35%. The 35% savings estimate is based on one Azure SQL Database serverless running for 12 months at a pay-as-you-go rate vs. a reduced rate for a 1-year savings plan. Based on Azure pricing as of March 2026. Prices are subject to change. Actual savings may vary based on location, database service, and/or usage. 

** Note that savings plan for databases will also be consumed by SQL Server on Azure Virtual Machines and SQL Server enabled by Azure Arc hourly license at the normal pay-go price.

What’s new in FinOps toolkit 13 – January 2026

Michael_Flanakin — Mon, 09 Feb 2026 09:21:43 GMT

Whether you consider yourself a FinOps practitioner, someone who’s enthusiastic about driving cloud efficiency and maximizing the value you get from the cloud or were just asked to look at ways to reduce cost, the FinOps toolkit has something for you. This release focuses on stability and usability improvements across FinOps hubs, Power BI reports, and Azure Optimization Engine with a few key additions, like configuring Key Vault purge protection when deploying FinOps hubs and support for format and compression when creating Cost Management exports via PowerShell. Read on for details.

New to the FinOps toolkit?

In case you haven’t heard, the FinOps toolkit is an open-source collection of tools and resources that help you learn, adopt, and implement FinOps in the Microsoft Cloud. The foundation of the toolkit is the Implementing FinOps guide that helps you get started with FinOps whether you’re using native tools in the Azure portal, looking for ways to automate and extend those tools, or if you’re looking to build your own FinOps tools and reports. To learn more about the toolkit, how to provide feedback, or how to contribute, see FinOps toolkit documentation.

Faster troubleshooting with expanded documentation

When something goes wrong, the fastest path to resolution is clear, comprehensive documentation. But finding the right guidance hasn't always been straightforward.

This release addresses that gap across several fronts. The new Data Lake Storage connectivity guide walks through connecting to FinOps hubs data from tools and services beyond Power BI. Updated Configure scopes documentation clarifies support for multiple Azure scopes and cross-cloud data ingestion. New guidance explains how to remove private networking to reduce costs when it's no longer needed.

On the troubleshooting front, expanded guidance covers common Data Explorer ingestion errors, including SEM0080, ErrorCodeNotString, and ingestion drop failures. Power BI report documentation now includes export requirements that clarify which Cost Management exports each report needs. Updated FOCUS converter documentation covers the newly added 1.2-preview fields: ServiceSubcategory, InvoiceId, PricingCurrency, and SkuMeter.

Have a tip that helped you get unblocked? Share it with the community to help others facing the same challenge and let us know if there’s anything we can do to help!

Join us for FinOps toolkit office hours

Community engagement has always been at the heart of the FinOps toolkit. Over the years, some of the best features and fixes have come directly from practitioners sharing what's working, what's not, and what they need next. That feedback loop is invaluable, and the community has been asking for a more direct way to connect with the team.

FinOps toolkit office hours make that possible. Join us every other Wednesday, from 8:30 to 9:00 AM Pacific (4:30 to 5:00 PM UTC), drop in to get help with deployment issues, discuss feature requests, share feedback, or connect with others on the same journey. No agenda, no preparation required. All experience levels welcome.

Join the next session or add it to your calendar.

Scaling FinOps hubs to meet enterprise demands

As FinOps hubs adoption grows, so do the demands placed on it. Organizations need deployments that satisfy compliance policies, recover gracefully from failures, and adapt to evolving requirements. This month, you’ll find improvements touching all three.

Compliance requirements vary widely across organizations. Some Azure Landing Zone policies require Key Vault purge protection but enabling it by default creates friction during development and testing when frequent redeployments are the norm. A new optional enablePurgeProtection parameter lets you enable purge protection when policies require it while keeping it off by default for flexibility elsewhere. This release also tightens the default security posture by replacing the User Access Administrator role with the more restrictive RBAC Administrator role, now scoped specifically to the Managed Exports app. (I’ll touch on apps in a second…)

Reliability was a big focus in this release. You’ll see improvements that address pipeline issues that could cause deployment failures or data inconsistencies, including ADF triggers not starting after deployment, InitializeHub pipeline failures, and duplicate records in certain scenarios. We’re always looking out for reliability and data quality issues, so please let us know if you run into any problems.

Extensibility has always been at the heart of FinOps hubs – it’s one of our defining design principles. But there’s a lot to extensibility and the underlying architecture needed to catch up. This release reorganizes the Bicep templates into separate application modules, laying the groundwork for more flexible deployment options in future releases. The vision: deploy only the components you need, extend with your own, and integrate more seamlessly with existing infrastructure. You’ll hear more as we evolve this extensibility model. I’m incredibly excited about the potential here.

Have an extension you’d like to see? Start a discussion and explore it with the community. We’d love to hear from you!

Streamline export automation with Parquet

Cost Management exports can grow large, especially for organizations with complex environments or long retention periods. CSV files get the job done, but they are verbose and slow to query at scale. We always recommend using parquet exports with snappy compression for the fastest downloads and ingestion times. Now you can use PowerShell to export your data using parquet.

For those who aren’t aware, the FinOps toolkit includes a PowerShell module with several useful commands, like creating and executing Cost Management exports. The New-FinOpsCostExport command is key here and now supports Parquet format through a new -Format parameter. Parquet files are columnar, compact, and significantly faster to query in tools like Azure Data Explorer, Synapse, and Fabric. You’ll also see a new -CompressionMode parameter which gives you control over gzip and snappy compression to further reduce storage costs and transfer times. Again, for the fastest data processing and lowest latency, we recommend using Parquet format with snappy compression.

Thanks to gorkomikus on GitHub for contributing this feature! They saw a gap and fixed it. That’s what community is all about!

Other new and noteworthy updates

Many small improvements and bug fixes go into each release, so covering everything in detail can be a lot to take in. But I do want to call out a few other small things that you may be interested in.

In Power BI reports:

Fixed tag expansion when tag names contain special characters like colons.
Fixed unattached disks count in the workload optimization report to show only truly unattached disks.
Fixed "Number of Months" parameter calculation that was excluding the first 5 days of data.
Fixed EA department scope failing on pricesheet export by skipping unsupported scopes.

In FinOps workbooks:

Fixed SQL Managed Instance vCores displaying incorrect values in the AHB workbook.

In Azure optimization engine:

Changed default SQL database backup redundancy to LRS for improved cost efficiency and compatibility with non-paired Azure regions.
Fixed reservations-related workbooks by replacing Instance Size Flexibility ratios CSV vanity URL.
Fixed underutilized disks recommendations not being generated for Premium SSD V2 disks.

What’s next

We’ve been a bit quiet lately, but we’re still here and excited about what the future has in store. It’s been interesting to see how the silence has caused an increase in people looking to contribute to the FinOps toolkit. This is very exciting to watch this vibrant community continue to grow!

Looking ahead, you can expect continued innovation across the toolkit:

AI automation on top of Cost Management and FinOps hubs giving you more options to getting the answers you need.
FinOps hubs will add recommendations, a new extensibility model, and continued data quality improvements.
Azure Optimization Engine will evolve as its capabilities are integrated into FinOps hubs.

To support this momentum, I’m also working on a set of premium, paid services designed to help organizations deploy, customize, and scale the FinOps toolkit with confidence. Whether you need help getting started, tailoring the tools to your environment, or ensuring long-term success, these services are built to meet you where you are – strategic, secure, and ready to deliver value from day one. Connect with me directly on LinkedIn or FinOps Foundation Slack to learn more.

Microsoft Agent Pre-Purchase Plan: One Unified Path to Scale AI Agents

kyleikeda — Fri, 20 Feb 2026 18:06:20 GMT

AI is now essential, and at Microsoft Ignite 2025, we introduced a new foundation for intelligent agents: Work IQ, Fabric IQ, and Foundry IQ. These three IQs represent the intelligence layer that gives agents deep context; understanding how people work, connecting to enterprise data, and orchestrating knowledge across platforms. Together with the launch of Microsoft Agent Factory, organizations now have a unified program to build, deploy, and manage agents powered by these IQs.

Microsoft Agent Pre-Purchase Plan (P3) is designed to for organizations looking to confidently invest in AI agent development with a single, predictable budget. It empowers businesses to experiment, build, and scale sophisticated AI agents without the friction of fragmented licensing or unexpected costs. By unifying access to agentic services across Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub, Microsoft Agent P3 empowers organizations to harness the full potential of the IQ layer thus removing barriers and unlocking the value of truly intelligent, context-driven agents.

What is Microsoft Agent Pre-Purchase Plan and how to does it work?

Microsoft Agent P3 is a one-year pay-upfront option.
Customers commit upfront to a lump-sum pool of Agent Commit Units (ACU) that can be used at any time during the one-year term.
Every time you consume eligible services across Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub, the ACUs are automatically drawn down from your P3 balance.
If you use up your balance before the year ends, you can add another P3 plan or switch to pay-as-you-go.
If you don’t use all your credits by the end of the year, the remaining balance expires.

Pricing*

*Pricing as of November 2025, subject to change.

**Example if Microsoft Copilot Studio generates a retail cost of $100 based on Copilot Credit and Microsoft Foundry usage, then 100 Agent CUs (ACUs) are consumed.

What is covered by the Microsoft Agent Pre-Purchase Plan?

* List as of February 2026, subject to change

** Currently in Private Preview

*** Covers Copilot Credits enabled agentic services: Microsoft Copilot Studio, Dynamics 365 first-party agents, and Copilot. Microsoft reserves the right to update Copilot Credit eligible products.

Customer Example

Suppose a customer expects to consume 1,500,000 Copilot Credit with custom agents created in Microsoft Copilot Studio. Assuming the pay-as-you-go rate for Copilot Credit to be $0.01, then at the pay-as-you-go rate, this will cost $15,000.

In addition, if they are using 5000 Microsoft Foundry Provisioned Throughput Units (PTU) and assuming the pay-as-you-go rate for PTU to be $1, then at the pay-as-you-go rate, this will cost $5,000.

By purchasing Tier 1 (20,000 ACUs) Microsoft Agent P3 at the cost of $19,000, it will give a 5% saving compared to the pay-as-you-go rate for the same usage.

How to purchase a Microsoft Agent Pre-Purchase Plan?

Sign in to the Azure portal →Reservations → + Add → Microsoft Agent Pre-Purchase Plan.
Select your subscription and scope
Choose your tier and complete payment.

What sets Microsoft Agent Pre-Purchase Plan apart?

At the heart of Microsoft Agent Pre-Purchase Plan are four pillars that redefine how organizations consume AI services:

One Plan: A single offer that spans Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub. No more siloed credits or SKU-level complexity, just one pool for all your AI workloads.
Breadth of Services: Access to 30+ services, from Azure AI Search and Cognitive Services to orchestration tools and Copilot-enabled experiences.
One Governance Path: Simplifies procurement and budget management. Procurement teams gain visibility and control without sacrificing agility.
Predictable Savings: Get discounts and avoid surprises when you choose this plan.

Conclusion

The Microsoft Agent Pre-Purchase Plan is designed to make your AI journey simpler, smarter, and more cost-effective. By combining the strengths of Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub into a single, unified offer, the plan eliminates the need to choose one platform or manage multiple contracts. Organizations benefit from predictable budgeting, streamlined procurement, and the flexibility to innovate across more than 30+ agentic services—all with one pool of funds.

Whether you’re just starting with AI or scaling enterprise-wide adoption, the Microsoft Agent Pre-Purchase Plan empowers you to unlock the full value of Microsoft’s agentic platform—driving innovation, efficiency, and business impact. And with support for agents built on Work IQ, Fabric IQ, and Foundry IQ, customers can be confident their solutions are grounded in the latest intelligence announced at Ignite.

What’s next

Read the Microsoft Agent P3 Offer MS Learn Doc

Purchase Microsoft Agent P3 in your Azure Portal

* Covers Copilot Credits enabled agentic services: Microsoft Copilot Studio, Dynamics 365 first-party agents, and Copilot. Microsoft reserves the right to update Copilot Credit eligible products

Streamline Analytics Spend on Microsoft Fabric with Azure Reservations

kyleikeda — Mon, 24 Nov 2025 19:13:50 GMT

Introduction

As organizations accelerate their cloud adoption, optimizing spend while maintaining performance and scalability is a top priority. Microsoft Fabric, our all-in-one, software-as-a-service data platform, is designed to help teams accomplish any data project. But how can you ensure your investment delivers maximum value? In this post, we’ll explore how Azure reservations for Microsoft Fabric can help you optimize costs, simplify purchasing, and streamline your data analytics spend.

What Is Microsoft Fabric?

Microsoft Fabric is an end-to-end data platform that brings together data orchestration, transformation, machine learning, real-time event processing, reporting, and databases in a single SaaS experience. It’s designed for data engineers, scientists, analysts, and business users, offering role-specific workloads and integrated AI experiences, all backed by a unified data lake—OneLake.

Unlike traditional services that require managing different pricing and capacities for each workload, Fabric simplifies this with a single capacity model. You purchase Fabric Capacity Units (CUs), which power all workloads, and jobs consume CUs at different rates depending on your compute needs.

How Azure reservations Work with Fabric

Azure reservation is a pricing model that helps you save when you commit to a specific resource, region, and term - ideal for stable, predictable workloads. Reservations don’t affect capacity or runtime; they simply provide discount benefits. Azure analyzes your usage and recommends reservation options, and tools like Azure Advisor guide you toward the right purchase.

You may be familiar with how reservations work with virtual machines, but Azure reservations can also apply to other services such as Microsoft Fabric. When purchasing Fabric, you can choose a pay-as-you-go model for flexible usage or save substantially with Azure reservations for consistent workloads. For example, if you deploy an F64 SKU in Fabric for ongoing reporting and analytics, buying an Azure reservation for this SKU ensures you pay the discounted rate for your consistent usage.

How to Purchase a Reservation for Microsoft Fabric

Let’s look at how you can purchase a reservation for Microsoft Fabric. Follow these steps below or watch this video:

1. Start in the Microsoft Marketplace or Azure Portal:

Visit the Microsoft Marketplace and look up Microsoft Fabric. Click “Get it now” and it will take you to the Azure Portal.

2. Create Fabric Capacity:

Select Configuration: In Azure Portal, on the Create Fabric Capacity page, select your subscription and resource group, name your capacity, and select your region.
Select Size: Use the Fabric SKU estimator to determine the right capacity for your workloads, or start with a free trial and monitor usage with the capacity metrics app. You can always upgrade or create multiple capacities as needed.
Organize with Tags: Use Azure tags to track costs and automate management across environments.

3. Buy Fabric Reservations:

In the Azure portal, search for and select “Reservations.”
On the Reservations page, click “Add” and select Microsoft Fabric. Choose your scope and subscription, select Fabric Capacity with upfront or monthly payments, and adjust the quantity as needed.

Best Practices for Maximizing Savings

To get the most value from your reservations, follow these best practices:

Estimate Carefully: Avoid over-committing (which leads to wasted resources) or under-committing (which leads to higher costs). Understand your resource needs and usage and use Azure Advisor recommendations to make informed decisions.
Enable Auto-Renew: Ensure your reservations automatically renew so you don’t lose the discount but adjust your reservation needs as workloads change.
Monitor Usage: Use Azure Cost Management to continuously track reservation usage.
Choose the Right Scope: Align reservation benefits with your organizational structure to maximize savings.

Conclusion:

Microsoft Fabric and Azure reservations empower organizations to streamline analytics spend, simplify purchasing, and unlock significant savings without sacrificing performance or scalability. Following best practices and leveraging the right tools ensures your cloud investments deliver maximum value.

Get started today by visiting the Microsoft Marketplace and Azure Portal to purchase Fabric Capacity units and reservations or read Save costs with Microsoft Fabric Capacity reservations - Microsoft Cost Management | Microsoft Learn to learn more.

Smarter Cloud, Smarter Spend: How Azure Powers Cost-Efficient Innovation

kyleikeda — Thu, 30 Oct 2025 17:05:07 GMT

In today’s dynamic business environment, organizations are under pressure to innovate rapidly while managing costs effectively. The cloud, especially with AI at the forefront, is driving transformation across industries. But with rising cloud spend and economic uncertainty, cost efficiency has become a top priority.

To help customers navigate this challenge, Microsoft commissioned Forrester Consulting to conduct a Total Economic Impact™ (TEI) study. The study reveals how organizations can unlock significant financial and operational benefits by leveraging Microsoft Azure’s tools and strategic pricing offers, especially when migrating to the cloud and adopting AI.

Cloud Migration: Accelerating Modernization with Azure

Migrating to the cloud is a foundational step for digital transformation. But many organizations initially struggled with cost overruns, lack of visibility, and inefficient resource usage. The TEI study shows how Azure’s native tools and strategic pricing offers helped overcome these challenges.

Key Enablers of Cost-Efficient Migration:

Azure Hybrid Benefit: Allows organizations to optimize savings in their migration journey by giving a discount on server licenses and subscriptions and granting hosting and outsourcing benefits
Azure reservations: A commitment model that enables customers to save on their spend when they commit to a specific resource, in a region, and for a specific term.
Azure savings plan for compute: A flexible pricing model that enables customers to save on their cost when they commit to a spend a fixed hourly amount for a specific term.
Microsoft Cost Management & Azure Advisor: Provide real-time insights and optimization recommendations.
Azure Pricing Calculator: Accurately estimate migration costs and forecast budgets.

“Azure reservations and Azure Hybrid Benefit facilitate moving to the cloud. With these offers and better cost management, we are saving 30% to 35%. Managing our costs without these tools would be an unpredictable nightmare.”
— Senior IT Director, Manufacturing

Quantified Impact*:

25% reduction in cloud spending in Year 1 using Microsoft tools.
$4.9M in direct savings over three years from tool-based optimization.
$3.8M in additional savings from strategic pricing offers.

AI Adoption: Driving Innovation with Cost-Efficient Azure Solutions

Once migrated, organizations are increasingly turning to AI to drive innovation and competitive advantage. Azure doesn’t just support AI workloads, it makes them more cost-effective and scalable.

Key Enablers of AI Adoption:

Azure AI Foundry Provisioned Throughput reservations: Get cost savings compared to provisioned throughput (PTU) hourly pricing.
Microsoft Cost Management & Azure Advisor: Help forecast and optimize AI-related cloud spend.
Strategic Pricing Offers: Enable predictable budgeting and reinvestment into AI initiatives.

“Leveraging Microsoft tools and strategic pricing offers is not only increasing profitability but also putting those savings into more interesting projects like AI with fraud prevention work and the customer experience.”
— VP of Analytics Engineering, Financial Services

“Azure reservations for AI projects using PTUs has helped our AI initiatives. It has helped better predict costs.”
— CIO, Healthcare

Unquantified Benefits:

Increased cloud insights and visibility.
Improved governance and accountability.
Enhanced productivity (24% by Year 3).

The Bottom Line: Unified Transformation with Azure

The TEI study concludes that Azure delivers a unified approach to cloud computing, enabling organizations to:

Migrate to the cloud efficiently with cost control
Adopt AI rapidly by reinvesting savings into innovation
Achieve a net present value (NPV) of $8.7 million over three years
Realize a 35% reduction in cloud spending in Year 1

“With Microsoft tools, we can focus on higher value projects. Instead of reviewing reports and conducting cost audits, we can build new tools and build with genAI. We can innovate faster.”
— Vice President of Analytics Engineering, Financial Services

Ready to Dive Deeper?

This blog is just the beginning. The full Forrester TEI study is packed with insights, customer stories, and financial modeling to help you build your business case for Azure.

Read the full study here

*To understand benefits, costs, and risks, Forrester interviewed eight decision-makers with experience using the evaluated Azure solutions. For the purposes of this study, Forrester aggregated the results from these decision-makers into a single composite organization.

Unlock Savings with Copilot Credit Pre-Purchase Plan

kyleikeda — Mon, 27 Oct 2025 21:53:23 GMT

Introduction

As organizations scale their use of Microsoft Copilot Studio from building custom agents to integrating with Dynamics 365, cost predictability and optimization becomes critical. To help you plan confidently and save more, we’re introducing Copilot Credit Pre-Purchase Plan (P3)*, a simple, one‑year plan that delivers volume discounts and automatic billing, so your team can focus on outcomes, not invoices.

What is Copilot Credit Pre-Purchase Plan?

The P3 is a one‑year, pay‑up‑front option for Copilot Credits. You purchase Copilot Credit Commit Units (CCCU) and your usage automatically draws from this pool. Higher tiers unlock progressive discounts enabling more growth. See pricing here.

How it works

You pre-purchase a pool of Copilot Credits Commit Unit (CCCUs) for one year.
Every time you use Copilot Credits for Microsoft Copilot Studio, Dynamics 365 first-party agents, or Copilot Chat*, the CCCUs are automatically drawn down from your P3 balance.
If you use up your balance before the year ends, you can add another P3 plan or switch to pay-as-you-go.
If you don’t use all your credits by the end of the year, the remaining balance expires.

Example:

A retail company runs 15 custom Copilot Studio agents to handle inventory checks, store operations, and customer service. They expect seasonal spike (holiday campaigns, back-to-school, and clearance events) but want predictable costs.

Without P3:
On the pay-as-you-go model their total cost can vary and spike as their usage goes up and down. During peak months, usage surges, and so does the bill make budgeting tough.

With P3:
Based on forecasting they expect to use 1,500,000 Copilot Credits over 12 months. Because they know how many Copilot Credits they plan on consuming, the retail company buys P3:

Purchase P3 Tier 2: 15,000 CCCUs (this covers 1,500,000 Copilot Credits)
P3 Upfront cost: $14,100
P3 discount: 6% vs PAYG

Now, every time their agents run, CCCUs are automatically deducted from the P3 balance.

P3 Tiers:

Pricing as of October 2025, subject to change. See pricing here.

Key Benefits

Cost savings: Up to 20% discount at highest tier**.
Budget predictability: One‑year term with upfront payment and no surprise bills.
Flexibility: Add more P3 anytime; works alongside capacity packs and PAYG.
No redeployment: Applies automatically to eligible usage.
Defined Scope: Decide where the P3 applies based on your business needs. It can be applied at the resource group, subscription, management group, or shared level.

How to Purchase Copilot Studio Pre-purchase plan

Sign in to the Azure portal → Reservations → + Add → Copilot Credit Pre‑purchase Plan.
Select your subscription and scope
Choose your tier and complete payment.
Link your subscription to Copilot Studio in Power Platform Admin Center.

Best Practices

Estimate accurately: Use historical usage or Copilot consumption estimator.
Deploy first: Ensure environments are PAYG‑enabled before buying.
Monitor utilization: Set alerts to avoid unexpected PAYG charges.
Plan for renewal: Auto‑renew is on by default; adjust as needed.

Conclusion

If you’re scaling fast or managing multiple environments, P3 gives you predictable costs and meaningful savings without sacrificing flexibility. It’s ideal for customers with variable or growing usage who want to optimize spend and simplify billing.

Copilot Credit Pre-Purchase Plan makes it easier to innovate without worrying about unpredictable costs. By committing upfront, you unlock discounts, streamline billing, and gain confidence in your budget.

Ready to start?
Visit the Azure portal to purchase your plan today or read the Copilot Credits Pre-purchase Plans documents to learn more.

Resources:

*Copilot Credit covers Microsoft Copilot Studio, Dynamics 365 first-party agents, and Copilot Chat. Microsoft reserves the right to update Copilot Credit eligible products.

** The actual realized cost per Copilot Credit for P3 and the MCS license will depend on the utilization rate. As such customers should take into account their

expected usage pattern as P3 Commit Units expire annually while the Copilot Credit capacity packs expire monthly.

Provider-Managed Azure Subscriptions: Cost Control and Commitment Clarity

Dirk_Brinkmann — Fri, 29 Aug 2025 04:48:21 GMT

As a Microsoft Cloud Solution Architect supporting enterprise customers, I occasionally encounter a specific scenario where customers with an Enterprise Agreement (EA) or Microsoft Customer Agreement (MCA-E) allow a service provider (SP) to manage one or more of their Azure subscriptions via the SP’s tenant. This setup has notable implications for cost and commitment management, which I’ll explore in this article.

Recommended prerequisite reading: Microsoft Cost Management: Billing & Trust Relationships Explained

Scenario Overview

A customer signs a contract with a service provider to outsource the management of certain resources. The customer retains full control over resource pricing and expects the usage of these resources to contribute towards their Microsoft Azure Consumption Commitment (MACC).

To achieve this, the customer associates one or more Azure subscriptions with a Microsoft Entra ID tenant owned and managed by the SP. In our example, this is “Subscription B.” The SP gains full RBAC access to the subscription and its resources, while the billing relationship remains tied to the customer’s billing account (EA) or billing profile (MCA-E).

Let’s have a look at the implications from both the customers and the service providers perspective:

Customers perspective

Cost & Pricing

All cost in Subscription B that occurs because of resource usage are tied and therefore billed to the customers billing account (EA) or billing profile (MCA-E).
The prices used for the usage are based on the negotiated customer price list associated with the billing account (EA) /profile (MCA-E).
The Azure resource consumption of Subscription B plus any eligible Marketplace offer consumption within the subscription contributes to the MACC of the customer.
Customer has full cost visibility of Subscription B via Azure Cost Analysis on the billing account/billing profile level.

Commitments (Reservations / Savings Plans)

Shared commitments at the billing account/billing profile level are utilized by matching resources in Subscription B.
Commitments scoped to Subscription B or lower can only be purchased by the customer, if the customer has RBAC rights on the subscription and the global billing policy allows purchases for subscription owner / reservation purchasers.

Service Provider Perspective

Cost & Pricing

The service provider is responsible for managing Subscription B’s resources and the associated costs.
Subscription B’s actual and amortized cost view is limited for the service provider as they have only access at the subscription level.
The service provider has no direct access to the customer price (Price Sheet) or invoice information.

Commitments (Reservations / Savings Plans)

The service provider can purchase commitments scoped at Subscription B or lower (resource group) if the global customer’s billing policy allows purchases for subscription owners / reservation purchasers. The associated costs of the commitment are attributed to the customer’s billing account/profile.
Shared or management group scoped commitments purchased by the service provider based on their own billing account / billing profile do not apply to Subscription B.

Key take aways

Decoupled Ownership: Customers can separate subscription management from billing ownership, enabling flexible operational models.
Cost Control: Customers retain full visibility and control over pricing, cost allocation, and commitment utilisation—even when subscriptions are managed by a service provider.
Governance and Policy Alignment: Successful implementation depends on clear billing policies and RBAC configurations that align with both customer and provider responsibilities.

What’s new in FinOps toolkit 12 – July 2025

Michael_Flanakin — Thu, 07 Aug 2025 17:00:00 GMT

Whether you consider yourself a FinOps practitioner, someone who’s enthusiastic about driving cloud efficiency and maximizing the value you get from the cloud or were just asked to look at ways to reduce cost, the FinOps toolkit has something for you. This month, you’ll find support for FOCUS 1.2, autostart in FinOps hubs which can reduce your hub costs, a new page in the Cost summary Power BI report, and various small fixes, improvements, and documentation updates across the board. Read on for details.

New to the FinOps toolkit?

FinOps Open Cost and Usage Specification (FOCUS) version 1.2

As you may have seen, Microsoft Cost Management released support for FOCUS 1.2 last month. This month, you’ll find updated FOCUS documentation, Power BI reports, FinOps hubs data ingestion, and a new FOCUS 1.2 metadata file.

The FOCUS documentation provides a high-level overview and summary of what FOCUS is, why it’s important, how to transition to it, and any conformance gaps between the Cost Management dataset and the official specification. These updates cover:

New columns, like ServiceSubcategory.
Renamed columns, like InvoiceId, PricingCurrency, and SkuMeter.
Future columns that are not yet populated, like CapacityReservationId, CapacityReservationStatus, CommitmentDiscountQuantity, CommitmentDiscountUnit, and SkuPriceDetails.

If you’re migrating reports from native Cost Management schemas to FOCUS, converting your own data, or comparing FOCUS data to native schemas, you can learn more with the following articles:

Power BI reports were also updated to account for the new and renamed columns. Storage reports include both new and old names with values copied to/from both, so no matter what you use, you’ll continue to get the right values whether you’re using FOCUS 1.0 or FOCUS 1.2 data. This includes:

InvoiceId and x_InvoiceId
PricingCurrency and x_PricingCurrency
SkuMeter and x_SkuMeterName

KQL reports go a step further and provide some of the additional columns that are not yet provided in Cost Management FOCUS exports. This includes CapacityReservationId, CapacityReservationStatus, CommitmentDiscountQuantity, CommitmentDiscountUnit, SkuPriceDetails, and more. I’ll cover this more in the next section.

Lastly, FOCUS defines a metadata file that identifies and describes the columns included in a FOCUS dataset. You can download a JSON version of these metadata files or learn more in Details about the FOCUS dataset.

Note the documentation updates have not been published yet, so you won’t see them on Microsoft Learn. While Microsoft works on publishing the updates, refer to the FOCUS documentation in the FinOps toolkit repository.

New FinOps hubs v1_2 schema

Data is at the heart of every FinOps practice. Whether you’re a hobbyist or part of a large team, you can’t “FinOps” without data. And when you start to “FinOps” at scale, you realize you need a lot of different data from a lot of different data sources. And these data sources often have different characteristics and change over time. Luckily, FinOps hubs were designed to handle ever-evolving datasets through it’s “schema version” concept.

FinOps hubs schema versions are contracts you can rely on to always present a consistent version of the data. Today, FinOps hubs use a “v1_0” schema version that aligns with FOCUS 1.0 (hence the name). As of FinOps hubs 12, you will see a new “v1_2” schema version, which aligns with FOCUS 1.2. And you’ll notice that your data is populated in the FOCUS 1.2 format regardless of what dataset version you exported from Cost Management. And the best part is, this optimization won’t impact you at all as long as your reports and integrations are setup to use the versioned functions (e.g., Costs_v1_0). If you find you have code using non-versioned functions (e.g., Costs), simply switch to the versioned function to get all data – old and new – using the previous v1_0 schema version.

To learn more, see Introducing non-breaking “breaking” changes in FinOps hubs 12.

Unlocking broader compatibility with flexible CIDR support

When setting up private endpoints in FinOps hubs, defining the right virtual network (VNet) configuration is essential to ensure secure and scalable connectivity. A key part of this setup involves specifying a CIDR (Classless Inter-Domain Routing) block, which determines the size and structure of the IP address space within the VNet. Based on community feedback, FinOps hubs expanded CIDR validation to support any subnet size ranging from /8 to /26 for maximum flexibility. (/26 is the minimum required to support native FinOps hubs functionality.)

This update reflects a more flexible and inclusive approach to network planning. By allowing a wider range of CIDR sizes, FinOps hubs better accommodate diverse deployment scenarios, such as those involving Power BI VNet data gateways that require larger address spaces. This change not only resolves upgrade blockers but also empowers you to tailor your deployments to meet your unique needs and without unnecessary constraints.

Balance cost and freshness with Data Explorer auto-start

One of the most effective ways to reduce cloud spend is by scheduling workloads to run only when needed, and Azure Data Explorer clusters are a prime candidate for this strategy. Data Explorer powers ingestion and analysis, but usage is billed hourly, which means you’re being charged for it even when not actively querying or ingesting data. To optimize this, you can configure Data Explorer to shut down automatically after a period of inactivity, but historically, this has introduced a problem because the cluster was shut down when new data needs to be ingested. With FinOps hubs 12, the ingestion pipeline automatically checks the status of the Data Explorer cluster and starts it if it’s stopped when new data arrives. When initiating the Data Explorer cluster, the startup process typically takes approximately 10 minutes. While this delay incurs pipeline execution costs, it remains significantly more cost-effective than maintaining a continuously running cluster (24x7). During this startup phase, data ingestion tasks are paused until the cluster is successfully provisioned. Depending on the timing of the ingestion trigger, there may be instances where the cluster's provisioning state is not yet terminal. This can occur, for example, when the Data Explorer is concurrently executing a stop or start operation while the pipeline attempts to initiate the cluster. In such cases, the pipeline waits for 10 minutes before reattempting the cluster start activity. As expected, detailed outputs—including cluster status, the result of the start operation, and any encountered errors—are available in the Azure Data Factory (ADF) monitoring interface for review and troubleshooting.
To summarize, this ensures ingestion continues seamlessly without manual intervention, allowing users to optimize for both cost and continuity. It’s a smart enhancement that supports workload scheduling best practices—keeping your data fresh while ensuring you only pay for what you use.

To get started with scheduling Data Explorer, see Automatic stop of inactive Azure Data Explorer clusters.

Strengthened security with flexible export permissions

FinOps hubs leverage Cost Management exports, which run on a predetermined schedule that can’t be set or changed. But some organizations are looking for more control over when exports run and data gets ingested into FinOps hubs. This is where managed exports come in. Managed exports automate the delivery of Cost Management data, enabling seamless and timely integration with analytics pipelines and reporting tools. Managed exports work by granting your FinOps hub instance access to create and run exports on your behalf. The challenge here is that Cost Management requires the User Access Administrator role to create exports, which is an elevated permission that some organizations restrict due to security policies. To increase the default security posture of FinOps hubs, managed exports are now disabled by default in FinOps hubs 12. If you’d like to use managed exports, simply check the Enable managed exports checkbox on the Advanced tab (or the set the enableManagedExports template parameter to true).

By leaving this option disabled or explicitly setting the parameter to false, you can now deploy FinOps hubs without requiring elevated permissions for role assignments. This makes it easier to deploy in secure or restricted environments while still maintaining core functionality. It’s a small but powerful change that simplifies onboarding and aligns with enterprise-grade security practices.

New executive summary in the Cost summary report

Understanding where your cloud spend is coming from is critical – not just for FinOps practitioners, but for executive stakeholders as well. That’s why the FinOps toolkit 12 release introduces a new Summary page in the Cost summary report, designed specifically to provide a high-level, executive-friendly view of cost drivers across your environment.

This new page highlights the top 10 subscriptions, resource groups, and service categories by spend for the selected period, making it easy to identify where costs are concentrated. It also includes a breakdown of monthly usage by pricing category and a daily spend trend for the last 30 days to facilitate quick pattern recognition and anomaly detection at a glance. To make room for this new executive summary, the original summary page has been renamed to Running total, which continues to provide a cumulative view of costs over time. Together, these updates offer a more complete and accessible picture of your cloud financials for both technical and non-technical audiences.

PowerShell updates for Cost Management exports

To ensure compatibility with the latest features and improvements in Microsoft Cost Management, the FinOps toolkit PowerShell commands for Cost Management exports were all updated to default to the latest GA API version, 2025-03-01. This keeps the toolkit aligned with the most recent capabilities and ensures long-term support for evolving services.

In addition, the default export version for FOCUS exports has been updated to 1.2-preview in the New-FinOpsCostExport command. This version includes the latest industry and data quality improvements, helping teams get more value from their exported cost data. These updates make it easier to stay aligned with the latest standards while reducing the need for manual configuration. If you need an older dataset version, simply set the -DatasetVersion parameter to the desired version.

New versioning strategy for a growing toolkit

What started as a modest effort to simplify FinOps operations with a single tool has grown into a suite of nine tools, each addressing a different aspect of FinOps. While we’ve been driving towards a “1.0” release of FinOps hubs, the FinOps toolkit scope has grown, but our approach to versioning hasn’t. With this release, we’re shifting to a versioning strategy that better represents the ever-growing nature of the toolkit as a collection of tools. Instead of “0.12” which only represents the state of a single tool, we’re dropping the “0.” to reflect the collective progress as version “12” of the toolkit as a whole.

Other new and noteworthy updates

Many small improvements and bug fixes go into each release, so covering everything in detail can be a lot to take in. But I do want to call out a few other small things that you may be interested in.

In FinOps hubs:

Document how savings are calculated and how to troubleshoot negative savings.
Updated the Data Explorer dashboard to use the v1_2 schema.

In Power BI reports:

Added an invoice ID filter to the Microsoft Customer Agreement (MCA) invoice recon page in the Invoicing and chargeback report.
Updated KQL reports to use the FinOps hubs v1_2 schema.
Correctly detect the hub version in the Data ingestion report.

In Azure optimization engine:

Link to recommendations Power BI report in MS Learn documentation (#1614).
Aka.ms links to point to the latest version of documentation articles in MS Learn.

In open data:

Added 20 new and updated 7 existing resource types.
Added 2 new service mappings.

What’s next

Despite many changes in Microsoft, I’m more excited than ever about what’s coming. The FinOps toolkit has grown into a vibrant community of contributors and users, all passionate about making FinOps more accessible, scalable, and impactful. And we’re just getting started.

Looking ahead, you can expect continued innovation across the toolkit:

FinOps hubs will add recommendations, a new extensibility model, and continued data quality improvements.
Power BI and FinOps workbooks will continue to expand with recurring updates and deeper FinOps insights.
Azure Optimization Engine will evolve as its capabilities are integrated into FinOps hubs.

To support this momentum, I’m also working on a set of premium services designed to help organizations deploy, customize, and scale the FinOps toolkit with confidence. Whether you need help getting started, tailoring the tools to your environment, or ensuring long-term success, these services are built to meet you where you are – strategic, secure, and ready to deliver value from day one. Connect with me directly on LinkedIn or Slack to learn more.

Introducing non-breaking “breaking” changes in FinOps hubs 12

Michael_Flanakin — Tue, 05 Aug 2025 23:27:17 GMT

Before I explain this, I want to say that I’m extremely excited about this update. FinOps hubs was designed to solve a common versioning challenge many organizations face where they need data coming from new columns but can’t update because of breaking changes in other columns. FinOps hubs solves this by introducing these breaking changes in a non-breaking way, giving you the control and flexibility to update when and where you need while leaving your foundational reports and integration points untouched and running just as smoothly as before.

FinOps hubs 12 is the first release to fully realize the value of this non-breaking, “breaking” changes approach since the architecture was established late last year. This approach ensures the FinOps hubs platform will not break reports, will not stagnate with historical baggage, and will also avoid getting bloated with duplicate columns and data, like you might see in certain Cost and Usage Reports out there. But let me take a step back and walk you through it…

How schema versioning works in FinOps hubs

FinOps hubs 0.7 added a custom, FOCUS-aligned schema for all supported datasets. When data is ingested into FinOps hubs with Azure Data Explorer or Microsoft Fabric, the native schemas are transformed into a FOCUS-like dataset to provide forward-looking datasets aligned to the future direction of FinOps across the industry. The data is also augmented to with extra columns and missing data to facilitate common FinOps tasks and goals we hear from organizations big and small. We refer to this as the v1_0 schema because all our tables and functions are named *_v1_0 to be clear about what schema version they use.

Some of you may be using the non-versioned functions, like Costs and Prices. These are wrappers around the corresponding versioned functions, like Costs_v1_0 and Prices_v1_0. The non-versioned functions are for ad-hoc use when you need a quick answer and don’t want to think about what version you need. These always return the latest version. And until FinOps hubs 12, this was always v1_0.

Now, FinOps hubs 12 includes a new v1_2 dataset that aligns to FOCUS 1.2 and includes even more augmented columns to support new scenarios. This gives you three options when querying the system. Let’s use cost as an example:

Costs is that ad-hoc function where you don’t have to think about what version you need. This now uses the v1_2 schema.
Costs_v1_0 is the original FOCUS 1.0 schema that was implemented in FinOps hubs 0.7. This has not changed and will not change.
Costs_v1_2 is the new schema that aligns to FOCUS 1.2 and includes additional columns to support other scenarios like commitment discount utilization, Azure Hybrid Benefit analysis, and more.

If you followed our guidance, then your reports, dashboards, and integration points should all use the versioned functions, like Costs_v1_0. In that case, upgrading to FinOps hubs 12 shouldn’t impact you at all. All your reports and dashboards will continue to function as they have before. If you find you used non-versioned functions, like Costs, simply change to the versioned functions and you should revert back to the same behavior you were seeing before.

Working with older FOCUS exports

Microsoft Cost Management has four different dataset versions for their FOCUS exports:

1.0-preview(v1) is aligned to FOCUS 1.0 preview from November 2023. This was the first public release.
1.0 is fundamentally the same as 1.0-preview(v1) except with changes in the official FOCUS columns to align to the FOCUS 1.0 GA.
1.0r2 is the same as 1.0 except the date columns, like ChargePeriodStart and ChargePeriodEnd, are formatted with seconds. That’s it. Older versions use “2025-01-01T00:00” and 1.0r2 going forward use “2025-01-01T00:00:00”. The only difference is the added “:00” to support some systems which weren’t able to parse dates without seconds.
1.2-preview is aligned to FOCUS 1.2, except there are a few gaps that have not been filled, so it’s flagged as a preview. Once those gaps are filled, you’ll see a new “1.2” release.

FinOps hubs can work with any of these versions. When you export an older version of the data, FinOps hubs simply transforms it to the latest schema version. This means, if you’re working on top of a 1.0-preview(v1) export, that data will now be fully converted to FOCUS 1.2, even if Cost Management didn’t provide the new columns. If you’re still using the v1_0 schema, you won’t even notice the difference. But as soon as you need to leverage one of the newer columns in the v1_2 schema, it’s right there for you, ready when you are. And the best thing is, you don’t need to reprocess any of the data. All your historical data is immediately accessible using either the v1_0 or v1_2 schema.

I’ll leave it at this for now, but please do leave comments if you’re curious about the inner workings of this and how we implemented it. I’m happy to write a more detailed blog post to share the inner workings. In the meantime, refer to FinOps hub data model to learn more.

What’s new in Costs_v1_2

Each of the datasets supported by FinOps hubs were updated. The Costs dataset had the most updates, so we’ll cover those first. The first difference you’ll notice in Costs_v1_2 is support for the latest version of FOCUS:

Added CapacityReservationId
Added CapacityReservationStatus
Added CommitmentDiscountQuantity
Added CommitmentDiscountUnit
Added ServiceSubcategory
Added SkuPriceDetails based on x_SkuDetails, changed to align to FOCUS 1.2 requirements
Renamed x_InvoiceId to InvoiceId
Renamed x_PricingCurrency to PricingCurrency
Renamed x_SkuMeterName to SkuMeter

You’ll also see new columns coming from Microsoft Cost Management:

x_AmortizationClass to help filter out principal charges that can be duplicated when summing ListCost and ContractedCost.
x_CommitmentDiscountNormalizedRatio for the instance size flexibility ratio needed to support CommitmentDiscountQuantity calculations.
x_ServiceModel to indicate what service model the charge is (i.e., IaaS, PaaS, SaaS).
x_SkuPlanName for the Marketplace plan name.

Note that some of the above columns are empty coming from Cost Management. FinOps hubs populates most of the missing columns, like the new capacity reservation and commitment discount columns. We added a new x_SourceValues column to track the column changes happening during FinOps hubs data ingestion. If you’re curious about any of the customizations applied on top of Cost Management data, review the properties in x_SourceValues. Any value that is changed is first backed up in x_SourceValues with its original column name and value to help source data quality issues.

While not a new column, one other change you may notice is that x_SkuTier is now being populated across all Cost Management FOCUS versions. This is an important one because you cannot get this information from actual and amortized cost datasets. You will only see the tier in FOCUS datasets. That’s just one more reason to switch to FOCUS.

Looking beyond the columns coming from Cost Management, you’ll also see extended columns for Alibaba and Tencent Cloud. This completes our native cloud FOCUS dataset support alongside AWS, GCP, and OCI, which are already supported. (Note we don’t ingest the cost automatically. We added support for the data once it’s been dropped into Azure storage.) This includes the following new columns:

Alibaba
- x_BillingItemCode
- x_BillingItemName
- x_CommodityCode
- x_CommodityName
- x_InstanceID
Tencent
- x_ComponentName
- x_ComponentType
- x_ExportTime
- x_OwnerAccountID
- x_SubproductName

FinOps hubs also added new columns to support scenarios covered in Power BI reports and the Data Explorer dashboard. With these columns promoted to the database level, reports will render faster and more consistently. This includes:

Discount percentage columns: x_NegotiatedDiscountPercent, x_CommitmentDiscountPercent, x_TotalDiscountPercent.
Savings columns: x_NegotiatedDiscountSavings, x_CommitmentDiscountSavings, x_TotalSavings.
Commitment discount utilization columns: x_CommitmentDiscountUtilizationAmount, x_CommitmentDiscountUtilizationPotential.
Azure Hybrid Benefit columns: x_SkuLicenseQuantity, x_SkuLicenseStatus, x_SkuLicenseType, x_SkuLicenseUnit.
SKU property columns: x_SkuCoreCount, x_SkuInstanceType, x_SkuOperatingSystem.
x_ConsumedCoreHours to track total core hours for the charge by multiplying ConsumedQuantity by x_SkuCoreCount.

FOCUS updates for other v1_2 datasets

While updating the Costs dataset, we also updated the other datasets to align to FOCUS 1.2 changes. Changes in other tables weren’t as big, but pair well and will be important to note if you’re using those functions:

CommitmentDiscountUsage
- Added CommitmentDiscountUnit
- Renamed x_CommitmentDiscountQuantity to CommitmentDiscountQuantity
Prices
- Renamed x_PricingCurrency to PricingCurrency
- Renamed x_SkuMeterName to SkuMeter
Transactions
- Renamed x_InvoiceId to InvoiceId

Recommendations changes for the future

In addition to aligning to FOCUS 1.2, we updated the Recommendations dataset schema to account for future plans to ingest Azure Advisor recommendations and also generate custom recommendations. This includes the following new columns:

ResourceId
ResourceName
ResourceType
SubAccountName
x_RecommendationCategory
x_RecommendationDescription
x_RecommendationId
x_ResourceGroupName

These columns are empty today, but will be populated in a future release when the Azure Advisor integration is complete.

Decimal columns switched to the Real datatype

In our initial Data Explorer release, we set all floating-point columns, like prices and costs, to use the decimal datatype. Later, we learned that real is preferred when remaining under a certain level of precision. While we couldn’t make the change in a non-breaking way within the v1_0 schema version, adopting a new schema version offered the perfect chance to address this.

Starting in v1_2, all floating-point columns will use the real datatype. If you’re extending the tables, functions, or building any custom extensions, be sure to switch from decimal to real when you switch to the v1_2 schema. If you opt to remain on v1_0, you can disregard this as v1_0 will continue to use the decimal datatype going forward and will not change based on our non-breaking promise. For those of you who do switch, you may notice a slight performance improvement when working with numbers at scale.

Next steps

Some may look at this update and see it as a simple update to align to FOCUS 1.2, while others may see it as a major shift in how FinOps hubs work and how that impacts the data being ingested. The truth is it’s somewhere in the middle. FinOps hubs were designed to scale beyond a single FOCUS dataset version. And while FinOps hubs have always supported multiple dataset versions with 1.0-preview(v1), 1.0, and 1.0r2, this is the first time when the schema version has seen such a big change, leveraging the inherent benefits of the architecture.

We hope you’re as excited about this as we are. You’ve already taken the first step to adopt FOCUS and now you’ll be able to decide when you’re ready to take the next step to FOCUS 1.2 when and where you need it, while keeping all other reports and integrations steady on 1.0. Minimal impact, maximum potential.

To learn more about managed datasets in FinOps hubs, see FinOps hub data model. And if you’re looking for more, I’m working on a set of premium services designed to help organizations deploy, customize, and scale the FinOps hubs with confidence. Whether you need help getting started, tailoring the tools to your environment, or ensuring long-term success, these services are built to meet you where you are – strategic, secure, and ready to deliver value from day one. Connect with me directly on LinkedIn or Slack to learn more.

News and updates from FinOps X 2025: Transforming FinOps in the era of AI

micflan — Sun, 06 Jul 2025 20:15:56 GMT

Last year, I talked about how Microsoft is empowering stakeholders across the organization with FinOps resources, tools, and services. It's been an amazing year with some unbelievable AI-powered advancements that set the stage for an even more amazing future. AI has become a central theme in nearly every corner of business and technology. It's no surprise that FinOps X 2025 was loaded with news about how AI is changing everything.

Managing AI costs with FinOps

If you’re new to AI or new to FinOps, a great place to start is the FinOps Framework for AI walkthrough. This quick guide offers a high-level overview of the FinOps Framework for AI workloads. From there, check out Understanding AI workload cost considerations for an introduction in some of the factors you’ll need to define the right architectural balance of cost and other metrics to meet your business needs. With these, you should have the foundation for what you need to price out your AI workloads with Azure OpenAI pricing offers.

Regardless of where you are on your AI journey, transparency is key to making smart decisions. And making insights available to every stakeholder is critical to ensuring everyone takes shared ownership for their technology usage. Whether you’re an engineer managing Azure OpenAI costs in the Azure portal or on a business or finance team working out of Power BI or Microsoft Fabric to manage costs and report on unit economics based on token usage (guest perspective), the year has been packed with useful tools and resources to monitor and control your AI spend.

But I have to say, some of the most impactful changes when it comes to FinOps for AI are the introduction of provisioned throughput unit (PTU) reservations and Azure AI Foundry Observability. My favorite part about PTU reservations is that they’re built around you and offer maximum flexibility with 1-month or 1-year reservations. What better way to plan ahead and save on even the newest AI workloads! And with Azure AI Foundry Observability, you have multiple tools all integrated to support monitoring, optimization, and governance, including weighing the cost vs. quality vs. performance of AI models.

And if you’re looking to automate model selection, check out the Azure AI Foundry model router, which can select the best large language model (LLM) to respond to a given prompt in real time by evaluating cost, performance, and query complexity. It’s a brave new world!

Transforming FinOps with AI

And while maximizing ROI for your AI workloads is important, I have to say I’m most excited about advancements in “AI for FinOps”, which is about AI-powered solutions that help you accomplish your FinOps goals. It all begins in the Azure portal, where Copilot in Azure is now generally available! Microsoft Cost Management makes it easier than ever to engage with Copilot with integrated prompts covering new scenarios, like cost estimation and simulation, and the ability to create custom views in Cost analysis. To learn more about what you can do with Copilot in Azure, see Discover cost management opportunities using tailored prompts.

But this is just the beginning. You can also use GitHub Copilot for Azure to answer those same questions directly from Visual Studio Code (or your favorite code editor), bringing FinOps insights right into your development workflow. Additionally, you can simplify and accelerate your journey to the cloud GitHub Copilot App Modernization extension packs for Java and .NET, reducing up-front complexity and costs of migration. And for the power users, GitHub Copilot also enables an innovative Agent mode, which not only answers questions, but can take action for you! Take this even further by connecting GitHub Copilot to FinOps hubs and unleash agentic AI for FinOps in a workspace built for collaboration! Run advanced queries, generate complex reports, and orchestrate data-driven workflows. Forecast your costs, identify anomalous usage and spend patterns, generate code and scripts to automate FinOps processes using the GitHub Copilot coding agent, and more! The sky truly is the limit!

And if you’re looking to bring AI to the masses, ingest your data into Microsoft Fabric, a unified platform that democratizes data engineering for the masses with AI-powered tools, like Copilot, integrated within every experience. And with custom data agents, you can tune that experience to meet your organizational needs and align to your governance policies.

Elevating your FinOps journey with FOCUS

When Microsoft joined the FinOps Foundation, I spoke about the importance of engaging with the community. Over the years, Microsoft has been an engaged member of the FinOps Foundation Governing Board, Technical Advisory Council, several working groups and special interest groups, the FinOps Open Cost and Usage Specification (FOCUS), as well as engaging directly with the FinOps community in Slack. The vibrant, welcoming community is what makes FinOps such a success. If I had to use one word to describe the community, that word would be “family.” And FinOps X is our family reunion where we get to share and celebrate the amazing progress we’ve made both for and with this amazing community.

Last year, we announced FOCUS 1.0 exports in Cost Management. Since then, we’ve seen amazing adoption – more than one-third of all cost exports are FOCUS exports. While adoption has moved much faster than we expected, it’s not surprising, given FOCUS is the best version of our cost data. And with our continued investment in each release, it will only get better. With that, I’m happy to share that a preview of FOCUS 1.2 is now available in Cost Management exports!

If you haven’t tried FOCUS, now is a great time to see what you’re missing. To learn more about FOCUS and its benefits, see What is FOCUS? and explore the many resources to help you understand and adopt FOCUS. For an in-depth walkthrough, check out the Learning FOCUS blog series, which covers every nook and cranny of the specification with useful tips and tricks. And to get started with exports, see Create and manage Cost Management exports.

If you’re already using or plan to use FOCUS, I would encourage you to join the project, share your direct feedback, and help us improve the specification to better meet your needs. Let’s do this together!

Strengthening FinOps fundamentals

There’s a misconception that I still hear today that to adopt FinOps, you need to implement every capability or you must have a central FinOps team. There’s nothing further from the truth. FinOps is about maximizing the ROI you get from technology and the FinOps Framework lays out a map that helps you plot the course for your journey. And with that, we continue to invest in guidance to help educate and enable stakeholders across the organization. From learning modules and documentation to new and evolving FinOps resources that we continually update to align to the latest version of the FinOps Framework, Well-Architected Framework, and Cloud Adoption Framework. And if you need assistance, we can also help you adopt and implement FinOps with specialized offerings from Microsoft Services that cover every aspect of the FinOps Framework – from education and assessments to foundational implementation, operations, and strategic planning. We’re here to help. Reach out to your Microsoft account rep to learn more.

When it comes to FinOps tooling, native provider tools are usually the first place you go for quick and easy answers. I already talked about how Copilot makes it easier and faster than ever to get quick answers with Copilot in Azure—now generally available. If you aren’t using Copilot to answer common questions, you’re missing out. Copilot is continually expanded to support new capabilities, like creating new custom views in Cost analysis, simulating Azure OpenAI costs, troubleshooting disk performance, and more. Cost Management brings Copilot one step closer with embedded Copilot prompts that make it easier to start the right conversation directly from within Cost Management. Add on data quality and completeness improvements, new smart views, like Azure OpenAI costs in Cost analysis, and pricing updates spanning virtual machines, Azure AI, Microsoft Fabric, and more, and there’s plenty to explore!

Looking beyond Cost Management, Azure Carbon Optimization is now generally available, giving you one place to view carbon emissions across services in the Azure portal. Paired with this is new sustainability features in Azure Migrate, which helps you plan your on-premises to cloud migration. With application-aware assessments, integrated sustainability metrics, and a new user experience with enhanced guidance, you’ll want to see how Azure Migrate can help you quantify the value of migrating your workloads to the cloud. To learn more, see Azure Migrate Build 2025 updates.

But that just covers some of the core FinOps tools. We’d need an entirely separate blog post to cover all the updates from all Microsoft Cloud services. I’ll mention just a few and encourage you to follow the Cost Management updates for more.

Azure Backup reduced protected instance fees for SAP HANA backups.
Azure Cache for Redis added a smaller enterprise tier cache instance.
Azure Cosmos DB added dynamic scaling and autoscale for vCore-based MangoDB.
Azure Database for PostgreSQL added new Advisor recommendations and V5 reservations.
Azure Databricks added serverless jobs to reduce unused capacity costs.
Azure DevTest Labs added VM hibernation to reduce costs by pausing VMs while preserving state.
Azure Kubernetes Service added new Advisor recommendations for rightsizing, autoscaling, and more.
Azure Monitor Log Analytics added summary rules to aggregate data, minimize cost, and speed up query performance.
Azure NetApp Files added support for 50 GiB minimum volume sizes, storage with cool access for all service levels, and reservations.
Azure SQL Managed Instance improved the free offer.

If all that isn’t enough, the FinOps blog also has you covered with guidance to control costs with Azure Policy, cut costs with Azure Hybrid Benefit for Linux, optimize storage and VM costs, and more.

Of course, Azure service costs are only part of the equation—SaaS costs are also critical to a holistic FinOps practice, with the added benefit of Marketplace SaaS charges accruing towards your Microsoft Azure Consumption Commitment (MACC), effectively maximizing your rate negotiation power. And now, with flexible billing for private Marketplace offers and the ability to lock in marketplace terms for up to five years, you have more options than ever to strike the right deal with your SaaS vendors that aligns cloud spending with your business needs.

These enhancements help ensure your teams have the clarity and flexibility they need to manage budgets, allocate costs, and drive accountability across the organization. With all these updates, you have more ways than ever to manage, optimize, and report on your cloud investments directly in the Azure portal and other native Microsoft tools.

Unlocking advanced analytics

While the Azure portal makes it easy to get quick answers, sometimes you need more. Whether you need to integrate cost data into an existing system or are simply looking for more flexible reporting, exports offer a reliable, scalable solution that pushes data to you, simplifying data acquisition and ingestion. And with the general availability of Cost Management exports, you can get your data where you need it, in the format you want with support for efficient parquet and compression formats—making it simple to move large datasets into your analytics platform of choice. The new exports platform is available across every Microsoft Cloud environment (including Azure Government and Azure China) supporting Enterprise Agreement, Microsoft Customer Agreement, and Microsoft Partner Agreement accounts and subscriptions. Based on customer feedback, exports also include new AccountId and InvoiceSectionId columns in the latest dataset versions to help allocate costs more precisely across your business.

If you need to manipulate or augment the cost data, Microsoft Fabric provides a unified platform for analytics with all the tools you need to integrate and join with other cloud and business data. Sign up for the Cost Management export to Fabric private preview to push data directly into a Microsoft Fabric lakehouse, removing the need for Azure storage.

If you’re looking for lightweight reporting on data across accounts and subscriptions, the FinOps toolkit now offers Power BI reports that connect to raw exports in storage. This is the quickest way to get up and running in Power BI where you can build more advanced reports with the latest data from Cost Management. FinOps toolkit Power BI reports have a fresh, new look and feel and offer expanded coverage of invoice reconciliation and commitment discount utilization, reservation break-even point, cloud governance, and more.

For more advanced reporting with larger accounts or multi-year reporting needs, FinOps hubs offer an open, extensible platform that scales to meet your needs. FinOps hubs provide scalable analytics that can now be hosted on top of Azure Data Explorer or Microsoft Fabric Real-Time Intelligence. FinOps hubs add network security, a version-agnostic platform that protects you from compatibility issues, multi-tenant, and multi-account support using an extensible platform that can also support cross-cloud reporting needs and supports a broad set of reporting and data connectivity options. FinOps hubs take Cost Management FOCUS exports and perform additional data cleansing to offer the best version of FOCUS data available, using a platform with built-in capabilities like forecasting and anomaly detection. And when you connect FinOps hubs to Microsoft Fabric, you also have a unified platform for self-serve analytics with an AI-powered, SaaS-like experience that streamlines data engineering. Microsoft Fabric offers Copilot integration within every experience, making it effortless to build the solutions and get the answers you need.

You can also leverage GitHub Copilot or your own AI agents to bring agentic AI to your FinOps practice. With FinOps-tuned AI instructions and prompts, GitHub Copilot Agent mode can answer questions about your data, build detailed reports, or orchestrate and automate complex FinOps scenarios.

FinOps hubs is built for the community, by the community to help organizations evolve their FinOps practice and gain the transparency and accountability needed to meet business needs.

Next steps

I hope you're as thrilled as I am about the transformative changes we're witnessing in the realm of FinOps, especially with the advent of AI. The evolution of FinOps in the era of AI is set to revolutionize how we manage cloud and technology innovations, bringing unprecedented efficiency and insights. This is just the beginning, and the potential is limitless. Stay tuned for more updates on the FinOps blog as we continue to explore and innovate in this exciting journey.

FOCUS 1.2 in Microsoft Cost Management: Unified multi-cloud, multi-currency reporting

jozfjon — Sun, 06 Jul 2025 20:20:15 GMT

On June 3, 2025, the FinOps Foundation released the FOCUS 1.2 standard, introducing key enhancements to help FinOps teams analyze, manage, and optimize cloud costs. We’re excited to announce that Microsoft Cost Management now supports exporting cost data using the FOCUS 1.2 schema, available in preview. This update empowers organizations to accelerate their FinOps journey with richer, more standardized data.

FOCUS 1.2 provides FinOps teams with a unified, auditable, and highly detailed dataset that simplifies cost management across cloud, SaaS, and PaaS services. By integrating billing data into a single schema, teams can streamline operations and use one dashboard or query for all technology spend—eliminating redundant workflows.

The dataset is in preview as a few fields required for full FOCUS 1.2 conformance are not yet populated. These will be enabled in future updates as supporting capabilities become available.

What’s new in the FOCUS 1.2-preview dataset

This release introduces several important enhancements designed to make cost management more powerful and intuitive.

Several extension columns have been renamed to align to FOCUS 1.2:

x_InvoiceId is now InvoiceId.
x_PricingCurrency is now PricingCurrency.
x_SkuMeterName is now SkuMeter.

In addition to these, you'll also find a few new columns to provide richer insights and greater flexibility:

ServiceSubcategory is a provider-agnostic breakdown of ServiceCategory.
x_ServiceModel is the cloud service model (IaaS, PaaS, or SaaS) for the service being charged for.
x_SkuPlanName is the marketplace plan name. This was inadvertently left out of our previous FOCUS dataset versions.
x_AmortizationClass indicates if a charge is a principal payment that will be amortized or is an effective charge that is amortized over time. This can be used to filter out principal charges when summing ListCost and ContractedCost to avoid double-counting.

Lastly, the following columns were added to align to FOCUS 1.2 but are not being set yet. These columns are currently null (empty) and will be populated as new capabilities become available. You will not need to update the FOCUS version when they are specified.

CapacityReservationId
CapacityReservationStatus
CommitmentDiscountQuantity
CommitmentDiscountUnit
SkuPriceDetails

Updates for all FOCUS datasets

As part of this update, the following columns were also updated in all FOCUS dataset versions to better align with FOCUS requirements and provide a more complete dataset.

x_SkuTier is now set to a unique tier ID.
SubAccountName, x_AccountId, x_AccountName, x_AccountOwnerId, x_InvoiceSectionId, x_InvoiceSectionName, and x_PricingUnitDescription no longer use placeholder values like “Unassigned” and "-2" to meet FOCUS requirements.

Next steps

To learn more about the FOCUS 1.2 schema and its capabilities, please refer to the FOCUS cost and usage details file schema.

To get started, simply create a new export and select the FOCUS 1.2-preview dataset version. We look forward to seeing how these enhancements help you drive greater value and efficiency in your FinOps practice.

A practitioner's guide to accelerating FinOps with GitHub Copilot and FinOps hubs

Brett_Wilson — Tue, 10 Jun 2025 10:00:00 GMT

ℹ️ Quick implementation overview

Setup time: ~30 minutes for basic configuration
Target audience: FinOps practitioners, finance teams, engineering managers
Prerequisites: Azure subscription with FinOps hubs deployed, VS Code, GitHub Copilot
Key enabler: FinOps Hub Copilot v0.11 release

Key benefits

🎯 Democratized analytics
Non-technical team members can perform advanced cost analysis without KQL expertise.

⚡ Faster insights
Natural language eliminates query writing overhead and accelerates time-to-insights.

📋 FinOps Framework alignment
All queries map directly to validated FinOps Framework capabilities.

🔒 Enterprise ready
Built on proven FinOps hub data foundation with security and governance controls.

FinOps practitioners face a common challenge: bridging the gap between complex cost data and actionable business insights. While FinOps hubs provide a comprehensive, analytics-ready foundation aligned with the FinOps Framework, accessing and analyzing this data traditionally requires deep technical expertise in KQL and schema knowledge.

This guide demonstrates how to perform sophisticated cost analysis using natural language queries using GitHub Copilot in VS Code connected to FinOps hubs 0.11 via the Azure MCP server. This approach democratizes advanced analytics across FinOps teams, supporting faster decision-making and broader organizational adoption of FinOps practices.

ℹ️ Understanding the technology stack
The Model Context Protocol (MCP) is an open standard that enables AI agents to securely connect to external data sources and tools. The Azure MCP server is Microsoft's implementation that provides this connectivity specifically for Azure resources, while GitHub Copilot acts as the AI agent that translates your natural language questions into the appropriate technical queries.

Understanding the foundation: FinOps hubs and natural language integration

FinOps hubs serve as the centralized data platform for cloud cost management, providing unified cost and usage data across clouds, accounts, and tenants. The integration with GitHub Copilot through the Azure MCP server introduces a natural language interface that maps practitioner questions directly to validated KQL queries, eliminating the technical barrier that often limits FinOps analysis to specialized team members.

Note: The FinOps toolkit also includes Power BI reports, workbooks, alerts, and an optimization engine for advanced analytics and automation. See the FinOps toolkit overview for the full set of capabilities.

Key capabilities and technical foundation

ℹ️ About the FinOps toolkit ecosystem
The FinOps toolkit also includes Power BI reports, workbooks, and an optimization engine for advanced analytics and automation. See the FinOps toolkit overview for the full set of capabilities.

FinOps hubs provide several critical capabilities that enable practitioner success:

📊 Data foundation

Centralized cost and usage data across multiple cloud providers, billing accounts, and organizational units
Native alignment with the FinOps Framework domains and FOCUS specification
Analytics-ready data model optimized for performance at scale without complexity overhead

🔗 Integration capabilities

Multiple access patterns: Power BI integration, Microsoft Fabric compatibility, and direct KQL access for advanced scenarios
Natural language query interface through Azure MCP server integration with Copilot

⚙️ Technical architecture

The Azure MCP server acts as the translation layer, implementing the open Model Context Protocol to enable secure communication between AI agents (like GitHub Copilot) and Azure resources. For FinOps scenarios, it specifically provides natural language access to Azure Data Explorer databases containing FinOps hubs data, converting practitioner questions into validated KQL queries while maintaining enterprise authentication and security standards.

Mapping FinOps Framework capabilities to natural language queries

The integration supports the complete spectrum of FinOps Framework capabilities through natural language interfaces. Each query type maps to specific Framework domains and validated analytical patterns:

💡 Quick reference
Each prompt category leverages pre-validated queries from the FinOps hubs query catalog, ensuring consistent, accurate results across different practitioners and use cases.

🔍 Understand phase capabilities

Capability	Natural language example	Business value
Cost allocation and accountability	"Show me cost allocation by team for Q1"	Instant breakdown supporting chargeback discussions
Anomaly detection and management	"Find any cost anomalies in the last 30 days"	Proactive identification of budget risks
Reporting and analytics	"What are our top resource types by spend?"	Data-driven optimization focus areas

⚡ Optimize phase capabilities

Capability	Natural language example	Business value
Rate optimization	"How much did we save with reservations last month?"	Quantification of commitment discount value
Workload optimization	"Show me underutilized resources"	Resource efficiency identification
Governance enforcement	"Show me resources without proper tags"	Policy compliance gaps

📈 Operate phase capabilities

Capability	Natural language example	Business value
Forecasting and planning	"Forecast next quarter's cloud costs"	Proactive budget planning support
Performance tracking	"Show month-over-month cost trends"	Operational efficiency measurement
Business value quantification	"Calculate our effective savings rate"	ROI demonstration for stakeholders

Practical implementation: Real-world scenarios and results

The following examples demonstrate how natural language queries translate to actionable FinOps insights. Each scenario includes the business context, Framework alignment, query approach, and interpretable results to illustrate the practical value of this integration.

ℹ️ Sample data notation
All cost figures, dates, and resource names in the following examples are illustrative and provided for demonstration purposes. Actual results will vary based on your organization's Azure usage, billing structure, and FinOps hub configuration.

Effective cost allocation and accountability

FinOps Framework alignment
Domain: Understand usage and cost
Capabilities: Allocation, Reporting and analytics

Business context
Finance teams require accurate cost allocation data to support budget planning and accountability discussions across organizational units.

Natural language query

What are the top resource groups by cost last month?

Query results and business impact

The natural language prompt maps to a validated allocation query that aggregates effective cost by resource group, providing the foundational data for chargeback and showback processes.

Resource group	Effective cost
haven	$36,972.85
leap	$15,613.96
ahbtest	$6,824.54
vnet-hub-001	$1,560.13
...	...

🎯 Key takeaway
Natural language queries eliminate the need for complex KQL knowledge while maintaining data accuracy. Finance teams can now perform sophisticated cost allocation analysis without technical barriers.

Learn more: Introduction to cost allocation

Proactive cost anomaly detection and management

FinOps Framework alignment
Domain: Understand usage and cost
Capabilities: Anomaly management, Reporting and analytics

Business context
Proactive anomaly detection enables rapid response to unexpected cost changes, supporting budget adherence and operational efficiency.

Natural language query

Are there any unusual cost spikes or anomalies in the last 12 months?

Query results and business impact

The system applies time series analysis to identify significant cost deviations, automatically calculating percentage changes and flagging potential anomalies for investigation.

Date	Daily cost	% change vs previous day
2025-06-03	$971.36	-59.54%
2025-06-01	$2,370.16	-4.38%
2025-04-30	$2,302.10	-5.56%
2025-04-02	$2,458.45	+5.79%
...	...	...

⚠️ Warning: Analysis insight
The 59% cost reduction on June 3rd indicates a significant operational change, such as workload migration or resource decommissioning, requiring validation to ensure expected behavior.

🎯 Key takeaway

Automated anomaly detection enables proactive cost management by identifying unusual spending patterns before they impact budgets, supporting rapid response to operational changes.

Learn more: Anomaly management

Accurate financial forecasting and budget planning

FinOps Framework alignment
Domain: Quantify business value
Capabilities: Forecasting, Planning and estimating

Business context
Accurate financial forecasting supports budget planning processes and enables proactive capacity and cost management decisions.

Natural language query

Forecast total cloud cost for the next 90 days based on the last 12 months.

Query results and business impact

The forecasting algorithm analyzes historical spending patterns and applies trend analysis to project future costs, providing both daily estimates and aggregate totals for planning purposes.

Date	Forecasted cost
2025-06-04	$2,401.61
2025-07-01	$2,401.61
2025-08-01	$2,401.61
2025-09-01	$2,401.61
...	...

Total forecasted 90-day spend: $216,145.24

🎯 Key takeaway
Natural language forecasting queries provide accurate financial projections based on validated historical analysis, enabling confident budget planning without requiring data science expertise.

Learn more: Forecasting

Reporting and analytics capabilities

FinOps Framework alignment
Domain: Understand usage and cost
Capabilities: Reporting and analytics

Business context
Executive reporting requires consistent, reliable cost trend analysis to support strategic decision-making and budget performance tracking.

Natural language query

Show monthly billed and effective cost trends for the last 12 months.

Query results and business impact

Month	Billed cost	Effective cost
2024-06	$46,066.39	$46,773.85
2024-07	$72,951.41	$74,004.08
2024-08	$73,300.31	$74,401.81
2024-09	$71,886.30	$72,951.26
...	...	...

Learn more: Reporting and analytics

Resource optimization analysis

FinOps Framework alignment
Domain: Optimize usage and cost
Capabilities: Workload optimization, Reporting and analytics

Business context
Prioritizing optimization efforts requires understanding which resource types drive the most cost, enabling focused improvement initiatives with maximum business impact.

Natural language query

What are the top resource types by cost last month?

Query results and business impact

Resource type	Effective cost
Fabric Capacity	$34,283.52
Virtual machine scale set	$15,155.59
SQL database	$2,582.99
Virtual machine	$2,484.34
...	...

Learn more: Workload optimization

Implementation methodology

This section provides a systematic approach to implementing natural language FinOps analysis using the technical foundation established above.

Prerequisites and environment validation

Before proceeding with implementation, ensure you have:

✅ Azure subscription with appropriate FinOps hub deployment permissions
✅ Node.js runtime environment (required by Azure MCP Server)
✅ Visual Studio Code with GitHub Copilot extension
✅ Azure CLI, Azure PowerShell, or Azure Developer CLI authentication configured

Access validation methodology

Step 1: Verify FinOps hub deployment

Confirm hub deployment status and data ingestion through the FinOps hubs setup guide

Step 2: Validate database access

Test connectivity to the hub database using Azure Data Explorer web application or Azure portal

Step 3: Confirm schema availability

Verify core functions (Costs, Prices) and databases (Hub, Ingestion) are accessible with current data

Expected Database Structure

Hub database: Public-facing functions including Costs, Prices, and version-specific functions (e.g., Costs_v1_0)
Ingestion database: Raw data tables, configuration settings (HubSettings, HubScopes), and open data tables (PricingUnits)
FOCUS-aligned data: All datasets conform to FinOps Open Cost and Usage Specification standards

Learn more: FinOps hubs template details

Azure MCP server configuration

ℹ️ What is Azure MCP Server?
The Azure Model Context Protocol (MCP) server is a Microsoft-provided implementation that enables AI agents and clients to interact with Azure resources through natural language commands. It implements the open Model Context Protocol standard to provide secure, structured access to Azure services including Azure Data Explorer (FinOps hub databases).

Key capabilities and service support

The Azure MCP server provides comprehensive Azure service integration, particularly relevant for FinOps analysis:

🔍 FinOps-relevant services

Azure Data Explorer: Execute KQL queries against FinOps hub databases
Azure Monitor: Query logs and metrics for cost analysis
Resource groups: List and analyze organizational cost structures
Subscription management: Access subscription-level cost data

🔧 Additional Azure services

Azure Storage, Cosmos DB, Key Vault, Service Bus, and 10+ other services
Full list available in the Azure MCP Server tools documentation

Installation methodology

The Azure MCP Server is available as an NPM package and VS Code extension. For FinOps scenarios, we recommend the VS Code extension approach for seamless integration with GitHub Copilot.

Option 1: VS Code extension (recommended)

Install the Azure MCP server extension from VS Code Marketplace
The extension automatically configures the server in your VS Code settings
Open GitHub Copilot and activate Agent Mode to access Azure tools

Option 2: Manual configuration

Add the following to your MCP client configuration:

{ "servers": { "Azure MCP Server": { "command": "npx", "args": ["-y", "@azure/mcp@latest", "server", "start"] } } }

Authentication requirements

Azure MCP Server uses Entra ID through the Azure Identity library, following Azure authentication best practices. It supports:

Azure CLI: az login (recommended for development)
Azure PowerShell: Connect-AzAccount
Azure Developer CLI: azd auth login
Managed identity: For production deployments

The server uses DefaultAzureCredential and automatically discovers the best available authentication method for your environment.

Technical validation steps

Step 1: Authentication verification

Confirm successful login to supported Azure tools

Step 2: Resource discovery

Validate MCP Server can access your Azure subscription and FinOps hub resources

Step 3: Database connectivity

Test query execution against FinOps hub databases

Integration with development environment

VS Code configuration requirements:

GitHub Copilot extension with Agent Mode capability
Azure MCP Server installation and configuration
FinOps hubs copilot instructions and configuration files

The FinOps Hub Copilot v0.11 release provides pre-configured GitHub Copilot instructions specifically tuned for FinOps analysis. This release includes:

AI agent instructions optimized for FinOps Framework capabilities
GitHub Copilot configuration files for VS Code Agent Mode
Validated query patterns mapped to common FinOps scenarios
Azure MCP Server integration guides for connecting to FinOps hub data

Verification methodology:

Open Copilot Chat interface (Ctrl+Shift+I / Cmd+Shift+I)
Activate Agent Mode and select tools icon to verify Azure MCP Server availability
Execute connectivity test: "What Azure resources do I have access to?"

Expected response validation:

Successful authentication confirmation
Azure subscription and resource enumeration
FinOps hub database connectivity status

Progressive query validation

Foundational test queries:

Complexity level	Validation query	Expected behavior
Basic	"Show me total cost for last month"	Single aggregate value with currency formatting
Intermediate	"What are my top 10 resource groups by cost?"	Tabular results with proper ranking
Advanced	"Find any costs over $1000 in the last week"	Filtered results with anomaly identification

Query execution validation:

KQL translation accuracy against FinOps hub schema
Result set formatting and data type handling
Error handling and user feedback mechanisms

Operational best practices for enterprise implementation

Query optimization and performance considerations

Data volume management:

Implement temporal filtering to prevent timeout scenarios (Azure Data Explorer 64MB result limit)
Use summarization functions for large datasets rather than detailed row-level analysis
Apply resource-level filters when analyzing specific environments or subscriptions

Schema consistency validation:

Reference the FinOps hub database guide for authoritative column definitions
Verify data freshness through ingestion timestamp validation
Validate currency normalization across multi-subscription environments

Query pattern optimization:

Leverage the FinOps hub query catalog for validated analytical patterns
Customize costs-enriched-base query foundation for organization-specific requirements
Implement proper time zone handling for global operational environments

Security and access management

Authentication patterns:

Utilize Azure CLI integrated authentication for development environments
Implement service principal authentication for production automation scenarios
Maintain principle of least privilege for database access permissions

Data governance considerations:

Ensure compliance with organizational data classification policies
Implement appropriate logging for cost analysis queries and results
Validate that natural language prompts don't inadvertently expose sensitive financial data

Comprehensive query patterns by analytical domain

The following reference provides validated natural language prompts mapped to specific FinOps Framework capabilities and proven KQL implementations.

Technical note: Each pattern references validated queries from the FinOps hub query catalog. Verify schema compatibility using the FinOps hub database guide before implementation.

Cost visibility and allocation patterns

Analytical requirement	FinOps Framework alignment	Validated natural language query
Executive cost trend reporting	Reporting and analytics	"Show monthly billed and effective cost trends for the last 12 months."
Resource group cost ranking	Allocation	"What are the top resource groups by cost last month?"
Quarterly financial reporting	Allocation / Reporting and analytics	"Show quarterly cost by resource group for the last 3 quarters."
Service-level cost analysis	Reporting and analytics	"Which Azure services drove the most cost last month?"
Organizational cost allocation	Allocation / Reporting and analytics	"Show cost allocation by team and product for last quarter."

Optimization and efficiency patterns

Analytical requirement	FinOps Framework alignment	Validated natural language query
Resource optimization prioritization	Workload optimization	"What are the top resource types by cost last month?"
Commitment discount analysis	Rate optimization	"Show reservation recommendations and break-even analysis for our environment."
Underutilized resource identification	Workload optimization	"Find resources with low utilization that could be optimized or decommissioned."
Savings plan effectiveness	Rate optimization	"How much did we save with savings plans compared to pay-as-you-go pricing?"
Tag compliance monitoring	Data ingestion	"Show me resources without required cost center tags."

Anomaly detection and monitoring patterns

Analytical requirement	FinOps Framework alignment	Validated natural language query
Cost spike identification	Anomaly management	"Find any unusual cost spikes or anomalies in the last 30 days."
Budget variance analysis	Budgeting	"Show actual vs. budgeted costs by resource group this quarter."
Trending analysis	Reporting and analytics	"Identify resources with consistently increasing costs over the last 6 months."
Threshold monitoring	Anomaly management	"Alert me to any single resources costing more than $5,000 monthly."

Governance and compliance patterns

Analytical Requirement	FinOps Framework Alignment	Validated Natural Language Query
Policy compliance validation	Policy and governance	"Show resources that don't comply with our tagging policies."
Approved service usage	Policy and governance	"List any non-approved services being used across our subscriptions."
Regional compliance monitoring	Policy and governance	"Verify all resources are deployed in approved regions only."
Cost center accountability	Invoicing and chargeback	"Generate chargeback reports by cost center for last quarter."

Key takeaway: These validated query patterns provide a comprehensive foundation for FinOps analysis across all Framework capabilities. Use them as templates and customize for your organization's specific requirements.

Troubleshooting and optimization guidance

Common query performance issues

⚠️ Warning: Performance considerations
Azure Data Explorer has a 64MB result limit by default. Proper query optimization avoids timeouts and ensures reliable performance. If using Power BI, use DirectQuery to connect to your data.

Large dataset timeouts

Symptom: Queries failing with timeout errors on large datasets

Solution: Add temporal filters

✅ Recommended: "Show costs for last 30 days" ❌ Avoid: "Show all costs"

Framework alignment: Data ingestion

Memory limit exceptions

Symptom: Exceeding Azure Data Explorer 64MB result limit

Solution: Use aggregation functions

✅ Recommended: "Summarize costs by month" ❌ Avoid: Daily granular data for large time periods

Best practice: Implement progressive drill-down from summary to detail

Schema validation errors

Symptom: Queries returning empty results or unexpected columns

Solution: Verify hub schema version compatibility using the database guide

Validation: Test with known queries from the query catalog

Query optimization best practices

Temporal filtering

✅ Recommended: "Show monthly costs for Q1 2025" ❌ Avoid: "Show all historical costs by day"

Aggregation-first approach

✅ Recommended: "Top 10 resource groups by cost" ❌ Avoid: "All resources with individual costs"

Multi-subscription handling

✅ Recommended: "Costs by subscription for production environment" ❌ Avoid: "All costs across all subscriptions without filtering"

Conclusion

The integration of FinOps hubs with natural language querying through GitHub Copilot and Azure MCP Server represents a transformative advancement in cloud financial management accessibility. By eliminating technical barriers traditionally associated with cost analysis, this approach enables broader organizational adoption of FinOps practices while maintaining analytical rigor and data accuracy.

Key takeaways for implementation success

Foundation building

Start with the basics:

Ensure robust FinOps hub deployment with clean, consistent data ingestion
Validate authentication and connectivity before advancing to complex scenarios
Begin with basic queries and progressively increase complexity as team familiarity grows

Business value focus

Align with organizational needs:

Align query patterns with organizational FinOps maturity and immediate business needs
Prioritize use cases that demonstrate clear ROI and operational efficiency gains
Establish feedback loops with finance and business stakeholders to refine analytical approaches

Scale and governance planning

Design for enterprise success:

Implement appropriate access controls and data governance from the beginning
Design query patterns that perform well at organizational scale
Establish monitoring and alerting for cost anomalies and policy compliance

Future considerations

As natural language interfaces continue to evolve, organizations should prepare for enhanced capabilities including:

🔮 Advanced analytics

Multi-modal analysis: Integration of cost data with performance metrics, compliance reports, and business KPIs
Predictive analytics: Advanced forecasting and scenario modeling through conversational interfaces

🤖 Automated intelligence

Automated optimization: Natural language-driven resource rightsizing and commitment recommendations
Cross-platform intelligence: Unified analysis across cloud providers, SaaS platforms, and on-premises infrastructure

The democratization of FinOps analytics through natural language interfaces positions organizations to make faster, more informed decisions about cloud investments while fostering a culture of cost consciousness across all teams. Success with this integration requires both technical implementation excellence and organizational change management to maximize adoption and business impact.

Learn more about the FinOps toolkit and stay updated on new capabilities at the FinOps toolkit website.

Microsoft Cost Management updates—May 2025 (summary)

micflan — Mon, 09 Jun 2025 10:00:00 GMT

Here's a quick run-down of the Cost Management updates for May 2025:

View estimated carbon emissions in Azure Migrate
Generally available: Azure Carbon Optimization
Microsoft Customer Agreement cost and usage data quality improvements
Limited preview: Export to Microsoft Fabric
New ways to save money:

Generally available: Enhancements to Purchase-Related Cost Details
Generally available: Smart VM Defaults in AKS
Generally available: Free Azure SQL Managed Instance Offer
Generally available: Free Azure SQL Managed Instance Offer
Preview: Network Optimized Azure Virtual Machines

This is just a quick summary. For the full details, please see Microsoft Cost Management updates—May 2025.

Understanding the Total Cost of Ownership

MariaJoseF — Thu, 02 Apr 2026 05:46:17 GMT

Whether you're just beginning your journey in Azure or are already managing workloads in the cloud, it's essential to ground your strategy in proven guidance. The Microsoft Cloud Adoption Framework for Azure offers a comprehensive set of best practices, documentation, and tools to help you align your cloud adoption efforts with business goals. One of the foundational steps in this journey is understanding the financial implications of cloud migration.

When evaluating the migration of workloads to Azure, calculating the Total Cost of Ownership (TCO) is a crucial step. TCO is a comprehensive metric that includes all cost components over the life of the resource. A well-constructed TCO analysis can provide valuable insights that aid in decision-making and drive financial efficiencies. By understanding the comprehensive costs associated with moving to Azure, you can make informed choices that align with your business goals and budget.

Here is a breakdown of the main elements that you need to build your own TCO:

1. Current infrastructure configuration:

Servers: details about your existing servers, including the number of servers, their specifications (CPU, memory, storage), and operating systems.
Databases: information about your current databases, such as the type, size, and any associated licensing costs.
Storage: type and amount of storage you are currently using, including any redundancy or backup solutions.
Network Traffic: Account for outbound network traffic and any associated costs.

2. Azure Environment Configuration:

Virtual Machines (VMs): appropriate Azure VMs that match your current server specifications. This has to be based on CPU, memory, storage, and region.
Storage Options: type of storage (e.g., Standard HDD, Premium SSD), access tiers, and redundancy options that align with your needs.
Networking: networking components, including virtual networks, load balancers, and bandwidth requirements.

3. Operational Costs:

Power and Cooling: Estimate the costs associated with power and cooling for your on-premises infrastructure.
IT Labor: Include the costs of IT labor required to manage and maintain your current infrastructure.
Software Licensing: Account for any software licensing costs that will be incurred in both the current and Azure environments.

Once you have more clarity of these inputs you can complement your analysis with other tools depending on your needs. The Azure Pricing Calculator is well suited to providing granular cost estimation for different Azure services and products. However, if the intent is to estimate cost and savings during migrations, Azure Migrate business case feature should be the preferred approach as it will allow the user to perform detailed financial analysis (TCO/ROI) for the best path forward and assess readiness to move workloads to Azure with confidence.

Understand your Azure costs

The Azure pricing calculator is a free cost management tool that allows users to understand and estimate costs of Azure Services and products. It serves as the only unauthenticated experience that allows you to configure and budget the expected cost of deploying solutions in Azure

The Azure pricing calculator is key for properly adopting Azure. Whether you are in a discovery phase and trying to figure out what to use, what offers to apply or in a post purchase phase where you are trying to optimize your environment and see your negotiated prices, the azure pricing calculator fulfills both new users and existing customers' needs.

The Azure pricing calculator allows organizations to plan and forecast cloud expenses, evaluate different configurations and pricing models, and make informed decisions about service selection and deployment options.

Decide, plan, and execute your migration to Azure

Azure Migrateis Microsoft’s free platform for migrating to and modernizing in Azure. It provides capabilities for discovery, business case (TCO/ROI), assessments, planning and migration in a workload agnostic manner. Customers must have an Azure account and create a migration project within the Azure portal to get started. Azure Migrate supports various migration scenarios, including for VMware and Hyper-V virtual machines (VM), physical servers, databases, and web apps. The service offers accurate appliance based and manual discovery options, to cater to customer needs.

The Azure Migrate process consists of three main phases: Decide, Plan, and Execute. In the Decide phase, organizations discover their IT estate through several supported methods and can get a dependency map for their applications to help collocate all resources belonging to an application. Using the data discovered, one can also estimate costs and savings through the business case (TCO/ROI) feature. In the Plan phase, customers can assess for readiness to migrate, get right-sized recommendations for targets in Azure and tools to use for their migration strategy (IaaS/PaaS). Users can also create a migration plan consisting of iterative “waves” where each wave has all dependent workloads for applications to be moved during a maintenance window. Finally, the Execute phase focuses on the actual migration of workloads to a test environment in Azure in a phased manner to ensure a non-disruptive and efficient transition to Azure.

A crucial step in the Azure Migrate process is building a business case prior to the move, which helps organizations understand the value Azure can bring to their business. The business case capability highlights the total cost of ownership (TCO) with discounts and compares cost and savings between on-premises and Azure including end-of-support (EOS) Windows OS and SQL versions. It provides year-on-year cash flow analysis with resource utilization insights and identifies quick wins for migration and modernization with an emphasis on long-term cost savings by transitioning from a capital expenditure model to an operating expenditure model, paying only for what is used.

Understanding the Total Cost of Ownership (TCO) is essential for making informed decisions when migrating workloads to Azure. By thoroughly evaluating all cost components, including infrastructure, operational, facilities, licensing and migration costs, organizations can optimize their cloud strategy and achieve financial efficiencies. Utilize tools like the Azure Pricing Calculator and Azure Migrate to gain comprehensive insights and ensure a smooth transition to the cloud.

What's new in FinOps toolkit 0.11 – May 2025

micflan — Sun, 06 Jul 2025 20:20:29 GMT

Whether you consider yourself a FinOps practitioner, someone who’s enthusiastic about driving cloud efficiency and maximizing the value you get from the cloud or were just asked to look at ways to reduce cost, the FinOps toolkit has something for you. This month, you’ll find support for AI agents like GitHub Copilot, Power BI updates for invoicing, commitment discounts, and usage analysis, documentation updates from the top feature asks, and more! Read on for details.

New to the FinOps toolkit?

Introducing agentic AI for FinOps hubs

Not long ago, AI was a niche tool reserved for specialized tasks. Something tinkerers and researchers played with in controlled environments. Now, it’s everywhere—answering questions, summarizing content, and even helping generate new content. But the real game-changer is moving beyond the simple question-response loop and leveraging AI for complex workflows where you tie specialized agents together to not only summarize and generate content but take action and perform tasks on your behalf. A true assistant. And with the new FinOps hubs copilot instructions, you can connect AI agents to your organizational data and orchestrate FinOps scenarios.

With the latest update to the FinOps hubs, AI agents—including GitHub Copilot—can now seamlessly connect to FinOps hubs, leveraging predefined AI instructions and the Azure MCP server to unlock FinOps insights in real time. This means any AI-powered assistant can query and interpret FinOps data, providing developers, finance teams, and operations specialists with instant visibility into cloud costs, efficiency metrics, and optimization recommendations—without needing manual intervention or deep KQL expertise. By integrating AI-driven decision-making into FinOps workflows, this feature redefines what’s possible when intelligent automation meets financial operations at scale.

The easiest way to get started is with GitHub Copilot in Visual Studio Code. You don’t need to be a developer or know how to write code. You can download and extract the FinOps hubs copilot instructions and connect to your hub instance in minutes. To learn more, see Configure and use AI agents.

Power BI updates for invoicing, commitment discounts, and usage analysis

We’re constantly looking for ways to improve the built-in reports to support your needs. In the May release, you’ll find a new report for Invoicing and chargeback and new pages within the Rate optimization and Cost summary reports.

The Invoicing and chargeback report helps you implement the Invoicing and chargeback capability. The report includes a few breakdowns of your billed cost, invoice recon pages for both Enterprise Agreement (EA) and Microsoft Customer Agreement (MCA), chargeback pages, and more!

In the Rate optimization report you’ll find two new pages for commitment discounts. First up is the Commitment discount utilization page, which shows your aggregate utilization percentage across all commitment discounts going back as far as you’ve exported your data. This was created after a request for historical data beyond the past few months you can see in the portal. You can also customize the report to show a specific utilization target and don’t forget to configure alerts when you publish the report to your Power BI workspace!

You’ll also find a new Commitment discount resources page which shows the resources that consumed a specific commitment discount. This is fairly straightforward, but answers a common question we hear during exploration. And one great thing about both of these pages is that you can right-click any commitment discount throughout the Rate optimization report to drill through to these pages for a specific commitment discount. This can be very helpful when investigating data in a more seamless way.

And lastly, the Cost summary report includes a new Usage analysis page that shows usage over time compared to cost for a specific unit. You’ll find a breakdown of cost over time by meter category with an overlaid total cost in the chart, plus a table of each charge with its consumed quantity, block size, price, and total cost. I shared this in a recent Learning FOCUS blog post, so it’s great to see this now available for you leverage and let us know how we can improve.

To learn more about all reports, see FinOps toolkit Power BI reports. We hope you’ll find these Power BI updates helpful and encourage you to share your feedback about what you’d like to see in future updates. We’re always looking for ways to improve your experience and welcome any new ideas or even pull requests! (I just saw a new pull request from a customer today!)

Listening to the community: FinOps hubs documentation updates

Every month we try to implement one of the top feature requests submitted and voted on by the community. This month, we picked up two changes related to FinOps hubs documentation. The first is one about publishing an architecture diagram to help organizations understand what’s included in the template and how the system works at a high level.

If you’re new, FinOps hubs is a data pipeline solution that takes Cost Management exports and uses Azure Data Factory to ingest data into Azure Data Explorer or Microsoft Fabric. Power BI reports and Data Explorer dashboards are available to help visualize and explore costs in detail. And, new this month, AI agents like GitHub Copilot can access the data in Data Explorer using the Azure MCP server. To learn more, see the FinOps hubs overview.

With the expansive growth of FinOps hubs, we’ve also started to get deeper questions around the upgrade process and frequency. With FinOps toolkit updates released monthly, some organizations are curious how often they should plan to update. And as usual, the answer is, “it depends”. When you update ultimately depends on the features you need. If there’s an important feature that you need now, then upgrade to the latest version when it gets released. If you don’t need any of the updates, then skip that release. In general, there isn’t a penalty or risk skipping one or more releases. While we hope you’ll find valuable new and updated features in each release, we also want to minimize the operational management effort. And with that, we’ve refactored the FinOps hub upgrade guide to make it easier and clearer to understand what steps are required to upgrade from one version to another, even if you’re skipping one or more releases.

The new upgrade guide organizes all steps into a simple, clear tutorial that helps you upgrade to the latest version from any previous release. Each step clearly calls out when it’s required or if it can be skipped for specific releases. If you’ve ever had a question about the exact steps to update from an older version, we hope this will help you get there!

Every month we try to implement one of the top feature requests. This month, we picked up two changes related to FinOps hubs documentation. The first is one about sharing a FinOps hubs architecture diagram. Fairly straightforward.

Other new and noteworthy updates

Many small improvements and bug fixes go into each release, so covering everything in detail can be a lot to take in. But I do want to call out a few other small things that you may be interested in.

In the Implementing FinOps guide:

Documented a new FOCUS 1.0 conformance gap where ServiceName may be empty for some purchases and adjustments.

In FinOps hubs:

Fix BillingPeriodStart and BillingPeriodEnd to always be at the start of the month.
Added support for backporting FOCUS 1.2 into the existing FOCUS 1.0 schema (when released later this month).
- This is a short-term solution to avoid errors if FOCUS 1.2 exports are created.
- Full FOCUS 1.2 support will come in a future release.
Refactored internal code to align with our vision for the FinOps hubs extensibility model.

In Power BI reports:

Fixed inconsistent numbers in the running total chart caused by date handling issues

In FinOps alerts:

Added telemetry to the FinOps alerts template to track usage and bugs.

In Azure optimization engine:

Upgraded Azure Resource Manager SQL Server name availability API version, used by the engine deployment script, due to upcoming deprecation of 2014-04-01 version.

In PowerShell commands:

Fixed a date handling error in the Start-FinOpsCostExport command.
Fixed upcoming breaking changes warning in Get-AzAccessToken cmdlet by adding temporary warning suppression.

In open data:

Added the "10 Seconds" unit of measure.
Added 24 new and 19 existing resource types.
Added 24 new service mappings.

What’s next

I’m excited about what’s coming over the next few months. Here are a few of the things we’re looking at:

FinOps hubs will add recommendations, similar to what you see in Azure Optimization Engine and FinOps workbooks, a new extensibility model to support customizations at scale, and continued data quality improvements on top of what Cost Management provides.
FinOps hubs and Power BI will both get updated to support FOCUS 1.2.
Power BI will continue to get recurring updates and expand to more FinOps capabilities.
FinOps workbooks will continue to get recurring updates, expand to more FinOps capabilities, and add cost from FinOps hubs.
Azure Optimization Engine will continue to receive small updates as we move its capabilities into FinOps hubs in upcoming releases.
Each release, we’ll try to pick at least one of the highest voted issues (based on 👍 votes) to continue to evolve based on your feedback, so keep the feedback coming!

To learn more, check out the FinOps toolkit roadmap, and please let us know if there’s anything you’d like to see in a future release. Whether you’re using native products, automating and extending those products, or using custom solutions, we’re here to help make FinOps easier to adopt and implement.

Learning FOCUS: Prices + quantities

micflan — Sun, 06 Jul 2025 20:20:52 GMT

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:

Column	Value
PricingQuantity	0.24
PricingUnit	Hours
x_PricingBlockSize	100
x_PricingUnitDescription	100 Hours

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

Column	Value
ConsumedQuantity	24
ConsumedUnit	Hours

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.

Cost Management	FOCUS
(none)	ConsumedQuantity
UnitOfMeasure	ConsumedUnit
Quantity	PricingQuantity
UnitOfMeasure	PricingUnit
UnitOfMeasure	x_PricingBlockSize
UnitOfMeasure	x_PricingUnitDescription
(none)	FOCUS 1.1: CommitmentDiscountQuantity
(none)	FOCUS 1.1: CommitmentDiscountUnit
PayGPrice	ListUnitPrice
UnitPrice	ContractedUnitPrice
EffectivePrice (actual cost data)	x_BilledUnitPrice
EffectivePrice (amortized cost data)	x_EffectiveUnitPrice

For more details, refer to the following articles:

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.

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) ⮞

How to control your Azure costs with Governance and Azure Policy

AndrewLuckwell — Wed, 18 Jun 2025 23:23:55 GMT

Azure resources can be configured in many ways, including ways which affect their performance, security, reliability, available features and ultimately cost.

The challenge is, all these resources and configurations are completely available to us by default. As long as someone has permission, they can create any resource and configuration they like. This implicit “anything goes” gives our technical teams the freedom to decide what’s best. Like a kid in a toy shop, they will naturally favour the biggest, fastest and coolest toys.

The immediate risk of course, is building beyond business requirements. Too much SKU, too much resilience, too much performance and too high cost.

Left unchecked, and we risk increasingly challenging and long-term issues:

Over-delivering will quickly become the norm.
Excessive resources configurations will become the habitual default in all environments.
Teams will become mis-aligned from wider business requirements.
Teams will become used to working in a frictionless environment, and challenge any restrictions.
FinOps teams will be stuck in endless cost optimisation work.

You may already be feeling the pain. Trapped in a cycle of repetitive, reactive cost optimisation work, seeing the same repeat offenders and looking for a way out. To break (or prevent) the cycle, a new approach is needed. We must switch priorities from detection and removal, to prevention and control. We must keep waste out. We must avoid over-provisioning.

We can achieve this with governance.

What is governance

Governance is a collection of rules, processes and tools that control how an organization consumes IT resources. It ensures our teams deploy resources that align to certain business goals, like security, cost, resource management and compliance.

Governance rules are like rules for a boardgame. They define how the game should be played, no matter who is playing the game.

This is important. It aligns everyone to our organization's rules regardless of role, position, seniority and authority. It helps ensures people play by the rules rather than their rules. Try playing Monopoly with no rules. What’s going to happen? I will pass go, and I will collect 200 dollars.

For Microsoft Azure, and the cloud in general, governance is centered around controlling how resources can and cannot be configured.

Storage Accounts should be configured like this.
Virtual Machines must be configured like that.
Disks can’t be configured with this.

It's as much about keeping wrong configurations out, as the right configurations in. When we enforce configurations that meet our goals and restrict those that don’t, we drastically increase our chance of success.

Why governance matters for FinOps

Almost all over-provisioning and waste can be traced back to how a resource is configured. From SKU, to size, redundancy and additional features, if it’s not needed it’s being wasted.

That’s all over-provisioning and waste is; Resources, properties and values that we don’t need.

Too much SKU, like Premium Disks Standard HDD/SSD.
Too much redundancy, like Storage Accounts with GRS when LRS is fine.
Too many features, like App Gateways with WAF but it’s disabled.

Have a think for a moment. What over-provisioning have you seen in the past? Was it one or two resource properties causing the problems?

Whatever you’ve seen, with governance we can stop it happening again.

When we control how resources get configured, we can control over-provisioning and waste, too. We can determine configurations we don’t need through our optimization efforts, and then create rules that define the configurations we do need:

“We don’t need Premium SSD disks.” becomes “Disks must be Standard HDD/SSD.”

“We don’t need Storage Accounts with GRS.” becomes “Storage Accounts must use LRS.”

“We don’t need WAF enabled Application Gateways” becomes “Application Gateways should be Standard SKUs”

These rules effectively remove the option to build beyond requirements. They will help teams avoid building too much/too big, stay within their means, hold them a bit more accountable and protect us from future overspend.

Detection becomes Prevention. Removal becomes Control.

Over time, we will:

Help our teams deliver just enough.
Raise and improve awareness of over-configurations and waste.
Help keep waste out once it’s found.
Reduce the chances over-provisioning in future.
Steadily reduce the need for ongoing Cost Optimisation efforts.
Free up time for other FinOps stuff.

This is why governance is a natural evolution from cost optimization, and why it’s critical for FinOps teams who want to be more proactive and spend less time cleaning up after tech teams.

How can we natively govern Microsoft Azure?

In Microsoft Azure, we can use the native governance service Azure Policy to help control our environments. We can embed our governance rules into Azure itself and have Azure Policy do the heavy lifting of checking, reporting and enforcing.

Azure Policy has many useful features:

Supports over 74000 resource properties, including all that generate costs.
Can audit resources, deny deployments and even auto-resolve resources as they come into Azure.
Provides easy reporting of compliance issues, saving time on manual checks.
Checks every deployment from every source. From Portal to Terraform, it’s got you covered.
Supports different scopes from Resource Groups to Management Groups, allowing policies to be used at any scale.
Supports parameters, making policies re-usable and quick to modify when responding to change in requirements.
Exemptions can be used on resources we want to ignore for now.
Supports different enforcement modes, for safe rollout of new policies.
It comes at no additional cost. Free!

These features make Azure Policy an extremely flexible and powerful tool that can help control resources, properties and values at any scale.

We can:

Create Policies for almost any cost-impacting value. SKUs, Redundancy Tiers, Instance Sizes, you name it…
Use different effects based on how ‘strict’ the rule should be. For example, we can use Deny (resource creation) for resource missing “Must have” attributes, and Audit to check if resources are still compliant with “Should have” attributes.
Use a combination of effects, enforcement modes and exemptions to control the rollout of new policies.
Reuse the Policies on multiple environments (like development versus production), with different values and effects depending on the environment's needs.
Quickly change the values when needed. When requirements change, the parameters can be modified with little effort.

How to avoid unwanted Friction

A common concern with governance is that it will create friction, interrupt work and slow teams down. This is a valid concern, and Azure Policy’s features allow for a controlled and safe rollout. With a good plan there is no need to worry.

Consider the following:

Start with Audit-Only policies and non-production environments.
Start with simpler resources and regular/top offenders.
Test policies in sandboxes before using them in live environments.
Use the ‘Do not Enforce’ mode when first assigning Deny policies. This treats them as Audit-only, allowing review before being enforced.
Always parameterize Effects and Values, for quick modification when needed.
Use exemptions when there are sensitive resources that are best to ignore for now.
Work with your teams and agree to a fair and balanced approach. Governance is for everyone and should include everyone where possible.

The biggest challenge of all may be breaking habits formed over years of freedom in the Cloud. It’s natural to resist change, especially when it takes away our freedom.

Remember, it’s friction where it’s needed, Interuption where it’s needed, slow down where it’s needed.

They key to getting teams onboard is delivering the right message. Why are we doing this? How will they benefit? How does it help them? How could they be impacted if you do nothing?

This needs to be more than “To meet our FinOps goals”. That’s your goal, not theirs. They won’t care.

Try something like:

We keep seeing over-utilization and waste and are spending an additional ‘X amount’ of time and money trying to remove it. This is now impacting our ability invest properly into our IT teams, affecting other departments and impacting our overall growth.

If we can get over-spend reduced and under control, we can re-invest where you need it; tooling, people, training and anything else that makes your lives better.

We want to implement governance rules and policies that will prevent issues reoccurring. With your insights and support we can achieve this faster, avoid unwanted impact, and can re-invest back into our IT teams once done.

Sound good to you?!

This is far more compelling and gives them reason to get onboard and help out.

How to start your FinOps governance journey

Making the jump from workload optimization into governance might initially sound challenging, but it’s actually pretty straightforward.

Consider the typical workload optimization cycle:

Discover potential misconfiguration, optimization and waste cleanup opportunities.
Compare to actual business requirements.
Optimize workload to meet those business requirements.

A governance practice extends this to the following:

Identify potential misconfigurations, optimization and waste cleanup opportunities.
Compare to actual business requirements.
Optimize workload to meet those business requirements.
Create an Azure Policy based on how the resource should have originally been configured, and how it should remain in future.

Thats it, one extra step.

Most of the hard work has already happened in steps 1-3, in the workload optimization we’ve already been doing. Step 4 simply turns the optimization into rule that says “This resource must be like this from now on”, preventing it happening again.

Let's do it again with a real resource, an Azure Disk:

Identify Premium SSD Disks in non-production environment.
Compare to business requirements, which confirms Standard HDD is fine.
Change Disk SKU from Premium to Standard HDD.
Create Azure Policy that only allows Disks with Standard HDD in the environment and denies other SKUs.

Done. No more Premium SSDs in this environment again. Prevention and Control.

The real work lies in being able to understand and identify how resources become over-provisioned and wasteful. Until then we will struggle to optimize, let alone govern.

The Wasteful Eight

There's so many resources and properties available. Understanding all the ways they can create waste can be challenging.

Fortunately, we can group resource properties into eight main categories, which make our efforts a bit easier. Lets look at the Wasteful Eight:

Category	Examples
Over-provisioned SKUs	- Disks with Premium SSD instead of Standard HDD/SSD. - App Service Plans with Premium SKU, instead of Standard. - Azure Bastion with Premium SKU, instead of Developer.
Too much redundancy	- Storage Accounts configured with GRS, when LRS is fine. - Recovery Services Vaults with GRS, when LRS is fine. - SQL Databases with Zone Redundancy enabled.
Too large / too many instances.	- Azure VMs with too many CPUs. - SQL Databases with too many vCores/DTUs. - Disks which are over 1024GB.
Supports auto-scaling/serverless, but aren’t using it.	- Application Gateway doesn’t have auto-scaling enabled. - App Service Plans without Auto-Scaling. - SQL Databases using fixed provisioning, instead of Serverless or Elastic Pools
Too many backups.	- Backups that are too frequent. - Backups with too long retention periods. - Non-prod backups with similar retentions as Prod.
Too much logging.	- Logging enabled in non-prod. - Log retentions too long. - Logging to Log Analytics instead of Storage Accounts. - Log Analytics not using cheaper table plans.
Extra features that are disabled, or not being used.	- Application Gateway with WAF SKU, but the WAF is disabled. - Azure Firewall with Premium SKU, but IDPS is disabled. - Storage Accounts with SFTP enabled but not used.
Orphaned/Unused.	- Unattached Disks - Empty App Service Plans - Unattached NAT Gateways

Remember, it's only wasteful if you don't have a business need for it, like too much redundancy in a non-production/development environment. In a production environment, you're likely to need premium disks or SKUs, GRS, and longer logging and backup retention periods. Governance is about reducing spend where you don't need it, and frees up money to spend where you do need it, for better redundancy, faster response times etc.

All resources will fall somewhere in the above categories. A single resource can be found in most of them.

For example, an Application Gateway can:

Have an over-provisioned/unused SKU (WAF vs Standard).
Have auto-scaling disabled.
Have too many instances.
Have excessive logging enabled.
Have the WAF SKU, but the WAF is for some reason disabled.
Be orphaned, by having no backend VMs.

Breaking down any resource like this will uncover most of its cost-impacting properties and give us a good idea of what to focus on. A few outliers are inevitable, but the vast majority will be covered.

Let's explore the Application Gateway examples further, the reasons why each item is wasteful and the subsequent Policies we might consider in a non-production environment. I’ve also included some links to respective Azure Policy definitions available in GitHub (test before use!).

Discovery	Reason	Governance Rule/Policy	Allowed Values and effects if applicable
Application Gateway has WAF SKU but doesn’t need it.	We use another firewall product.	Allowed Application Gateway SKUs	Standard Deny
Application Gateway isn’t configured with Auto-Scaling, creating inefficient use of instances.	Auto-Scaling improves efficiency by scaling up and down as demand changes. Manual scaling is inefficient.	Application Gateway should be configured with Auto-Scaling.	Deny
Application Gateway min/max instance counts are higher than needed.	Setting Min/Max instance thresholds avoids them being too high. Particularly the min count, which might not need more than 1 instance.	Allowed App Gateway Min/Max instance counts	Min Count: 1 Max Count: 2 Deny
Non-Prod Application Gateways have logging enabled, when it’s not needed.	We don't have usage that needs to be logged in non-production environments.	Non-Prod Application Gateways should avoid logging	Deny
Application Gateway has WAF but it’s disabled.	A disabled WAF is doing nothing yet still paid for. Either use it, or change the Tier to Standard to reduce costs.	Application Gateway WAF is disabled.	Audit
Application Gateway has no Backend Pool resources.	Indicates an orphaned/unused App Gateway. It should be removed.	Application Gateway has empty Backend Pool and appears Orphaned	Audit

Now this might seem a bit over the top. Do we really to be controlling our App Gateway min/max scaling counts? It depends. If you have a genuine problem with too many instances then yes, you probably should.

The point is, you can if you need to. This simply demonstrates how powerful governance and Azure Policy can be at controlling how resources are used.

A more likely starting point will be things like SKUs, Sizes, Redundancy Tiers and Logging. These are the high risk, high impact areas you’ve probably seen before and want to avoid again.

Once you exhaust those it's time to jump into Cost Management and explore your most expensive resources and services. Explore the Billing Meters to see how each resources costs are broken down. This is where your money is going and where your governance rules will have the biggest impact.

Where to find Azure Policies

If you want to use Azure policy you're going to need some Policy Definitions. A Definition is your governance rule defined in Azure. It tells Azure what configurations you do and don't want, and how to deal with problems.

It's recommended that you start with some of the in-built policies first, before creating your own. These are provided by Microsoft, available inside Azure Policy to be applied, and are maintained by Microsoft. Fortunately, there are plenty of policies to choose from: built-in, community provided, Azure Landing Zone related and a few of my own:

Azure Built-in Policy Repo: https://github.com/Azure/azure-policy

Azure Community Policy Repo: https://github.com/Azure/Community-Policy

Azure Landing Zones Policies: https://github.com/Azure/Enterprise-Scale/blob/main/docs/wiki/ALZ-Policies.md

My stuff: https://github.com/aluckwell/Azure-Cost-Governance

Making the search even easier is the AzAdvertizer. This handy tool brings thousands of policies into a single location, with easy search and filter functionality to help find useful ones. It even includes 'Deploy to Azure' links for quick deployment.

AzAdvertizer: https://www.azadvertizer.net/azpolicyadvertizer_all.html

Of the thousands of policies in AzAdvertizer, the list below is a great starting point for FinOps. These are all built-in, ready to go and will help you get familiar with how Azure Policy works:

Policy Name	Use Case	Link
Not Allowed Resource Types	Block the creation of resources you don't need. Helps control when resource types can/can't be used.	https://www.azadvertizer.net/azpolicyadvertizer/6c112d4e-5bc7-47ae-a041-ea2d9dccd749.html
Allowed virtual machine size SKUs	Allow the use of specific VM SKUs and Sizes and block SKUs that are too big or not fit for our use-case.	https://www.azadvertizer.net/azpolicyadvertizer/cccc23c7-8427-4f53-ad12-b6a63eb452b3.html
Allowed App Services Plan SKUs	Allow the use of specific App Service Plan SKUs. Block SKUs that are too big or not fit for our use-case.	https://www.azadvertizer.net/azpolicyadvertizer/27e36ba1-7f72-4a8e-b981-ef06d5c78c1a.html
[Preview]: Do not allow creation of Recovery Services vaults of chosen storage redundancy.	Avoid Recovery Services Vaults with too much redundancy. If you don't need GRS, block it.	https://www.azadvertizer.net/azpolicyadvertizer/8f09fda1-91a2-4e14-96a2-67c6281158f7.html
Storage accounts should be limited by allowed SKUs	Avoid too much redundancy and performance when it's not needed.	https://www.azadvertizer.net/azpolicyadvertizer/7433c107-6db4-4ad1-b57a-a76dce0154a1.html
Configure Azure Defender for Servers to be disabled for resources (resource level) with the selected tag	Disable Defender for Servers on Virtual Machines if they don't need it. Help control the rollout of Defender for Servers, avoiding machines that don't need it.	https://www.azadvertizer.net/azpolicyadvertizer/080fedce-9d4a-4d07-abf0-9f036afbc9c8.html
Unused App Service plans driving cost should be avoided	Highlight when App Service Plans are 'Orphaned'. Either put them to use or get them deleted ASAP.	https://www.azadvertizer.net/azpolicyadvertizer/Audit-ServerFarms-UnusedResourcesCostOptimization.html

New policies are always being added, and existing policies improved (see the Versioning). Check back occasionally for changes and new additions that might be useful.

When you get the itch to create your own, I'd suggest watching the following videos to understand the nuts and bolts of Azure Policy, and then onto Microsoft Learn for further reading.

https://www.youtube.com/watch?v=4wGns611G4w

https://www.youtube.com/watch?v=fhIn_kHz4hk

https://learn.microsoft.com/azure/governance/policy/overview

Good luck!

Getting started with FinOps hubs: Multicloud cost reporting with Azure and Google Cloud

GrahamM — Fri, 27 Jun 2025 16:43:31 GMT

Microsoft’s FinOps hubs offer a powerful and trusted foundation for managing, analyzing, and optimizing cloud costs. Built on Azure Data Explorer (ADX) and Azure Data Lake Storage (ADLS), FinOps hubs provide a scalable platform to unify billing data across providers leveraging FOCUS datasets.

In this post, we’ll take a hands-on technical walkthrough of how to connect Microsoft FinOps hubs to Google Cloud, enabling you to export and analyze Google Cloud billing data with Azure billing data directly within your FinOps hub instance. This walk through will focus on using only storage in the hub for accessing data and is designed to get you started and understand multicloud connection and reporting from FinOps hubs. For large datasets Azure Data Explorer or Microsoft Fabric is recommended.

With the introduction of the FinOps Open Cost and Usage Specification (FOCUS), normalizing billing data and reporting it through a single-pane-of-glass experience has never been easier.

As a long-time contributor to the FOCUS working group, I’ve spent the past few years helping define standards to make multicloud reporting simpler and more actionable. FOCUS enables side-by-side views of cost and usage data—such as compute hours across cloud providers—helping organizations make better decisions around workload placement and right-sizing. Before FOCUS, this kind of unified analysis was incredibly challenging due to the differing data models used by each provider.

To complete this technical walk through, you’ll need access to both Azure and Google Cloud—and approximately 2 to 3 hours of your time.

Getting started: The basics you’ll need

Before diving in, ensure you have the following prerequisites in place:

✅ Access to your Google Cloud billing account.

✅ A Google Cloud project with BigQuery and other APIs enabled and linked to your billing account.

✅ All required IAM roles and permissions for working with BigQuery, Cloud Functions, Storage, and billing data (detailed below).

✅ Detailed billing export and pricing export configured in Google Cloud.

✅ An existing deployment of FinOps hubs.

What you’ll be building

In this walk-through, you’ll set up Google billing exports and an Azure Data Factory pipeline to fetch the exported data, convert to parquet and ingest into your FinOps hub storage, following the FOCUS 1.0 standard for normalization.

Through the process you should end up creating:

Configure a BigQuery view to convert detailed billing exports into the FOCUS 1.0 schema.
Create a metadata table in BigQuery to track export timestamps to enable incremental data exports reducing file export sizes and avoiding duplicate data.
Set up a GCS bucket to export FOCUS-formatted data in CSV format.
Deploy a Google Cloud Function that performs incremental exports from BigQuery to GCS.
Create a Google Cloud Schedule to automate the export of your billing data to Google Cloud Storage.
Build a pipeline in Azure Data Factory to:
- Fetch the CSV billing exports from Google Cloud Storage.
- Convert them to Parquet.
- Ingest the transformed data into your FinOps hub ingestion container.

Let's get started. We're going to start in Google Cloud before we jump back into Azure to setup the Data Factory pipeline.

Enabling FOCUS exports in Google

Prerequisite: Enable detailed billing & pricing exports

⚠️ You cannot complete this guide without billing data enabled in BigQuery if you have not enabled detailed billing exports and pricing exports, do this now and come back to the walk-through in 24 hours.

Steps to enabled detailed billing exports and pricing exports:

Navigate to Billing > Billing Export.
Enable Detailed Cost Export to BigQuery.
Select the billing project and a dataset - if you have not created a project for billing do so now.
Enable Pricing Export to the same dataset.

🔊 “This enables daily cost and usage data to be streamed to BigQuery for granular analysis.”

Detailed guidance and information on billing exports in Google can be found here: Google Billing Exports.

What you'll create:

Service category table
Metadata table
FOCUS View - you must have detailed billing export and pricing exports enabled to create this view
Cloud Function
Cloud Schedule

What you'll need

An active GCP Billing Account (this is your payment method).
A GCP Project (new or existing) linked to your GCP billing account.
All required APIs enabled.
All required IAM roles enabled.

Enable Required APIs:

BigQuery API
Cloud Billing API
Cloud Build API
Cloud Scheduler
Cloud Functions
Cloud Storage
Cloud Run Admin
Pub/Sub (optional, for event triggers)

Required IAM Roles

Assign the following roles to your user account:

roles/billing.viewer or billing.admin
roles/bigquery.dataEditor
roles/storage.admin
roles/cloudfunctions.admin
roles/cloudscheduler.admin
roles/iam.serviceAccountTokenCreator
roles/cloudfunctions.invoker
roles/run.admin (if using Cloud Run)
roles/project.editor

Create a service account (e.g., svc-bq-focus)

Assign the following roles to your service account:

roles/bigquery.dataOwner
roles/storage.objectAdmin
roles/cloudfunctions.invoker
roles/cloudscheduler.admin
roles/serviceAccount.tokenCreator
roles/run.admin

Your default compute service account will also require access to run cloud build services. Ensure you apply the cloud build role to your default compute service account in your project, it may look like this:

projectID-compute@developer.gserviceaccount.com

→ roles/cloudbuild.builds.builder

Create FOCUS data structure and View

This section will create two new tables in Big Query, one for service category mappings and one for metadata related to export times. These are important to get in before we create the FOCUS view to extract billing data in FOCUS format.

Create a service category mapping table

I removed service category from the original google FOCUS view to reduce the size of the SQL Query, therefore, to ensure we mapped Service category properly, I created a new service category table and joined it to the FOCUS view.

In this step we will create a new table using open data to map GCP services to service category. Doing this helps reduce the size of the SQL query and simplifies management of Service Category mapping. Leveraging open source data we can easily update service category mappings if they ever change or new categories are added without impacting the FOCUS view query.

Process:

Download the latest service_category_mapping.csv from the FOCUS Converter repo
Go to BigQuery > Your Dataset > Create Table
Upload the CSV
Table name: service_category
Schema: Auto-detect

Create a metadata table

This table will be used to track the last time detailed billing data was added to your detailed billing export, we use this to enable incremental exports of billing data through the FOCUS view to ensure we only export the latest set of data and not everything all the time.

Process:

Go to BigQuery > Create Table
Table name: metadata_focus_export
Schema:
Field Name : Format last_export_time: TIMESTAMP export_message: STRING Enter your field name and then choose field format, do not add :

🔊 “Ensures each export only includes new data since the last timestamp.”

Create the FOCUS-aligned view

Creating a view in BigQuery allows us to un-nest the detailed billing export tables into the format of FOCUS 1.0*. To use Power BI we must un-nest the tables so this step is required. It also ensures we map the right columns in Google Cloud detailed billing export to the right columns in FOCUS.

⚠️ The FOCUS SQL code provided in this walk-through has been altered from the original Google provided code. I believe this new code is better formatted for FOCUS 1.0 than the original however it does contain some nuances that suit my personal views. Please evaluate this carefully before using this in a production system and adjust the code accordingly to your needs.

Steps:

Navigate to BigQuery > New Query
Paste and update the FOCUS view SQL query which is provided below
Replace:
- yourexporttable with detailed export dataset ID and table name that will look like "
- yourpricingexporttable with pricing export and table name
- your_billing_dataset with your detailed export dataset ID and table name
FOCUS SQL Query:

WITH usage_export AS ( SELECT *, ( SELECT AS STRUCT type, id, full_name, amount, name FROM UNNEST(credits) LIMIT 1 ) AS cud, FROM "Your-Detailed-Billing-Export-ID" -- replace with your detailed usage export table path ), prices AS ( SELECT export_time, sku.id AS sku_id, sku.description AS sku_description, service.id AS service_id, service.description AS service_description, tier.* FROM "your_pricing_export_id", UNNEST(list_price.tiered_rates) AS tier ) SELECT "111111-222222-333333" AS BillingAccountId, "Your Company Name" AS BillingAccountName, COALESCE((SELECT SUM(x.amount) FROM UNNEST(usage_export.credits) x),0) + cost as BilledCost, usage_export.currency AS BillingCurrency, DATETIME(PARSE_DATE("%Y%m", invoice.month)) AS BillingPeriodStart, DATETIME(DATE_SUB(DATE_ADD(PARSE_DATE("%Y%m", invoice.month), INTERVAL 1 MONTH), INTERVAL 1 DAY)) AS BillingPeriodEnd, CASE WHEN usage_export.adjustment_info.type IS NOT NULL and usage_export.adjustment_info.type !='' THEN 'Adjustment' WHEN usage_export.cud.type = 'PROMOTION' AND usage_export.cost_type = 'regular' AND usage_export.cud.id IS NOT NULL THEN 'Credit' WHEN usage_export.sku.description LIKE '%Commitment - 3 years - dollar based VCF%' or usage_export.sku.description LIKE '%Prepay Commitment%' THEN 'Purchase' WHEN usage_export.cud.id IS NOT NULL AND usage_export.cud.id != '' THEN 'Credit' WHEN usage_export.cost_type = 'regular' THEN 'Usage' WHEN usage_export.cost_type = 'tax' THEN 'Tax' WHEN usage_export.cost_type = 'adjustment' THEN 'Adjustment' WHEN usage_export.cost_type = 'rounding_error' THEN 'Adjustment' ELSE usage_export.cost_type END AS ChargeCategory, IF(COALESCE( usage_export.adjustment_info.id, usage_export.adjustment_info.description, usage_export.adjustment_info.type, usage_export.adjustment_info.mode) IS NOT NULL, "correction", NULL) AS ChargeClass, CASE WHEN usage_export.adjustment_info.type IS NOT NULL AND usage_export.adjustment_info.type != '' THEN usage_export.adjustment_info.type ELSE usage_export.sku.description END AS ChargeDescription, CAST(usage_export.usage_start_time AS DATETIME) AS ChargePeriodStart, CAST(usage_export.usage_end_time AS DATETIME) AS ChargePeriodEnd, CASE usage_export.cud.type WHEN "COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE" THEN "Spend" WHEN "COMMITTED_USAGE_DISCOUNT" THEN "Usage" END AS CommitmentDiscountCategory, usage_export.cud.id AS CommitmentDiscountId, COALESCE (usage_export.cud.full_name, usage_export.cud.name) AS CommitmentDiscountName, usage_export.cud.type AS CommitmentDiscountType, CAST(usage_export.usage.amount_in_pricing_units AS numeric) AS ConsumedQuantity, usage_export.usage.pricing_unit AS ConsumedUnit, -- review CAST( CASE WHEN usage_export.cost_type = "regular" THEN usage_export.price.effective_price * usage_export.price.pricing_unit_quantity ELSE 0 END AS NUMERIC ) AS ContractedCost, -- CAST(usage_export.price.effective_price AS numeric) AS ContractedUnitPrice, usage_export.seller_name AS InvoiceIssuerName, COALESCE((SELECT SUM(x.amount) FROM UNNEST(usage_export.credits) x),0) + cost as EffectiveCost, CAST(usage_export.cost_at_list AS numeric) AS ListCost, prices.account_currency_amount AS ListUnitPrice, IF( usage_export.cost_type = "regular", IF( LOWER(usage_export.sku.description) LIKE "commitment%" OR usage_export.cud IS NOT NULL, "committed", "standard"), null) AS PricingCategory, IF(usage_export.cost_type = 'regular', usage_export.price.pricing_unit_quantity, NULL) AS PricingQuantity, IF(usage_export.cost_type = 'regular', usage_export.price.unit, NULL) AS PricingUnit, 'Google'AS ProviderName, usage_export.transaction_type AS PublisherName, usage_export.location.region AS RegionId, usage_export.location.region AS RegionName, usage_export.service.id AS ResourceId, REGEXP_EXTRACT (usage_export.resource.global_name, r'[^/]+$') AS ResourceName, usage_export.sku.description AS ResourceType, COALESCE(servicemapping.string_field_1, 'Other') AS ServiceCategory, usage_export.service.description AS ServiceName, usage_export.sku.id AS SkuId, CONCAT("SKU ID:", usage_export.sku.id, ", Price Tier Start Amount: ", price.tier_start_amount) AS SkuPriceId, usage_export.project.id AS SubAccountId, usage_export.project.name AS SubAccountName, (SELECT CONCAT('{', STRING_AGG(FORMAT('%s:%s', kv.key, kv.value), ', '), '}') FROM ( SELECT key, value FROM UNNEST(usage_export.project.labels) UNION ALL SELECT key, value FROM UNNEST(usage_export.tags) UNION ALL SELECT key, value FROM UNNEST(usage_export.labels) ) AS kv) AS Tags, FORMAT_DATE('%B', PARSE_DATE('%Y%m', invoice.month)) AS Month, usage_export.project.name AS x_ResourceGroupName, CAST(usage_export.export_time AS TIMESTAMP) AS export_time, FROM usage_export LEFT JOIN "Your-Service-Category-Id".ServiceCategory AS servicemapping ON usage_export.service.description = servicemapping.string_field_0 LEFT JOIN prices ON usage_export.sku.id = prices.sku_id AND usage_export.price.tier_start_amount = prices.start_usage_amount AND DATE(usage_export.export_time) = DATE(prices.export_time);

🔊 "This creates a FOCUS-aligned view of your billing data using FOCUS 1.0 specification, this view does not 100% conform to FOCUS 1.0.

Create GCS Bucket for CSV Exports

Your GCS bucket is where you will place your incremental exports to be exported to Azure. Once your data is exported to Azure you may elect to delete the files in the bucket, the metaata table keeps a record of the last export time.

Steps:

Go to Cloud Storage > Create Bucket
Name: focus-cost-export (or any name you would like)
Region: Match your dataset region
Storage Class: Nearline (cheaper to use Earline but standard will also work just fine)
Enable Interoperability settings > create access/secret key
- The access key and secret are tied to your user account, if you want to be able to use this with multiple people, create an access key for your service account - recommended for Prod, for this guide purpose, an access key linked to your account is fine.
Save the access key and secret to a secure location to use later as part of the ADF pipeline setup.

🔊 “This bucket will store daily CSVs. Consider enabling lifecycle cleanup policies.”

Create a Cloud Function for incremental export

A cloud function is used here to enable incremental exports of your billing data in FOCUS format on a regular schedule. At present there is no known supported on demand export service from Google, so we came up with this little workaround.

The function is designed to evaluate your billing data for last export time that is equals to or greater than the last time the function ran. To do this we look at the export_time column and the metadata table for the last time we ran this. This ensure we only export the most recent billing data which aids in reducing data export costs to Azure.

This process is done through the GCP GUI using an inline editor to create the cloud function in the cloud run service.

Steps:

Go to Cloud Run > Write Function
Select > Use Inline editor to create a function
Service Name: daily_focus_export
Region, the same region as your dataset - in our demo case us-central1
Use settings:
- Runtime: Python 3.11 (you cannot use anything later than 3.11)
- Trigger: Optional
- Authentication: Require Authentication
- Billing: Request based
- Service Scaling: Auto-scaling set to 0
- Ingress: All
- Containers: leave all settings as set
- Volumes: Leave all settings as set
- Networking: Leave all settings as set
- Security: Choose the service account you created earlier
- Save
Create main.py file and requirements.txt files through the inline editor
- For requirements.txt copy and paste the below:
  - functions-framework==3.*
  - google-cloud-bigquery
  - Google-cloud-storage
- For main.py your function entry point is: export_focus_data
Paste the code below into your main.py inline editor window

import logging import time import json from google.cloud import bigquery, storage logging.basicConfig(level=logging.INFO) def export_focus_data(request): bq_client = bigquery.Client() storage_client = storage.Client() project_id = "YOUR-ProjectID" dataset = "YOUR-Detailed-Export-Dataset" view = "YOUR-FOCUS-View-Name" metadata_table = "Your-Metadata-Table" job_name = "The name you want to call the job for the export" bucket_base = "gs://<your bucketname>/<your foldername>" bucket_name = "Your Bucket Name" metadata_file_path = "Your-Bucket-name/export_metadata.json" try: logging.info("🔁 Starting incremental export based on export_time...") # Step 1: Get last export_time from metadata metadata_query = f""" SELECT last_export_time FROM `{project_id}.{dataset}.{metadata_table}` WHERE job_name = '{job_name}' LIMIT 1 """ metadata_result = list(bq_client.query(metadata_query).result()) if not metadata_result: return "No metadata row found. Please seed export_metadata.", 400 last_export_time = metadata_result[0].last_export_time logging.info(f"📌 Last export_time from metadata: {last_export_time}") # Step 2: Check for new data check_data_query = f""" SELECT COUNT(*) AS row_count FROM `{project_id}.{dataset}.{view}` WHERE export_time >= TIMESTAMP('{last_export_time}') """ row_count = list(bq_client.query(check_data_query).result())[0].row_count if row_count == 0: logging.info("✅ No new data to export.") return "No new data to export.", 204 # Step 3: Get distinct export months folder_query = f""" SELECT DISTINCT FORMAT_DATETIME('%Y%m', BillingPeriodStart) AS export_month FROM `{project_id}.{dataset}.{view}` WHERE export_time >= TIMESTAMP('{last_export_time}') AND BillingPeriodStart IS NOT NULL """ export_months = [row.export_month for row in bq_client.query(folder_query).result()] logging.info(f"📁 Exporting rows from months: {export_months}") # Step 4: Export data for each month for export_month in export_months: export_path = f"{bucket_base}/{export_month}/export_{int(time.time())}_*.csv" export_query = f""" EXPORT DATA OPTIONS( uri='{export_path}', format='CSV', overwrite=true, header=true, field_delimiter=';' ) AS SELECT * FROM `{project_id}.{dataset}.{view}` WHERE export_time >= TIMESTAMP('{last_export_time}') AND FORMAT_DATETIME('%Y%m', BillingPeriodStart) = '{export_month}' """ bq_client.query(export_query).result() # Step 5: Get latest export_time from exported rows max_export_time_query = f""" SELECT MAX(export_time) AS new_export_time FROM `{project_id}.{dataset}.{view}` WHERE export_time >= TIMESTAMP('{last_export_time}') """ new_export_time = list(bq_client.query(max_export_time_query).result())[0].new_export_time # Step 6: Update BigQuery metadata table update_query = f""" MERGE `{project_id}.{dataset}.{metadata_table}` T USING ( SELECT '{job_name}' AS job_name, TIMESTAMP('{new_export_time}') AS new_export_time ) S ON T.job_name = S.job_name WHEN MATCHED THEN UPDATE SET last_export_time = S.new_export_time WHEN NOT MATCHED THEN INSERT (job_name, last_export_time) VALUES (S.job_name, S.new_export_time) """ bq_client.query(update_query).result() # Step 7: Write metadata JSON to GCS blob = storage_client.bucket(bucket_name).blob(metadata_file_path) blob.upload_from_string( json.dumps({"last_export_time": new_export_time.isoformat()}), content_type="application/json" ) logging.info(f"📄 Metadata file written to GCS: gs://{bucket_name}/{metadata_file_path}") return f"✅ Export complete. Metadata updated to {new_export_time}", 200 except Exception as e: logging.exception("❌ Incremental export failed:") return f"Function failed: {str(e)}", 500

Before saving, update variables like project_id, bucket_name, etc.

🔊 “This function exports new billing data based on the last timestamp in your metadata table.”

Test the Cloud Function

Deploy and click Test Function
Ensure a seed export_metadata.json file is uploaded to your GCS bucket (if you have not uploaded a seed export file the function will not run. Example file is below
- { "last_export_time": "2024-12-31T23:59:59.000000+00:00" }
Confirm new CSVs appear in your target folder

Automate with Cloud Scheduler

This step will set up an automated schedule to run your cloud function on a daily or hourly pattern, you may adjust the frequency to your desired schedule, this demo uses the same time each day at 11pm.

Steps:

Go to Cloud Scheduler > Create Job
Region: Same region as your Function - This Demo us-central1
Name: daily-focus-export
Frequency: 0 */6 * * * (every 6 hours) or Frequency: 0 23 * * * (daily at 11 PM)
Time zone: your desired time zone
Target: HTTP
Auth: OIDC Token → Use service account
Click CREATE

🔊 "This step automates the entire pipeline to run daily and keep downstream platforms updated with the latest billing data."

Wrapping up Google setup

Wow—there was a lot to get through! But now that you’ve successfully enabled FOCUS-formatted exports in Google Cloud, you're ready for the next step: connecting Azure to your Google Cloud Storage bucket and ingesting the data into your FinOps hub instance.

This is where everything comes together—enabling unified, multi-cloud reporting in your Hub across both Azure and Google Cloud billing data.

Let’s dive into building the Data Factory pipeline and the associated datasets needed to fetch, transform, and load your Google billing exports.

Connecting Azure to Google billing data

With your Google Cloud billing data now exporting in FOCUS format, the next step is to bring it into your Azure environment for centralized FinOps reporting. Using Data Factory, we'll build a pipeline to fetch the CSVs from your Google Cloud Storage bucket, convert them to Parquet, and land them in your FinOps Hub storage account.

Azure access and prerequisites

Access to the Azure Portal
Access to the resource group your hub has been deployed to
Contributor access to your resource group
At a minimum storage account contributor and storage blob data owner roles
An existing deployment of the Microsoft FinOps Hub Toolkit
Admin rights on Azure Data Factory (or at least contributor role on ADF)

Services and tools required

Make sure the following Azure resources are in place:

Azure Data Factory instance
A linked Azure Storage Account (this is where FinOps Hub is expecting data)
(Optional) Azure Key Vault for secret management

Pipeline Overview

We’ll be creating the following components in Azure Data Factory

Component	Purpose
GCS Linked Service	Connects ADF to your Google Cloud Storage bucket
Azure Blob Linked Service	Connects ADF to your Hub’s ingestion container
Source Dataset	Reads CSV files from GCS
Sink Dataset	Writes Parquet files to Azure Data Lake (or Blob) in Hub's expected format
Pipeline Logic	Orchestrates the copy activity, format conversion, and metadata updates

Secrets and authentication

To connect securely from ADF to GCS, you will need:

The access key and secret from GCS Interoperability settings (created earlier)
Store them securely in Azure Key Vault or in ADF pipeline parameters (if short-lived)

💡 Best Practice Tip:

Use Azure Key Vault to securely store GCS access credentials and reference them from ADF linked services. This improves security and manageability over hardcoding values in JSON.

Create Google Cloud storage billing data dataset

Now that we're in Azure, it's time to connect to your Google Cloud Storage bucket and begin building your Azure Data Factory pipeline.

Steps

Launch Azure Data Factory
Log in to the Azure Portal
Navigate to your deployed Azure Data Factory instance
Click “Author” from the left-hand menu to open the pipeline editor
In the ADF Author pane, click the "+" (plus) icon next to Datasets
Select “New dataset”
Choose Google Cloud Storage as the data source
Select CSV as the file format
Set the Dataset Name, for example:
gcs_focus_export_dataset
Click “+ New” next to the Linked Service dropdown
Enter a name like:
GCS-Billing-LinkedService
Under Authentication Type, choose:
Access Key (for Interoperability access key)
Or Azure Key Vault (recommended for secure credential storage)
Fill in the following fields:
Access Key: Your GCS interoperability key
Secret: Your GCS interoperability secret
Bucket Name: focus-cost-export
(Optional) Point to a folder path like: focus-billing-data/
Click Test Connection to validate access
Click Create
Adjust Dataset Properties

Now that the dataset has been created, make the following modifications to ensure proper parsing of the CSVs:

SettingValue

Column delimiter; (semicolon)
Escape character" (double quote)

You can find these under the “Connection” and “Schema” tabs of the dataset editor.

If your connection fails you may need to enable public access on your GCS bucket or check your firewall restrictions from azure to the internet!

Create a Google Cloud Storage metadata dataset

To support incremental loading, we need a dedicated dataset to read the export_metadata.json file that your Cloud Function writes to Google Cloud Storage. This dataset will be used by the Lookup activity in your pipeline to get the latest export timestamp from Google.

Steps:

In the Author pane of ADF, click "+" > Dataset > New dataset
Select Google Cloud Storage as the source
Choose JSON as the format
Click Continue
Configure the Dataset

Setting	Value
Name	gcs_export_metadata_dataset
Linked Service	Use your existing GCS linked service
File path	e.g., focus-cost-export/metadata/export_metadata.json
Import schema	Set to From connection/store or manually define if needed
File pattern	Set to single file (not folder)

Create the sink dataset – "ingestion_gcp"

Now that we’ve connected to Google Cloud Storage and defined the source dataset, it’s time to create the sink dataset. This will land your transformed billing data in Parquet format into your Azure FinOps Hub’s ingestion container.

Steps:

In Azure Data Factory, go to the Author section
Under Datasets, click the "+" (plus) icon and select “New dataset”
Choose Azure Data Lake Storage Gen2 (or Blob Storage, depending on your Hub setup)
Select Parquet as the file format
Click Continue

Configure dataset properties

Name: ingestion_gcp
Linked Service:
Select your existing linked service that connects to your FinOps Hub’s storage account. (this will have been created when you deployed the hub)
File path:
Point to the container and folder path where you want to store the ingested files (e.g., ingestion-gcp/cost/billing-provider/gcp/focus/)

Optional Settings:

Option	Recommended Value
Compression type	snappy

Once configured, click Publish All again to save your new sink dataset.

Create the sink dataset – "adls_last_import_metadata"

The adls_last_import_metadata dataset (sinks dataset) is the location you use to copy the export time json file from google to azure, this location is sued for the pipeline to check the last time the import of data was run by reading the json file you coped from google and comparing it to the new json file from google

Steps:

In Azure Data Factory, go to the Author section
Under Datasets, click the "+" (plus) icon and select “New dataset”
Choose Azure Data Lake Storage Gen2 (or Blob Storage, depending on your Hub setup)
Select JSON as the file format
Click Continue

Configure dataset properties

Name: adsl_last_import_metadata
Linked Service:
Select your existing linked service that connects to your FinOps Hub’s storage account. (this will have been created when you deployed the hub)
File path:
Point to the container and folder path where you want to store the ingested files (e.g., ingestion/cost/metadata)

Build the ADF pipeline for incremental import

With your datasets created, the final step is building the pipeline logic that orchestrates the data flow. The goal is to only import newly exported billing data from Google, avoiding duplicates by comparing timestamps from both clouds.

In this pipeline, we’ll:

Fetch Google’s export timestamp from the JSON metadata file
Fetch the last successful import time from the Hub’s metadata file in Azure
Compare timestamps to determine whether there is new data to ingest
If new data exists:
- Run the Copy Activity to fetch GCS CSVs, convert to Parquet, and write to the ingestion_gcp container
- Write an updated metadata file in the hub, with the latest import timestamp

Pipeline components:

Activity	Purpose
Lookup - GCS Metadata	Reads the last export time from Google's metadata JSON in GCS
Lookup - Hub Metadata	Reads the last import time from Azure’s metadata JSON in ADLS
If Condition	Compares timestamps to decide whether to continue with copy
Copy Data	Transfers files from GCS (CSV) to ADLS (Parquet)
Set Variable	Captures the latest import timestamp
Web/Copy Activity	Writes updated import timestamp JSON file to ingestion_gcp container

What your pipeline will look like:

Step-by-Step

Create two lookup activities:
- GCS Metadata
- Hub Metadata

Lookup1 – GCS Metadata

Add an activity called Lookup to your new pipeline
Select the Source Dataset: gcs_export_metadata_dataset or whatever you named it earlier

This lookup reads the the export_metadata.json file created by your Cloud Function in GCS for the last export time available.

Configuration view of lookup for GCS metadata file

Lookup2 – Hub Metadata

Add an activity called lookup and name it Hub Metadata
Select the source dataset: adls_last_import_metadata

This lookup reads the last import time data from the hub metadata file to compare it to the last export time from GCS

Configuration view of Metadata lookup activity

Add conditional logic

In this step we will add the condition logic

Add activity called If Condition
Add the expression below to the condition

Go to the Expression tab and paste the following into Dynamic Content:

@greater(activity('Lookup1').output.last_export_time, activity('Lookup2').output.last_import_time)

Configuration view of If Condition Activity

Add Copy Activity (If Condition = True)
next to True condition select edit and add activity Copy Data
Configure the activity with the following details

Setting	Value
Source Dataset	gcs_focus_export_dataset (CSV from GCS)
Sink Dataset	ingestion_gcp (Parquet to ADLS)
Merge Files	Enabled (reduce file count)
Filter Expression	@activity('Lookup1').output.firstRow.last_export_time

Ensure you add filter expression for filter by last modified. This is important, if you do not add the filter by last modified expression your pipeline will not function properly.

Finally we create an activity to update the metadata file in the hub

Add another copy activity to your if condition and ensure it is linked to the previous copy activity, this ensure it runs after the import activity is completed.

Copy metadata activity settings:

Source	gcs_export_metadata_dataset
Sink	adls_last_import_dataset
Destination Path	ingestion_gcp/metadata/last_import.json

This step ensures the next run of your pipeline uses the updated import time to decide whether new data exists.

Your pipeline now ingests only new billing data from Google and records each successful import to prevent duplicate processing.

Wrapping up – A unified FinOps reporting solution

Congratulations — you’ve just built a fully functional multi-cloud FinOps data pipeline using Microsoft’s FinOps Hub Toolkit and Google Cloud billing data, normalized with the FOCUS 1.0 standard.

By following this guide, you’ve:

✅ Enabled FOCUS billing exports in Google Cloud using BigQuery, GCS, and Cloud Functions

✅ Created normalized, FOCUS-aligned views to unify your GCP billing data

✅ Automated metadata tracking to support incremental exports

✅ Built an Azure Data Factory pipeline to fetch, transform, and ingest GCP data into your Hub

✅ Established a reliable foundation for centralized, multi-cloud cost reporting

This solution brings side-by-side visibility into Azure and Google Cloud costs, enabling informed decision-making, workload optimization, and true multi-cloud FinOps maturity.

Next steps

🔁 Schedule the ADF pipeline to run daily or hourly using triggers
📈 Build Power BI dashboards or use templates from the Microsoft FinOps Toolkit visualise unified cloud spend
🧠 Extend to AWS by applying the same principles using the AWS FOCUS export and AWS S3 storage

Feedback?

Have questions or want to see more deep dives like this? Let me know — or connect with me if you’re working on FinOps, FOCUS, or multi-cloud reporting. This blog is just the beginning of what's possible.

EA to MCA: Reporting on cost in Power BI

micflan — Sun, 06 Jul 2025 20:21:11 GMT

Microsoft offers several ways to analyze and report on your cloud costs. For quick exploration of subscriptions and billing accounts, start with smart views in Cost analysis in the Azure portal or Microsoft 365 admin center. When you need more control or to save and share charts, switch to customizable views. But what should you do when you need to build out more advanced, interactive reports or need to share reports with business and finance stakeholders? This is where Power BI comes in, especially since many organizations are already leveraging Power BI for business and financial reporting outside of cloud costs.

Cost Management connector for Power BI

The Cost Management app for Power BI has always been a popular option for organizations with an Enterprise Agreement (EA) enrollment. But the app was designed exclusively for EA enrollments and doesn’t support Microsoft Customer Agreement (MCA) accounts. This left many organizations with no other option than to create new reports from scratch using the Cost Management connector for Power BI. But this presents a few challenges:

The connector uses outdated APIs that don’t include all details.
The underlying datasets use different column names than EA data, so the same reports can’t be used.
The connector can only handle up to around $2-5 million in total monitored spend.
The connector doesn’t support connecting to multiple billing accounts, so there’s no way to view historical costs after an EA renewal or MCA migration.

The latest recommendation from the Cost Management team is to export data to a storage account and use the Azure Data Lake Storage Gen2 connector or Microsoft Fabric to pull data into Power BI reports. This approach ensures your reports will have the latest complete data in a more scalable way. But the problem here is that you have to start from scratch with a new, empty report. This is where the FinOps toolkit comes in.

Power BI reports for Cost Management exports

Based on the direction from the Cost Management team, the FinOps toolkit provides a set of reports that connect to exported data from Cost Management. Simply export your data, download the reports, and point them at your storage account. It’s that simple. And the great news is, these reports:

Use the latest data in the FinOps Open Cost and Usage Specification (FOCUS) format, which includes all available details about your cost and usage.
Use a single set of columns for both EA and MCA billing accounts.
Support connecting to multiple billing accounts and even subscriptions.

The FinOps toolkit includes 5 reports:

Cost summary – Track cost over time and get a general overview of cost and savings with common breakdowns to get you started.
Rate optimization – Review cost savings from negotiated and commitment discounts and identify opportunities to increase savings.
Policy + governance – Summarize your governance posture with standard metrics aligned with the Cloud Adoption Framework.
Workload optimization – Gain insights into resource utilization and efficiency opportunities based on historical usage patterns.
Data ingestion – Review FinOps hubs cost and monitor Cost Management exports to identify and resolve common issues.

The Cost summary and Rate optimization reports are based on the EA template app, so if you’re familiar with that, you should feel right at home. A lot has been added, so you’ll also find some welcome additions.

Getting started with FinOps toolkit reports

FinOps toolkit Power BI reports support a few deployment options, from raw Cost Management exports in Azure Data Lake Storage (ADLS) to data processed and ingested into storage, Azure Data Explorer, or Microsoft Fabric via the FinOps hubs orchestration engine. For today, we’ll focus exclusively on raw Cost Management exports in storage.

Step 1. Create an Azure Data Lake Storage Gen2 storage account

FinOps toolkit reports use ADLS for improved performance and load times. When creating a new storage account, select Premium performance and Block Blobs redundancy, then select Enable hierarchical namespace on the Advanced tab.

Make note of the subscription and storage account name. You’ll need those in the next step.

To learn more, see Create a storage account for Azure Data Lake Storage.

Step 2. Create Cost Management exports

Next, let’s create exports.

Open Cost Management in the Azure portal.
Select Reporting + analytics > Exports, and then select + Create.
In the export wizard, select the All costs (FOCUS) + prices template.
Select Next.
Specify the subscription and storage account from step 1.
Specify the desired container and directory path.
Specify Parquet format with Snappy compression and overwrite data to avoid data duplication with raw exports.
- CSV with or without Gzip compression will also work but may impact data refresh performance.
Select Next.
Confirm the configured settings and select Create.

With cost and price exports created, now create reservation recommendation exports. One important note about reservation recommendation exports is that each export can only cover one reservation scope, one service, and one lookback period. If you want to collect shared and scoped recommendations, or recommendations from multiple services, or recommendations for different lookback periods, you will need to create multiple exports. You can create up to 10 exports in the new export wizard. To create more, run thru the wizard for the remaining datasets. I recommend creating shared and single scoped recommendations for each service you use.

Select + Create at the top of the page.
Select the Create your own export template.
Select + Add export,
Select the Reservation recommendations type, specify each of the available options, and select Add.
Repeat 3 and 4 for each desired reservation recommendation dataset.
Select Next.
Specify the same destination settings from the cost and price exports above, then select Next.
Confirm the configured settings and select Create.

Repeat 1-8 for any additional datasets.

Normally, exports will run within 24 hours. Select the checkboxes for each of the new exports, then select the Run now command at the top of the page.

After you configure exports for your current scope, use the scope picker at the top of the page to select any additional scopes you’re interested in. If you recently transitioned from EA to MCA or even had an EA renewal in the last 7 years, you can create cost and price exports on those older billing accounts. And of course, if you’re managing multiple subscriptions, you can do the same for each subscription. Note that price and reservation exports are only available for EA billing accounts and MCA billing profiles.

To learn more, see Create and manage Cost Management exports.

Step 3. Connect Power BI reports to storage

The FinOps toolkit includes a set of demo reports with sample data and report templates that you can open in Power BI Desktop. If you don’t already have Power BI Desktop, you can learn more and download it from the Power BI Desktop page.

Before we setup each report, let’s get the storage account URL. The URL consists of 3 parts:

{dfs-endpoint}/{container}/{optional-folder-path}

To get the DFS endpoint, open the desired storage account in the Azure portal, select Settings > Endpoints in the menu, and copy the Data Lake Storage URL.

Replace “{container}” with the container name specified in the exports and, if you used a common storage path across all exports and scopes, replace the “{optional-folder-path}” with the common part of the storage path. Don’t include scope-specific folders if you intend to report on multiple scopes. If you need to change any export container or storage path values, re-run the export to ensure it lands in the correct place.

Next, download the latest demo reports (PBIX files) or report templates (PBIT files), extract the ZIP, and open the desired files in Power BI Desktop. I recommend starting with Cost summary and Rate optimization. (If you opted to download demo reports, you can also upload these directly to any Microsoft Fabric or Power BI workspace.)

If you downloaded the demo reports, you can explore the pages with demo data freely without connecting to a storage account. (Although, these reports have limited data.) When you’re ready to connect to your data, select Transform data > Edit parameters.

If you downloaded the templates, you’ll see a dialog pop up requesting the needed parameters.

Set Storage URL to the Data Lake Storage (DFS) URL we captured earlier and Number of Months to the number of closed months you’d like to see in the report. You can leave the rest of the values with their default values.

If you exported prices and want to see missing prices be populated for reservation usage, select the Experimental: Add Missing Prices parameter. Please note this option joins the cost and price data and may severely impact data refresh performance. If you experience performance issues, please switch to using FinOps hubs with Data Explorer or Microsoft Fabric.

The Default Granularity option specifies whether you would like most reports to be summarized at a usage or monthly level.

If using a template, select Load and your report should start to ingest data from the storage account. If using a demo report, select OK and then select the Apply button in the banner. Data load times can take anywhere from minutes to hours, depending on how much data you have. You can publish the report to the Power BI service using the Home > Publish command in Power BI Desktop (or by saving the report and manually uploading the PBIX file). Once uploaded, open the Power BI workspace in a web browser, locate the semantic model for the report, and select the Schedule refresh icon to configure the report to automatically update every month.

Repeat this process for each report using the same parameter values.

Note that Power BI has certain limits and guardrails that may constrain the amount of data you can ingest from storage. The amount of data will also impact data refresh performance. Depending on your license and services you use, Power BI reports can load around $1-5 million worth of spend per month with incremental refresh configured; however, loading this much data can take hours to ingest.

If you experience errors or delays in the data refresh, we recommend using FinOps hubs with Data Explorer or Microsoft Fabric. FinOps hubs offer massively improved performance and powerful new capabilities for organizations who need to monitor over $100K in total cost.

Step 4. Populate historical data

Once you have reports up and running, you should think about how much historical data you want to report on. Many organizations start with 13 months, but some are interested in longer, year-over-year reporting. Just remember the constraints of loading no more than $1-5 million in spend per month with scheduled refresh configured. If you do not set up incremental refresh, you will only be able to load a total of $1-5 million in spend.

You can populate historical data in the portal or via PowerShell. If you have multiple scopes or want to populate data from more than a few months, PowerShell can save time.

To run exports from the portal, open each export in Cost Management and select the Export selected dates command at the top of the flyout. Specify the start and end date for one month and select Execute. Repeat this for each month and each export for each scope.

To run exports from PowerShell, you can use either PowerShell 7 or Azure Cloud Shell. Refer to Install the FinOpsToolkit PowerShell module for initial setup instructions.

Once the FinOpsToolkit module is installed, run the following command for each exports and each scope. You can copy the billing account and billing profile IDs from the Properties page for each scope in the Azure portal. (This is under Settings > Configuration in Cost Management.)

Start-FinOpsCostExport ` -Scope '/providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###' ` -Name '{export-name}' ` -Backfill 13 # or desired number of months

This command will kick off one export for each month in the specified date range (number of -Backfill months) and will pause for API throttling. Once complete, you can run the command again for the next export or next scope.

Each export can take 15 minutes or more, depending on the size of the account. Once all exports have completed, your reports should automatically update after your next scheduled refresh. You can also manually refresh the report in Power BI Desktop or the semantic model in your Power BI workspace.

To learn more about this command, see Start-FinOpsCostExport.

Summary and next steps

By now, you should have reports setup and populated with at least one month of data and additional months being actively populated. These reports are intended to help you get started on your FinOps journey, so please do think about how you can improve and augment them to meet your needs. Power BI is a powerful platform that allows you to bring in your own data and visualize that in various ways. The FinOps toolkit reports are just the beginning!

If you have any questions, post them in the FinOps toolkit discussion forum. If you have specific feedback about ways to improve the reports, PowerShell, or even a new idea, create a new feature request. The FinOps toolkit community is here to help!

Next, I’ll dig into FinOps hubs, which offer improved performance and additional capabilities for organizations looking to do more with their data.

Managing Azure OpenAI costs with the FinOps toolkit and FOCUS: Turning tokens into unit economics

robbdi — Wed, 21 May 2025 10:00:00 GMT

By Robb Dilallo

Introduction

As organizations rapidly adopt generative AI, Azure OpenAI usage is growing—and so are the complexities of managing its costs. Unlike traditional cloud services billed per compute hour or storage GB, Azure OpenAI charges based on token usage.

For FinOps practitioners, this introduces a new frontier: understanding AI unit economics and managing costs where the consumed unit is a token.

This article explains how to leverage the Microsoft FinOps toolkit and the FinOps Open Cost and Usage Specification (FOCUS) to gain visibility, allocate costs, and calculate unit economics for Azure OpenAI workloads.

Why Azure OpenAI cost management is different

AI services break many traditional cost management assumptions:

Billed by token usage (input + output tokens).
Model choices matter (e.g., GPT-3.5 vs. GPT-4 Turbo vs. GPT-4o).
Prompt engineering impacts cost (longer context = more tokens).
Bursty usage patterns complicate forecasting.

Without proper visibility and unit cost tracking, it's difficult to optimize spend or align costs to business value.

Step 1: Get visibility with the FinOps toolkit

The Microsoft FinOps toolkit provides pre-built modules and patterns for analyzing Azure cost data.

Key tools include:

Microsoft Cost Management exports
Export daily usage and cost data in a FOCUS-aligned format.
FinOps hubs
Infrastructure-as-Code solution to ingest, transform, and serve cost data.
Power BI templates
Pre-built reports conformed to FOCUS for easy analysis.

Pro tip:
Start by connecting your Microsoft Cost Management exports to a FinOps hub. Then, use the toolkit’s Power BI FOCUS templates to begin reporting.

Learn more about the FinOps toolkit

Step 2: Normalize data with FOCUS

The FinOps Open Cost and Usage Specification (FOCUS) standardizes billing data across providers—including Azure OpenAI.

FOCUS Column	Purpose	Azure Cost Management Field
ServiceName	Cloud service (e.g., Azure OpenAI Service)	ServiceName
ConsumedQuantity	Number of tokens consumed	Quantity
PricingUnit	Unit type, should align to "tokens"	DistinctUnits
BilledCost	Actual cost billed	CostInBillingCurrency
ChargeCategory	Identifies consumption vs. reservation	ChargeType
ResourceId	Links to specific deployments or apps	ResourceId
Tags	Maps usage to teams, projects, or environments	Tags
UsageType / Usage Details	Further SKU-level detail	Sku Meter Subcategory, Sku Meter Name

Why it matters:
Azure’s native billing schema can vary across services and time. FOCUS ensures consistency and enables cross-cloud comparisons.

Tip: If you use custom deployment IDs or user metadata, apply them as tags to improve allocation and unit economics.

Review the FOCUS specification

Step 3: Calculate unit economics

Unit cost per token = BilledCost ÷ ConsumedQuantity

Real-world example: Calculating unit cost in Power BI

A recent Power BI report breaks down Azure OpenAI usage by:

SKU Meter Category → e.g., Azure OpenAI
SKU Meter Subcategory → e.g., gpt 4o 0513 Input global Tokens
SKU Meter Name → detailed SKU info (input/output, model version, etc.)

GPT Model	Usage Type	Effective Cost
gpt 4o 0513 Input global Tokens	Input	$292.77
gpt 4o 0513 Output global Tokens	Output	$23.40

Unit Cost Formula:
Unit Cost = EffectiveCost ÷ ConsumedQuantity

Power BI Measure Example:
Unit Cost = SUM(EffectiveCost) / SUM(ConsumedQuantity)

Pro tip:
Break out input and output token costs by model version to:

Track which workloads are driving spend.
Benchmark cost per token across GPT models.
Attribute costs back to teams or product features using Tags or ResourceId.

Power BI tip: Building a GPT cost breakdown matrix

To easily calculate token unit costs by GPT model and usage type, build a Matrix visual in Power BI using this hierarchy:

Rows:

SKU Meter Category
SKU Meter Subcategory
SKU Meter Name

Values:

EffectiveCost (sum)
ConsumedQuantity (sum)
Unit Cost (calculated measure)

Unit Cost = SUM(‘Costs’[EffectiveCost]) / SUM(‘Costs’[ConsumedQuantity])

Hierarchy Example:

Azure OpenAI

├── GPT 4o Input global Tokens

├── GPT 4o Output global Tokens

├── GPT 4.5 Input global Tokens

└── etc.

Power BI Matrix visual showing Azure OpenAI token usage and costs by SKU Meter Category, Subcategory, and Name. This breakdown enables calculation of unit cost per token across GPT models and usage types, supporting FinOps allocation and unit economics analysis.

What you can see at the token level

Metric	Description	Data Source
Token Volume	Total tokens consumed	Consumed Quantity
Effective Cost	Actual billed cost	BilledCost / Cost
Unit Cost per Token	Cost divided by token quantity	Effective Unit Price
SKU Category & Subcategory	Model, version, and token type (input/output)	Sku Meter Category, Subcategory, Meter Name
Resource Group / Business Unit	Logical or organizational grouping	Resource Group, Business Unit
Application	Application or workload responsible for usage	Application (tag)

This visibility allows teams to:

Benchmark cost efficiency across GPT models.
Track token costs over time.
Allocate AI costs to business units or features.
Detect usage anomalies and optimize workload design.

Tip: Apply consistent tagging (Cost Center, Application, Environment) to Azure OpenAI resources to enhance allocation and unit economics reporting.

How the FinOps Foundation’s AI working group informs this approach

The FinOps for AI overview, developed by the FinOps Foundation’s AI working group, highlights unique challenges in managing AI-related cloud costs, including:

Complex cost drivers (tokens, models, compute hours, data transfer).
Cross-functional collaboration between Finance, Engineering, and ML Ops teams.
The importance of tracking AI unit economics to connect spend with value.

By combining the FinOps toolkit, FOCUS-conformed data, and Power BI reporting, practitioners can implement many of the AI Working Group’s recommendations:

Establish token-level unit cost metrics.
Allocate costs to teams, models, and AI features.
Detect cost anomalies specific to AI usage patterns.
Improve forecasting accuracy despite AI workload variability.

Tip: Applying consistent tagging to AI workloads (model version, environment, business unit, and experiment ID) significantly improves cost allocation and reporting maturity.

Step 4: Allocate and Report Costs

With FOCUS + FinOps toolkit:

Allocate costs to teams, projects, or business units using Tags, ResourceId, or custom dimensions.
Showback/Chargeback AI usage costs to stakeholders.
Detect anomalies using the Toolkit’s patterns or integrate with Azure Monitor.

Tagging tip:
Add metadata to Azure OpenAI deployments for easier allocation and unit cost reporting. Example:

tags:

CostCenter: AI-Research

Environment: Production

Feature: Chatbot

Step 5: Iterate Using FinOps Best Practices

FinOps capability	Relevance
Reporting & analytics	Visualize token costs and trends
Allocation	Assign costs to teams or workloads
Unit economics	Track cost per token or business output
Forecasting	Predict future AI costs
Anomaly management	Identify unexpected usage spikes

Start small (Crawl), expand as you mature (Walk → Run).

Learn about the FinOps Framework

Next steps

Ready to take control of your Azure OpenAI costs?

Deploy the Microsoft FinOps toolkit
Start ingesting and analyzing your Azure billing data.
Get started
Adopt FOCUS
Normalize your cost data for clarity and cross-cloud consistency.
Explore FOCUS
Calculate AI unit economics
Track token consumption and unit costs using Power BI.
Customize Power BI reports
Extend toolkit templates to include token-based unit economics.
Join the conversation
Share insights or questions with the FinOps community on TechCommunity or in the FinOps Foundation Slack.
Advance Your Skills
Consider the FinOps Certified FOCUS Analyst certification.

Appendix: FOCUS column glossary

ConsumedQuantity: The number of tokens or units consumed for a given SKU. This is the key measure of usage.

ConsumedUnit: The type of unit being consumed, such as 'tokens', 'GB', or 'vCPU hours'. Often appears as 'Units' in Azure exports for OpenAI workloads.

PricingUnit: The unit of measure used for pricing. Should match 'ConsumedUnit', e.g., 'tokens'.

EffectiveCost: Final cost after amortization of reservations, discounts, and prepaid credits. Often derived from billing data.

BilledCost: The invoiced charge before applying commitment discounts or amortization.

PricingQuantity: The volume of usage after applying pricing rules such as tiered or block pricing. Used to calculate cost when multiplied by unit price.