Building a Fabric cost model as a Microsoft partner

Capture at least this during discovery, because these are the inputs to your entire model:

• data volume today and expected growth per year
• number of pipelines and how often they run
• transformation complexity and where it lands (Spark, Warehouse, Dataflow)
• number of Power BI users, split into creators and readers
• number of concurrent users at the busiest moment of the day
• real-time requirements, and whether a KQL database belongs to them
• number of environments: development, test and production
• retention requirements and what happens to historical data

Microsoft states in Plan your capacity size that required compute varies widely depending on the operations performed, how efficiently they are written and the level of concurrency. That is exactly why picking a SKU based on data volume alone, or user count alone, does not work. Two customers with 2 TB and 200 users can differ by a factor of three in consumption.

The SKU table runs from F2 (2 CUs) to F8192 (8192 CUs). In a 30 second block an F2 therefore has 60 CU seconds to spend and an F64 has 1920. That calculation is documented in Plan your capacity size and underpins everything you see in the Capacity Metrics app.

Each workload behaves differently, and you need to know the difference:

• Data Factory is serverless. Pipelines use the Data Orchestration and Data Movement meters, Dataflow Gen2 uses Standard Compute and High Scale Compute, and Copy job uses Data Movement and Data Movement Incremental copy. See Data Factory pricing.
• Warehouse is serverless too and bills per active query in CU seconds. Fabric reports almost all warehouse operations as background, so they are smoothed over 24 hours.
• Spark maps one CU to two Spark vCores, so an F64 provides 128 Spark vCores. All Spark operations are background. The default session timeout is 20 minutes, and a session left open keeps consuming. See Apache Spark billing and utilization.
• Real-Time Intelligence bills on active seconds times vCores of the KQL database, and all those operations are interactive.
• Power BI is mixed: DAX queries are interactive, refreshes are background.
• OneLake storage consumes no CUs but is billed pay-as-you-go per GB. Transactions against OneLake do consume CUs. See OneLake compute and storage consumption.

On top of that, bursting and smoothing apply. Fabric lets operations temporarily use more compute than the SKU provides and then spreads the cost over time: interactive operations over a minimum of five and a maximum of sixty-four minutes, background operations over 24 hours. Throttling only starts once you have consumed more than ten minutes of future capacity, and then progresses in stages until all new requests are rejected. The full description is in Understand the Fabric capacity throttling policy.

The Fabric SKU Estimator is a web calculator that recommends a suitable SKU based on your input. The tool is in preview at the time of writing. You enter, among other things, compressed data size in GiB, the number of daily batch cycles and the number of tables in your sources, you select the workloads you plan to use, and you get an estimated viable SKU plus a breakdown per workload. The estimator supports Data Engineering, Data Factory, Data Warehouse, Data Science, OneLake, Power BI and Power BI Embedded, Real-Time Intelligence and Fabric databases.

That makes the estimator excellent for the first round of conversations and for comparing scenarios. What the tool cannot know is how efficient the code your team writes will be. The same transformation can easily cost a multiple in a badly written notebook compared to a well written one.

Microsoft explicitly advises in Evaluate and optimize your Microsoft Fabric capacity to start small and gradually increase capacity. For a partner that is also the commercially safest advice: a customer scaling up after three months because the platform is being used is a success story. A customer having to scale down because you bought too much is a discussion about your advice.

Microsoft describes the route in Plan your capacity size: create a trial capacity, review utilization in the Capacity Metrics app, drill down to the timepoint you want to assess and read the SKU card and the Capacity CU card there. Evaluate and optimize your Microsoft Fabric capacity adds that you can use trial capacities or pay-as-you-go F SKUs to measure the actual size required before buying a reserved instance.

Measure at least this, and keep the screenshots:

• CU consumption per item and per operation
• peak utilization and what time of day it falls
• runtime of pipelines and notebooks
• concurrency during the busiest hour
• the throttling chart and the overages tab, including minutes to burndown
• the System events table for actual throttling events
• rejected operations in the drilldown

There is one detail partners often miss. Throttling calculations include only billable operations, and some preview features generate non-billable operations. Microsoft writes in Understand the Fabric capacity throttling policy that you should use those non-billable operations to plan ahead, so your capacity is right for when the feature does start counting. If your PoC leans on preview functionality, your measured consumption is structurally too low.

The trial capacity is useful for learning but not for committing. It is equivalent to an F64, runs for 60 days and is not a basis for a price agreement. See Microsoft Fabric licenses.

Work it out like this:

1. Baseline. Normal usage as measured in the PoC, extrapolated to production. This is the scenario you base the reservation on.
2. Growth. What happens with the agreed data growth, extra pipelines or extra users over twelve months. State explicitly at what point a SKU step becomes necessary.
3. Peak. Month-end close, year-end close, a campaign or a migration period during which history is loaded. This is also where you decide whether to scale up temporarily or let smoothing absorb it.

Concurrency deserves separate attention in the peak scenario. Microsoft names high concurrency, meaning too many users for the capacity size, as one of the causes of high interactive consumption in Evaluate and optimize your Microsoft Fabric capacity. Query scale-out can improve the experience under high concurrency, but explicitly does not result in less total compute. That is an important distinction to explain to a customer: you are buying responsiveness, not savings.

• Microsoft platform cost. The Fabric capacity, OneLake storage, data movement and the related Azure services. This is the customer's consumption, even when you invoice it.
• Partner implementation cost. Architecture, build, migration, testing, deployment, documentation, knowledge transfer and the first period of aftercare. This is your effort and it does not move with CU consumption.
• Partner commercial price. What you ultimately charge. That is a choice, not a sum.

The reason to separate them is not accounting but commercial. If you put margin on consumption, you earn more the less efficiently the platform runs. That puts your interest against your customer's, and it is exactly the behaviour you cannot defend in a quarterly review.

For partners in the CSP model there is a concrete calculation on top. Partner earned credit is earned on managed services within the Azure plan and requires a PEC eligible built-in role at the right scope, but it does not apply to reservations under the Azure plan. See Partner earned credit. A reservation and partner earned credit are therefore mutually exclusive on the same consumption. Calculate both variants before you choose, because the answer differs per customer.

Write these assumptions into the proposal verbatim:

• data volume at start and assumed growth percentage
• number of pipelines, frequency and expected runtime
• number of users, split into creators and readers
• assumed concurrency at the peak moment
• which environments exist and which of them run continuously
• retention period and what happens to soft-deleted data
• the chosen SKU and the measurement period it is based on
• the pricing region, because Fabric rates differ per region
• whether pay-as-you-go or a reservation is assumed

Keep the customer-facing table deliberately simple. Fill in rates from the current Microsoft pricing page for the correct region and never put an invented amount in it.

Agree on a revision moment as well. After the first full production month you compare measured CUs against the assumption and adjust the model. That conversation is easy if you wrote down the assumptions and painful if you did not.

Microsoft describes per workload where consumption originates in Evaluate and optimize your Microsoft Fabric capacity. The choices with the biggest leverage:

• Dataflows and pipelines. Achieve query folding, because without folding Power Query retrieves everything and transforms locally. Disable staging for small volumes and simple transformations. Do not refresh more often than the source changes, because an hourly refresh on a daily source adds nothing.
• Warehouse. Use the smallest suitable data types, because a VARCHAR(500) that could have been 25 changes the query plan. Model in star schema and keep statistics current, with FULLSCAN where needed.
• Spark. Stop sessions you are not using, because the default timeout is 20 minutes. Reserve only the executors you need, otherwise other jobs run into HTTP 430.
• Power BI. Star schema, efficient DAX, incremental refresh on large fact tables, and not too many visuals per page. Report bursting, where many reports are generated at the same time, is a classic cause of background peaks.
• Shortcuts instead of copies. For a shortcut within OneLake, transaction usage counts against the capacity of the workspace holding the shortcut, while storage is billed to the capacity where the data lives. For a shortcut to an external source such as ADLS, OneLake does not count the usage, but that external service bills you directly. See OneLake compute and storage consumption.
• Number of capacities. Scaling out, meaning spreading workloads across multiple capacities, is how you protect critical reporting from a heavy experiment. Surge protection helps, but Microsoft explicitly adds that to fully protect critical solutions you should isolate them in a correctly sized capacity.

Two practical details that can break a migration plan. Scaling across the boundary between F256 and F512, in either direction, puts the capacity through a transition that can cancel in-flight operations and running jobs. Plan such a resize in a maintenance window. And after scaling up, the capacity licence update can take up to a day, during which Free users may still be asked to upgrade to Pro. Both are documented in Scale your Fabric capacity.

Pay-as-you-go suits an environment you want to pause or scale: development and test, temporary migration capacity, and the first months of a new platform while you are still measuring. F SKUs are billed per second with a one minute minimum, and you can pause the capacity when nothing is running. Pausing does generate a bill for the accumulated future consumption, so it is not an escape from costs already incurred.

A reservation suits the demonstrable base load in production. Mind the boundaries: you commit to a number of CUs per region for one or three years, the reservation covers neither storage nor networking, and it does not auto-renew by default. When it expires, workloads keep running at pay-as-you-go. See Fabric capacity reservations. A useful detail for your model: scaling below your reserved capacity does not affect the bill, so a reservation on the base load stays useful even when you temporarily run smaller.

In the CSP model, only admin agents or sales agents can purchase a Fabric reservation. Arrange that up front, because signing day is an unpleasant moment to find out.

The situation: an organization with roughly 2 TB of compressed data, expected growth of 25 percent per year, 40 pipelines of which 35 run nightly and 5 run hourly, 250 Power BI users of which 15 are creators, and a peak of about 60 concurrent readers around nine in the morning. Three environments are planned: development, test and production. Retention is seven years, with the last two years in active use.

How the model runs:

1. Workload profile. Batch oriented with a clear nightly window and a morning peak on reporting. No real-time requirements, so no KQL database in the model.
2. Initial estimate. Input into the SKU Estimator (2 TB compressed, 40 daily batch cycles, the number of source tables, workloads Data Factory, Warehouse and Power BI) produces a starting recommendation. That recommendation goes along as an attachment, not as a commitment.
3. PoC. Two weeks on trial capacity, with the five heaviest pipelines and the three most used reports. Measured: CU consumption per pipeline, the morning peak in utilization and whether throttling occurs.
4. Scenarios. Baseline is the measured nightly window plus the morning peak. Growth is the same workload with 25 percent more data and 50 extra readers. Peak is the month-end close plus the one-off historical migration of seven years of data.
5. Environments. Production runs continuously. Development and test sit on a separate, smaller capacity that is paused outside office hours. That is an architecture choice with a direct cost effect.
6. Licences. With 235 readers, whether the F64 threshold is reached becomes decisive. Below F64 every reader needs a Pro licence; at F64 and above a free licence with the Viewer role is enough. That comparison belongs in the proposal, with both amounts.
7. Purchase model. Production moves to a reservation on the base load after the first measured production month. Development and test stay pay-as-you-go so pausing remains possible.

The deliverable is not an amount but a table of assumptions, a range and a revision moment. That is exactly what you want to hand over.

Build eight reusable artefacts and maintain them as a product:

• a discovery questionnaire that collects exactly the inputs of your model
• a workload assessment that records the expected consumption pattern per workload
• a capacity estimate with the SKU Estimator input worked into it
• a PoC playbook with fixed measurement points from the Capacity Metrics app
• a cost model with the three scenarios and the assumption list
• an architecture review that walks the cost levers from this article
• a production sizing document that puts measured values next to the estimate
• a monthly cost review with a fixed owner at both customer and partner

That last one is your bridge to a managed service. A customer who receives a substantiated monthly overview of consumption, deviation and proposed optimization is not buying a report but peace of mind. And because partner earned credit is earned on management rather than resale margin, that model works on your side too.

The core of all this: a good Fabric cost model does not predict the exact bill six months out. It makes visible which assumptions an amount rests on, validates those assumptions against real measured consumption, and adjusts architecture and capacity as the customer's platform grows. That is defensible. A single number is not.

• Plan your capacity size
• What is the Fabric SKU Estimator (preview)?
• Evaluate and optimize your Microsoft Fabric capacity
• Understand the Fabric capacity throttling policy
• Microsoft Fabric concepts and licenses
• Scale your Fabric capacity
• OneLake compute and storage consumption
• Data Factory pricing in Microsoft Fabric
• Apache Spark billing and utilization in Microsoft Fabric
• Fabric capacity reservations
• Partner earned credit

To walk through the calculation method on the customer side step by step, read How to build a cost model for Microsoft Fabric. For optimizing an existing capacity, Capacity and cost optimization in Fabric is the follow-up.