Microsoft Fabric Cost Optimisation: Capacity Units, Burstable Workloads, and Avoiding Bill Shock

A common reaction from data leaders after their first month with Microsoft Fabric: “The platform is great, but I don’t understand my bill.” The capacity unit model is conceptually different from the per-query pricing of Athena, the per-DBU pricing of Databricks, or the per-hour pricing of Redshift. If you manage Fabric like you managed those services, you will either over-provision (wasting money on idle capacity) or under-provision (throttling your users at peak times).

This guide covers the mechanics of Fabric’s pricing model, how to right-size your capacity, and the specific levers available for cost control — including the features that most organisations miss during initial deployment.

How Fabric Capacity Pricing Works

Microsoft Fabric uses a capacity unit (CU) model. A Fabric capacity is a pool of compute resources measured in CUs per second. You purchase a capacity SKU that determines the total CU pool available:

SKU	CUs	Approximate Use Case
F2	2	Development/experimentation
F4	4	Small development workloads
F8	8	Small production + dev/test
F16	16	Medium workloads
F32	32	Medium production
F64	64	Large production (Copilot minimum)
F128	128	Enterprise production
F256–F2048	256–2048	Large enterprise / critical workloads

Every Fabric workload consumes CUs: a Spark notebook session, a pipeline run, a Power BI report query, an Eventstream ingestion job, a KQL Database query. These workloads draw from the shared CU pool of the capacity they are assigned to.

SKU pricing (Azure Canada Central, approximate as of mid-2026): F2 runs approximately CAD $300–$400/month for a 24/7 running capacity. F64 runs approximately CAD $9,000–$11,000/month. Actual pricing varies by region and Microsoft agreement terms — always validate with your Microsoft account team or the Azure pricing calculator.

Storage is billed separately from compute. OneLake storage is priced at Azure Data Lake Storage Gen2 rates — approximately USD $0.02–$0.025 per GB/month for LRS (locally redundant storage). For most organisations, storage costs are a fraction of compute costs.

The Smoothing Algorithm: How Fabric Handles Bursts

Unlike per-query pricing models that charge exactly for what you use in real time, Fabric uses a smoothing algorithm to manage burst workloads against your capacity’s CU pool.

When a workload consumes more CUs than your capacity’s baseline rate (i.e., a burst), Fabric does not immediately throttle or charge overage. Instead, it tracks the excess consumption and “smooths” it over a 24-hour window. If your total consumption over 24 hours stays within your capacity’s daily CU budget, you experience no throttling.

The practical implication: short bursts (a heavy pipeline run, a complex Power BI query against a large dataset) are absorbed without throttling, even if the instantaneous CU consumption exceeds your SKU’s baseline. Only sustained over-consumption — workloads that consistently exceed your capacity throughout the day — results in throttling (interactive queries de-prioritised, background jobs queued).

This means the right-sizing question is about average daily CU consumption, not peak instantaneous consumption. A capacity that handles your typical workload day without sustained throttling is correctly sized.

Pause and Resume: Your Primary Cost Control Lever

The most impactful cost control mechanism for non-production Fabric capacities is pause and resume. A paused Fabric capacity incurs no compute charges — only storage charges continue. Pausing a development or test capacity during evenings and weekends can reduce non-production compute costs by 60–70% for a typical business-hours usage pattern.

Microsoft provides three mechanisms for pausing and resuming capacities:

Azure Portal: Manual pause/resume through the Fabric capacity blade. Suitable for ad-hoc control; not suitable for scheduled automation.

Fabric Capacity REST API: The /suspend and /resume endpoints allow programmatic capacity management. Invoke via Azure Logic Apps, Azure Functions, or a scheduled GitHub Actions workflow:

# Pause a Fabric capacity via REST API
az rest --method post \
  --url "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Fabric/capacities/{capacityName}/suspend?api-version=2023-11-01"

Power Automate: Build a scheduled cloud flow that calls the Fabric REST API to pause capacity at 6 PM weekdays and resume at 7 AM weekdays. Power Automate is available to all Microsoft 365 users and requires no code.

Critical operational note: When a capacity is paused, all active Fabric sessions in that capacity are terminated. Ensure that scheduled pipeline runs complete before the pause window, and communicate the pause schedule to users who may have active notebooks or report sessions.

Workspace-Level Capacity Assignment

Every Fabric workspace is assigned to a capacity. Workspaces on the same capacity share the CU pool. This creates an opportunity for cost isolation: by assigning workspaces to different capacities, you control which workloads compete for which CU pools.

A recommended architecture for cost management:

Production capacity (F64 or above, always on): Production Lakehouses, production pipelines, Gold layer data, Power BI semantic models serving end users.

Development capacity (F8 or F16, paused on schedule): Developer Lakehouses, experimental notebooks, pipeline testing. Paused evenings and weekends.

Heavy batch capacity (F32 or F64, event-triggered): Reserved for resource-intensive batch workloads — large data migrations, monthly reconciliation runs, model retraining jobs. Resumed only during scheduled batch windows, paused otherwise.

This isolation prevents a rogue notebook (an inefficient Spark job that runs a full table scan) from consuming the CU pool allocated to interactive Power BI users, which would cause their report queries to be throttled.

Storage Costs: OneLake Is Not Free

A common misconception about Fabric is that OneLake storage is included in the capacity price. It is not. OneLake storage is billed at ADLS Gen2 rates — pay-per-GB stored, separately from your capacity SKU.

Cost control for OneLake storage:

• Delta table VACUUM: Delta tables accumulate old file versions for time-travel. Run VACUUM tableName RETAIN 168 HOURS (7-day retention is a reasonable default for most use cases) on a schedule to delete obsolete Parquet files and reclaim storage.
• Delta OPTIMIZE: Run OPTIMIZE tableName periodically to compact small Parquet files into larger ones, reducing both storage costs and Spark read overhead.
• Lifecycle management: Fabric does not yet support native OneLake lifecycle policies (automatic tiering to cool/archive storage). Monitor storage growth via the Fabric Capacity Metrics app and archive historical data to lower-cost Azure Blob Storage if needed.

Shortcuts and Cross-Cloud Egress Costs

If you use OneLake shortcuts to link AWS S3 or Google Cloud Storage data into Fabric (as described in our OneLake architecture guide), the data transfer costs are your responsibility — not Microsoft’s.

When a Fabric Spark notebook reads from an S3 shortcut, AWS charges standard S3 data transfer out (egress) fees. At scale, these fees are significant: AWS charges approximately USD $0.09/GB for data leaving the US regions, and similar rates for other regions.

Cost control for shortcut-based architectures:

• Use shortcuts for moderate-volume, low-frequency reference data only
• For high-volume, high-frequency data accessed regularly from Fabric, copy it to native OneLake storage using a Data Factory Copy activity
• Monitor shortcut read volume in the Fabric Capacity Metrics app (Spark job metrics show bytes read from external sources)

Spark Compute Tuning

Spark workloads in Fabric notebooks consume CUs proportional to the executor and driver memory configuration. Default session configurations provision more resources than most workloads require, which inflates CU consumption.

Recommended session configuration for medium data workloads (files in the 1–50 GB range per notebook run):

%%configure
{
    "driverMemory": "4g",
    "driverCores": 2,
    "executorMemory": "4g",
    "executorCores": 2,
    "numExecutors": 4
}

For large-scale batch workloads (100 GB+ data volumes), scale up executor count and memory — but explicitly configure rather than relying on defaults.

Avoid always-on Spark sessions: A Fabric notebook session holds allocated resources until it times out (default: 20 minutes of inactivity). For scheduled Spark Job Definitions, the session starts on trigger and terminates on completion. For interactive notebooks left open by developers, sessions accumulate idle CU consumption. Configure workspace session timeout policies and communicate to development teams.

The Fabric Capacity Metrics App

Microsoft provides a Fabric Capacity Metrics Power BI app that connects to your Fabric capacity and displays:

• CU burndown by item, workload, and time period
• Throttling events (when workloads were queued due to capacity saturation)
• Top consumers by CU usage
• Storage consumption by item

Install this app in your capacity’s admin workspace and review it weekly during the initial deployment period. The most common finding in initial deployments: a small number of Spark notebooks or pipelines consuming a disproportionate share of CUs due to inefficient query patterns (full table scans, unoptimised join order, excessive shuffle operations).

Fabric vs AWS Redshift Serverless + Glue: Which Is More Economical?

For organisations choosing between Fabric and an AWS-native analytics stack:

AWS Redshift Serverless + Glue pricing is fully usage-based: Redshift charges per RPU-hour consumed, Glue charges per DPU-hour. At low utilisation (spiky, intermittent workloads), this model is economical — you pay only for actual consumption. At consistent high utilisation, the usage-based cost can exceed an equivalent Fabric capacity SKU.

Microsoft Fabric with a right-sized capacity and pause/resume automation is more predictable at consistent utilisation. For organisations with clear business-hours usage patterns and development environments that can be paused, Fabric’s monthly capacity cost provides cost certainty that per-query models do not.

Rule of thumb: if your analytics workloads are consistent (daily batch + business-hours BI), Fabric’s capacity model is likely more economical at mid-to-large scale. If your workloads are highly variable or genuinely low-volume, per-usage models (AWS, or Fabric’s pay-as-you-go option for development capacities) may cost less.

Conclusion

Microsoft Fabric’s capacity pricing model requires a different cost management discipline than per-query or per-cluster models. Right-sizing your capacity SKU, implementing pause/resume for non-production environments, isolating workload categories across workspace-capacity assignments, and tuning Spark session configurations are the primary levers. Used correctly, these controls make Fabric cost predictable and competitive with usage-based alternatives.

Evaluating Microsoft Fabric for your organisation? Infra IT Consulting helps Canadian and international businesses assess, architect, and implement modern data platforms. Book a discovery call →