Forum Discussion
Fabric Capacity Cost
Hello Community,
Last week, I used Microsoft Fabric (F2 capacity, Southeast Asia region) to run a simulation. I’m on a pay-as-you-go model, and I only activated the capacity for around 8 hours on that particular day.
According to the official pricing information, the F2 capacity costs NT$10.77 per hour.
So, based on this, my expected cost should be: NT$10.77/hour × 8 hours = NT$86.16
However, when I checked Azure Cost Management, I was surprised to see that the total charge for that day was NT$537.05.
I’d like to understand whtehr there are there additional costs) that could have contributed to this?
Thank you in advance!
Hi facessang ,
Apologies for the delayed response, and thank you for your patience.
Additional Considerations
- Failures Matter: That one failed execution of Notebook 1 still consumed over 122k CU, which may not yield business value. Minimizing failure retries or optimizing cell execution order could help.
- Idle or Headless Jobs: Some EventHub and EventStream entries have 0 successful runs but high CU+duration. Are these continuously active inputs? If so, re-evaluating their polling patterns or intervals might reduce CU waste.
- Overprovisioning: With a sustained average utilization >500%, you may be regularly hitting auto scale buffers. If you haven't explicitly disabled auto scale, that could lead to higher CU costs though still within your subscription cap.
- Monitoring & Alerts: Consider adding utilization alerts or usage caps through Azure Cost Management, especially if you're testing in iterative bursts.
Understand your Fabric capacity throttling - Microsoft Fabric | Microsoft Learn
Best Regards,
Lakshmi Narayana
6 Replies
v-lgarikapatCommunity Support
Hi facessang ,
Thanks for reaching out to the Microsoft fabric community forum.
Thanks for sharing this your calculation seems logical based on the F2 hourly rate, but Microsoft Fabric billing is actually tied to Capacity Unit (CU) consumption rather than flat hourly charges. Even though F2 provides 2 CUs per second, workloads like Copilot, Spark, Eventhouse, Compute Pools, or Dataflows can dynamically consume more than the base capacity via bursting, and you're billed per CU-second used. In your case, it looks like AI and Spark-related workloads significantly increased total usage, which explains the NT$537.05 charge. To better understand and track this, I’d recommend using the Fabric Capacity Metrics app, which provides CU usage by workload. Also, consider pausing the capacity when not in use and exploring reservation plans if your usage is consistent these steps can really help control cost spikes.
For reference
What is the Microsoft Fabric Capacity Metrics app? - Microsoft Fabric | Microsoft Learn
Understand the metrics app compute page - Microsoft Fabric | Microsoft Learn
Microsoft Fabric concepts - Microsoft Fabric | Microsoft Learn
Copilot consumption - Microsoft Fabric | Microsoft Learn
Data Warehouse Billing and Utilization Reporting - Microsoft Fabric | Microsoft Learn
Solved: Pricing in details - Microsoft Fabric Community
Solved: F2 Capacity for Small Business - Microsoft Fabric Community
If this post helped resolve your issue, please consider the Accepted Solution. This not only acknowledges the support provided but also helps other community members find relevant solutions more easily.
We appreciate your engagement and thank you for being an active part of the community.
Best regards,
LakshmiNarayana.Thank you for the reply!
In that case, I check my Fabric Capacity Metrics, I found out that I used 240,009.4763 CU(s) on that day. The cost it should be 359 NTD. Do I still miss something else?- v-lgarikapat
Hi facessang ,
Apologies for the delayed response, and thank you for your patience.
Additional Considerations
- Failures Matter: That one failed execution of Notebook 1 still consumed over 122k CU, which may not yield business value. Minimizing failure retries or optimizing cell execution order could help.
- Idle or Headless Jobs: Some EventHub and EventStream entries have 0 successful runs but high CU+duration. Are these continuously active inputs? If so, re-evaluating their polling patterns or intervals might reduce CU waste.
- Overprovisioning: With a sustained average utilization >500%, you may be regularly hitting auto scale buffers. If you haven't explicitly disabled auto scale, that could lead to higher CU costs though still within your subscription cap.
- Monitoring & Alerts: Consider adding utilization alerts or usage caps through Azure Cost Management, especially if you're testing in iterative bursts.
Understand your Fabric capacity throttling - Microsoft Fabric | Microsoft Learn
Best Regards,
Lakshmi Narayana
