/e2e-fabric-cost-estimation

name: e2e-fabric-cost-estimation
description: "Estimates Fabric capacity cost before a migration by profiling Spark, SQL, Power BI, and Real-Time workloads, then recommending SKU size and comparing Reserved, Pay-As-You-Go, and Autoscale billing. Use only for capacity sizing and pricing questions, not for general migration or connectivity work."

> **Telemetry — MANDATORY.** Every `api.fabric.microsoft.com` call must carry > `x-ms-fabric-skill: e2e-fabric-cost-estimation` (`az rest`: `--headers "x-ms-fabric-skill=e2e-fabric-cost-estimation"`), > including every LRO poll, `fabric_lro` and retry. Snippets omit it — add it anyway.

> **CRITICAL NOTES** > 1. To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering > 2. To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering > 3. **Pricing is region-specific.** Always resolve the capacity's Azure region (via the Fabric REST `GET /v1/capacities`, which returns `region`/`sku`/`state`, or via ARM) or ask the user *before* any price lookup, and state the region with every quoted figure.

> **🔴 MANDATORY LIVE-PRICING FETCH — whenever your answer contains a dollar figure.** > Before presenting **any** dollar amount, cost, break-even point, billing-mode comparison, RI-vs-PAYG analysis, migration cost, or cost worksheet, you **must** run a shell command (`bash`/`powershell`) that calls the Azure Retail Prices API at `https://prices.azure.com/api/retail/prices`. This applies without exception to every *priced* answer — Databricks/Synapse migration cost, **Autoscale vs. base-SKU break-even**, RI-vs-PAYG break-even, cost worksheets, and billing-mode strategy. Fetch the live per-CU-hour PAYG rate (`priceType eq 'Consumption'`, `* Capacity Usage CU` meters), the reservation term totals, and the `autoscale for Spark Capacity Usage CU` rate **first**, then compute. Never answer a priced question from memorized or hardcoded rates, and never reason about break-even purely from formulas. If the meter lookup returns no rows, surface that to the user — **never** silently fall back to a hardcoded rate (e.g., do not assume `$0.18/CU-hr` for Autoscale; the Autoscale meter is a distinct rate that must be fetched). > **Exception — pure capacity sizing:** a question answered purely in **capacity units** with *no dollar figure* (e.g., "which SKU fits 80 CUs?" or "how many CUs does a P2 map to?") is CU math, not pricing, and does not require a fetch. The moment you attach a dollar amount to that sizing answer, the fetch becomes mandatory.

> **🟠 CLARIFY FIRST, THEN ACT — do not assume defaults.** > A priced request needs two inputs before you can fetch or compute: the **Azure region** and the **workload profile** (e.g. CU-hours/day, node/job details, or the source cluster sizes for a migration). If **either** is missing, your **first** response must **ask the user for the missing input(s) and STOP** — do **not** pick a default region (never assume `East US` or any other region to "get started"), do **not** call the pricing API, and do **not** produce estimates from assumed values. Only after the user supplies the missing inputs do you fetch live prices and compute. Asking is the correct behavior even though the mandatory-fetch rule applies to the *eventual* priced answer.

> **🔴 AUTOSCALE RATE IS A DISTINCT METER — never reuse the base/PAYG rate for it.** > The `autoscale for Spark Capacity Usage CU` meter is a **separate** price from the base `* Capacity Usage CU` PAYG rate. You **must** fetch it with its own API call and read the returned `retailPrice`. It is a correctness bug to assign the base/PAYG rate (or a memorized figure such as `0.18`) to an autoscale variable — e.g. `autoscaleRate = paygRate` or `autoscaleRate = 0.18` is **forbidden**. If the autoscale meter lookup returns no rows, list all Fabric Spark meters for the region and surface that to the user; never substitute the base rate.

Fabric Cost Estimation

Prerequisite Knowledge

• [COMMON-CORE.md](../../common/COMMON-CORE.md) — Fabric topology, capacity concepts, authentication & token audiences
• [COMMON-CLI.md](../../common/COMMON-CLI.md) — CLI patterns for capacity discovery, authentication recipes (`az login`, token acquisition)

---

Table of Contents

| Topic | Section | |---|---| | Fabric Billing Model Overview | [§ Billing Model](#fabric-billing-model) | | Capacity Unit (CU) Reference | [§ CU Reference](#capacity-unit-reference) | | Workload Cost Estimation | [§ Workload Estimation](#workload-cost-estimation) | | Storage Pricing | [§ Storage](#storage-pricing) | | Network Pricing | [§ Network](#network-egress-pricing) | | Billing Mode Strategy | [§ Billing Strategy](#billing-mode-strategy) | | SKU Sizing Decision Tree | [§ SKU Sizing](#sku-sizing-decision-tree) | | Migration Cost Worksheet | [§ Worksheet](#migration-cost-worksheet) | | Pricing API Reference | [pricing-api-reference.md](resources/pricing-api-reference.md) | | Must / Prefer / Avoid | [§ Must / Prefer / Avoid](#must--prefer--avoid) | ---

Fabric Billing Model

Microsoft Fabric uses a **unified capacity model** where all workloads share a pool of **Capacity Units (CUs)**. Understanding the billing dimensions:

| Dimension | Description | Billing Mechanism | |---|---|---| | **Compute (CU-seconds)** | Processing power consumed by queries, Spark jobs, pipelines | CU consumption against capacity SKU | | **Storage (GB/month)** | OneLake storage for Delta tables, Files, shortcuts | Per-GB monthly rate | | **Network egress (GB)** | Data leaving Azure region | Per-GB egress charges | | **Capacity reservation** | Base SKU commitment (F2–F8192) | Monthly or annual commitment |

Billing Modes

| Mode | Description | Best For | |---|---|---| | **Reserved Instance (RI)** | 1-year or 3-year commitment; significant discount (compute from live API)