Creating custom analyses and reports with FinOps hubs

The FinOps toolkit’s standard Power BI reports cover the scenarios most organizations start with: cost transparency, rate optimization, the rest of the FinOps Framework’s common ground. Sooner or later, most teams outgrow the predefined reports. They want to build their own analyses, extend reporting into new territory, or enrich FinOps data with data that lives somewhere else in the business.

That flexibility is already there. It sits in Azure Data Explorer (ADX), the engine underneath FinOps hubs.

What teams actually build with it

The custom work almost always falls into a handful of patterns: chargeback and showback models that refine cost allocation across business units and cost centers; deeper cost-visibility work to find idle or over-provisioned resources and quantify the effect of architecture changes; joining cost data to business metrics like cost per customer or cost per transaction; forecasting and budgeting off historical usage trends; normalizing costs across multiple cloud providers for one comparable view; anomaly detection for spend that doesn’t look like the pattern; and executive dashboards built around the KPIs a C-level audience actually asks about.

Where the flexibility comes from

FinOps hubs has used Azure Data Explorer as its central data platform since version 0.7. Since version 0.10, it also supports Microsoft Fabric Real-Time Intelligence (RTI), Fabric’s version of ADX, as an alternative. Both are high-performance, fully managed analytics engines built for exploring large datasets, and both are queried with the same language: Kusto Query Language (KQL).

To follow along, you need a deployed FinOps hub on either platform, and an Entra ID account with Viewer access to the hub’s Hub and Ingestion databases.

Writing your first KQL query

KQL is conceptually close to SQL, but built for fast, flexible analysis at scale. The Costs view in the Hub database is FOCUS-aligned, so an analysis built against it lines up with standardized FinOps use cases from the start. A first query is short:

Costs
| summarize Cost = sum(EffectiveCost) by BillingPeriodStart
| render columnchart

That summarizes effective cost by billing period and renders it as a column chart. ADX also understands a subset of T-SQL, so a team more comfortable in SQL isn’t blocked, though KQL is the one worth learning: it has the broader feature set, and it’s the same language used across Microsoft Defender, Azure Resource Graph, Azure Monitor, and Fabric, so the skill transfers well beyond FinOps.

From there, the queries grow naturally with the question:

Costs
| where BillingPeriodStart >= datetime(2024-01-01)
    and BillingPeriodEnd < datetime(2024-04-01)
| summarize TotalEffectiveCost = sum(EffectiveCost)
    by ProviderName, BillingCurrency, BillingPeriodStart, ServiceCategory
| order by TotalEffectiveCost desc

Costs isn’t the only view. Prices and the other FinOps hubs datasets can be queried the same way, or joined together with the join operator, and the FinOps toolkit’s best-practice query library has worked examples to start from rather than a blank editor.

Choosing where the results live

A working query is only half the job; the other half is putting it in front of the right audience.

• Excel with Power Query fits portfolio managers and procurement teams who want live FinOps data inside the spreadsheets they already use for budget planning, contract renewals, and forecast validation.
• Power BI is the natural home for FinOps teams, finance, and executive stakeholders, especially where Power BI is already the org’s reporting standard. It can build directly on ADX queries alongside the toolkit’s own report templates.
• ADX dashboards and the render operator suit lightweight, real-time needs: monitoring reservation or savings-plan utilization, or watching the cost of a specific service like Azure OpenAI, without leaving the query environment.
• Azure Workbooks work well for cloud engineers and operations teams already living in the Azure portal, combining cost data with operational telemetry on one flexible page.
• Microsoft Fabric brings it together for organizations standardizing there: Power BI reports and Real-Time Dashboards side by side, and Org Apps to package multiple FinOps assets into one role-specific experience for portfolio managers, engineers, and executives alike.

Enriching FinOps data with what it doesn’t already know

Cost data gets more useful once it’s not answering questions alone. ADX and Fabric RTI support external tables, which query data where it already lives (a data lake, SQL Server, Cosmos DB) without duplicating it, useful for organizational metadata, budget and forecast data, or blob inventory reports layered onto storage cost data for optimization analysis.

For operational context, Azure Monitor and Log Analytics integration lets you correlate cost with telemetry that’s already flowing: joining VM and disk performance metrics (CPU, memory, throughput, IOPS) against the Costs view doesn’t just surface downsizing candidates, it lets you estimate the savings a specific optimization would actually produce. Because Microsoft Sentinel is itself built on Log Analytics, the same pattern extends to security cost showback: correlating Sentinel’s cost with its own ingestion volume to allocate shared security spend fairly.

The rule of thumb for choosing between the two: reach for external tables when the data is relatively static and real-time performance isn’t critical; ingest data when you need high-performance queries over something that changes often, or real-time monitoring and anomaly detection depend on it. Most organizations end up doing both, and ADX makes it easy to promote an external table into a native one when a dataset that started as reference data turns out to need the performance.

Automating the reports you’d otherwise run by hand

Once a query is worth repeating, it’s worth automating. Power Automate and Azure Logic Apps connect to ADX natively, so a query can run on a schedule or in response to an event, then trigger a notification, populate a ticketing system, or kick off an approval workflow when spend looks unusual. Azure DevOps Pipelines can run KQL as part of CI/CD, useful for cost validation checks or generating a FinOps report as part of a deployment. And Azure Data Factory or Fabric pipelines handle the more complex orchestration: periodically enriching FinOps data with external reference data, or triggering an analysis as one step in a larger data workflow.

What holds up in practice

The pattern that keeps showing up across every custom FinOps hubs build: start with one KQL query that answers a real, specific question, put it somewhere the right audience will actually see it, and only automate it once it’s proven worth repeating. FinOps hubs already gives you the data platform to do all of this. The gap is rarely capability, it’s the time to sit down and write the first query, connect the first external source, or wire up the first automation.

That’s exactly the kind of build a workshop is scoped for: a defined outcome, in your environment, that you leave with and can extend on your own.