← All case studies
Australian lender · Microsoft Fabric

Microsoft Fabric Capacity Autoscaling

Match Fabric capacity to changing processing and reporting demand, with a client-reported monthly run rate reduced from AUD 14,000 to AUD 3,000.

Microsoft FabricReal-Time IntelligenceCapacity telemetryAutomation
Microsoft Fabric Capacity Autoscaling

The problem

The lender's Fabric workload did not need the same amount of compute throughout the day. Overnight ETL and data preparation created a heavy processing window; daytime reporting introduced a different, changing pattern of demand. Holding capacity at the level required for the busiest period meant continuing to pay for that allocation when less work was running. Sizing only for quieter periods would create the opposite risk: important processing and reports might have to wait when demand rose. The problem was to manage that tradeoff without making manual resizing another operational task.

A reservation offers a lower unit price for eligible committed usage, but price and utilisation are different questions. A discounted allocation can still exceed what the workload needs at a particular time. Equally, a consistently busy baseline may be well suited to a reservation. The design therefore needed to follow this client's workload rather than assume one purchasing model is best for every organisation. Predictable overnight demand and unexpected business-hour pressure both had to be considered, along with the point at which it was safe to reduce capacity.

The objective was to use the available allocation effectively before increasing it, then return to a lower run rate when the work allowed. Cost needed to be considered alongside timely data and usable reports. As reporting and AI use expand, that decision remains a workload-management question rather than a one-off choice of capacity size.

The solution

ProcessBI implemented a near-real-time control loop around Fabric capacity telemetry. It evaluates current and smoothed consumption, recognises predictable windows such as overnight ETL, and watches business-hour demand for sustained pressure that could lead to throttling.

The control policy does not treat every short spike as a reason to buy more capacity. It first makes effective use of the current allocation, then resizes within approved limits when demand persists. Cooldown rules, operational logging, alerts and a manual override protect critical reporting and refresh windows.

The implementation plan

A controlled sequence from workload evidence to accountable scaling.

01
Observe the workloadBring utilisation, smoothed consumption and early throttling indicators into a near-real-time monitoring layer instead of sizing from a monthly average.
02
Optimise before scalingIdentify inefficient jobs and use the existing allocation effectively before increasing the SKU. Scaling supports sound workload design; it does not replace it.
03
Set workload-specific policyDefine minimum and maximum capacity, planned ETL windows, business-hour thresholds, cooldown periods and the conditions for a safe scale-down.
04
Automate with safeguardsScale within approved bounds, record the reason for every change, alert on failure and retain a manual override for critical processing and reporting periods.
05
Measure cost and serviceTrack run-rate cost alongside refresh completion, report availability and throttling so savings are never achieved by making the business wait for data.

Capacity behaviour and cost

The 24-hour pattern explains the control logic. The monthly cost comparison uses the client-supplied figures.

A responsive 24-hour capacity policy

The chart shows how a control policy can respond to workload shape without holding peak capacity all day.

Microsoft Fabric workload and capacity pattern over 24 hours A fixed peak capacity line remains high throughout the day. A changing workload peaks during overnight ETL, settles, rises during business hours and spikes again in the afternoon. The autoscaled capacity follows sustained demand within controlled steps. Overnight ETL Business hours

Monthly run-rate comparison

AUD per month. The reserved figure is a 40% discount applied to the AUD 14,000 base, as specified for this comparison.

Fixed peak PAYG baseAUD 14,000
Reserved comparator · 60% of baseAUD 8,400
Autoscaled PAYG · client-reportedAUD 3,000

Microsoft currently advertises approximately 41% reservation savings versus pay-as-you-go; actual regional pricing and reservation coverage vary. Microsoft Fabric pricing ↗

78.6%lower than the fixed peak pay-as-you-go base
64.3%lower than the 40%-discounted reserved comparator
AUD 64,800annualised difference versus that reserved comparator, if sustained
Monthly operating modelBasisRun rate
Fixed peak pay-as-you-goOwner-supplied base comparatorAUD 14,000
Reserved capacity comparator60% of the base after a 40% discountAUD 8,400
Autoscaled pay-as-you-goClient-reported engagement resultAUD 3,000

Benefits analysis

The value came from matching capacity to service demand, not simply choosing the lowest unit price.

COST
Less idle headroomCapacity could return to a lower run rate after heavy processing instead of remaining fixed at the level needed for the largest window.
SERVICE
Performance protectedSustained demand could trigger additional capacity before users experienced avoidable data, refresh or reporting delays.
CONTROL
Decisions became auditableEvery resize had a workload reason, approved boundary and operational record rather than relying on ad hoc manual intervention.
GROWTH
Ready for changing demandThe policy can respond as data volumes, reporting adoption and agentic AI workloads alter the capacity profile.
Process → Architecture → Delivery

Our methodology

  1. 01DiscoverAgree the outcome, the decisions and the requirements.
  2. 02Current stateMap how the work and data flow today, with evidence.
  3. 03Root causesFind what drives the delay, rework or disagreeing numbers.
  4. 04ApproachAgree the target design, scope and measures of success.
  5. 05BuildBuild the process change, model or report the design calls for.
  6. 06OptimiseTest at real volumes; tune speed, cost and usability.
  7. 07ProductioniseRelease with managed deployment, monitoring and support.
  8. 08GovernSet owners, access and controls so it keeps working.
Swimlane process map: As-is: fixed peak capacity, manual resizing. The steps are listed below the diagram.
Illustrative reference process 1 of 2As-is: fixed peak capacity, manual resizing Capacity sits at peak all day. When someone resizes manually, in this example, the reason and the job state are not recorded.
Steps in this diagram

Lanes: Workloads, Platform admin, Report users.

  • Day starts
  • Hold peak capacity all day
  • Idle headroom most hours
  • Ad-hoc manual resize
  • Throttled reports if sized down
  • No record of why
Full size
Swimlane process map: To-be: policy-driven resizing with safeguards. The steps are listed below the diagram.
Illustrative reference process 2 of 2To-be: policy-driven resizing with safeguards Optimise before scaling, resize within approved bounds, wait out cooldown and completion checks before scaling down, record the reason, alert on failure, and keep a manual override.
Steps in this diagram

Lanes: Telemetry (automated), Policy engine, Platform owner, Fabric capacity.

  • Every minute
  • Smoothed CU + windows
  • Sustained pressure / window?
  • Scale up within max
  • Jobs done + cooldown?
  • Scale down within min
  • Resize applied
  • Reason + bound logged
  • Override for critical period
  • Auditable decision
Full size
Architecture diagram: Near-real-time capacity control loop. The components are listed below the diagram.
Reference architectureNear-real-time capacity control loop Capacity telemetry streams into an Eventhouse. A policy engine evaluates smoothed consumption, planned windows, bounds and cooldown, then resizes through the Azure Resource Manager API. Every action is logged; operators can override from Teams.
Components in this design
  • Fabric capacity (F-SKU, Azure resource)
  • Workspace monitoring (CU, throttling, jobs)
  • Eventstream (30-second timepoints)
  • Eventhouse (smoothed CU, windows)
  • Manual override (Teams adaptive card)
  • Policy engine (bounds, cooldown, windows)
  • Policy config (min/max, ETL windows)
  • Resize via ARM API (resizes the F-SKU (managed identity))
  • Log Analytics (action log + alerts)
  • Control-loop report (sample report on this page)
Full size
First page of the Fabric Capacity & Cost sample report
Delivery: interactive Power BI sample reportFabric Capacity & Cost Operate the autoscaling policy: see demand against allocation, audit each scale action, and confirm that lower cost never came from making the business wait for data. Delivered with named owners, role-based access, release pipelines and a controlled way to change governed measures.
Full screen
Who it is for
Platform owner, FinOps, data platform on-call.
Decision it supports
Adjust policy bounds or windows; override for critical periods; investigate throttling.
Report pages
Control loop

Reference design: how this pattern is typically built on Microsoft services. Component choices for a specific engagement depend on the client's environment and existing licences.

Microsoft icons are used under Microsoft's terms. Icon notices

Synthetic sample data, not client data.

The outcome

Client-reported result
Based on client-supplied monthly run-rate figures, Fabric capacity cost decreased from approximately AUD 14,000 to AUD 3,000 per month — an AUD 11,000 or 78.6% reduction. Against the requested reserved-capacity comparator of AUD 8,400, the autoscaled run rate was AUD 5,400 or 64.3% lower. If sustained for 12 months, those differences annualise to AUD 132,000 and AUD 64,800 respectively. These are client-reported engagement figures, not universal Fabric benchmarks.
Next step

Paying for peak Fabric capacity all day?

Tell us what is happening. We agree priorities and scope before proposing any work.

Talk through your projectThe service: Fabric Migration & Power BI Optimisation