---

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 — Fabric topology, capacity concepts, authentication & token audiences
• 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 | | Capacity Unit (CU) Reference | § CU Reference | | Workload Cost Estimation | § Workload Estimation | | Storage Pricing | § Storage | | Network Pricing | § Network | | Billing Mode Strategy | § Billing Strategy | | SKU Sizing Decision Tree | § SKU Sizing | | Migration Cost Worksheet | § Worksheet | | Pricing API Reference | pricing-api-reference.md | | 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) | Steady-state base load | | Pay-As-You-Go (PAYG) | Hourly billing; no commitment; full list price | Testing, unpredictable workloads | | Autoscale Billing for Spark | Opt-in serverless model; Spark jobs offloaded from capacity and billed per Spark CU-hour. Bursting & smoothing disabled for Spark; does not consume capacity CUs | Isolating variable Spark spend from steady-state capacity | | Fabric Trial | Trial capacity (size varies by tenant/eligibility — commonly up to F64 for 60 days); verify current trial terms before use; never size production from it | Evaluation only |

Capacity SKU Tiers — Live Pricing Lookup

Do NOT use hardcoded prices. Always fetch current pricing from the Azure Retail Prices API at runtime.

Step 1: Detect Customer Region

If the customer already has a Fabric capacity, get its region, SKU, and state from the core Fabric REST API — GET https://api.fabric.microsoft.com/v1/capacities returns region, sku, and state per capacity. Azure Resource Manager (az resource list) is an equivalent fallback; only the Fabric Admin API (/v1/admin/capacities) omits region. See the templates in resources/pricing-api-reference.md.

If no capacity exists yet, ask the user which Azure region they plan to deploy in.

Step 2: Fetch Live Fabric Pricing

Query the Azure Retail Prices API (public, no auth required). For every priced question — including Autoscale-vs-base break-even and billing-mode (PAYG/RI/pause-resume) strategy — your first action must be to actually run this fetch in a shell (bash/powershell) before any calculation. Do not reason about break-even or billing trade-offs from formulas alone; run the command, then compute from the returned retailPrice rows:

curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=serviceName%20eq%20'Microsoft%20Fabric'%20and%20armRegionName%20eq%20'<region>'" | jq '.Items[] | {meterName, retailPrice, unitOfMeasure, type, reservationTerm}'

Use the reference template in resources/pricing-api-reference.md to paginate NextPageLink results, then filter to the Fabric capacity meters for the selected region. The Retail Prices API does not return one row per F-SKU — matching ^F\d+ against skuName/armSkuName returns nothing. PAYG per-CU-hour is now billed on per-workload Consumption meters whose meterName ends in Capacity Usage CU (priceType eq 'Consumption', unitOfMeasure eq '1 Hour'); take the modal retailPrice across them for the base compute rate (a low, per-CU-hour figure — always use the value the API returns; do not copy any illustrative number from this skill). Reservations come from meterName eq 'Fabric Capacity CU' (the legacy flat meter is now reservation-only). Read the per-CU rates from those rows.

Step 3: Build the Pricing Table

The API gives you a per-CU rate, not per-SKU prices. Build the per-SKU table by multiplying that per-CU rate by each SKU's CU count from the documented SKU→CU map (Fn = n CUs, e.g. F64 = 64, F128 = 128, F256 = 256, F512 = 512, F1024 = 1024, F2048 = 2048, F4096 = 4096, F8192 = 8192).

Convert each reservationTerm bucket to a monthly figure correctly (the reservation rows are term totals, not hourly rates):

• PAYG monthly = consumptionCuHourRate × skuCUs × 730 (Consumption row, priceType eq 'Consumption', meterName like * Capacity Usage CU)
• 1-Year RI monthly = reservationRetailPrice × skuCUs ÷ 12 (do not multiply by 730)
• 3-Year RI monthly = reservationRetailPrice × skuCUs ÷ 36

See the monthly conversion guidance in resources/pricing-api-reference.md.

Step 4: Present to User

Present the pricing table with the region explicitly stated:

Fabric Capacity Pricing — Region: [detected_region] (live as of [today's date])

| SKU | CUs | Monthly PAYG | 1-Year RI | 3-Year RI | RI Savings |
|-----|-----|-------------|-----------|-----------|------------|
| F4  | 4   | $[live]     | $[live]   | $[live]   | [calc]%    |
| ... | ... | ...         | ...       | ...       | ...        |

Source: Azure Retail Prices API (prices.azure.com)

IMPORTANT: If the API is unreachable, inform the user and direct them to the Azure Pricing Calculator. Never fall back to hardcoded prices — they go stale.

---

Capacity Unit Reference

CU Consumption by Workload

| Workload | CU Consumption Model | Key Metric | |---|---|---| | Spark (notebooks, SJD) | CU-seconds during active Spark session | vCores × duration | | SQL DW (warehouse queries) | CU-seconds per query | Query complexity × data scanned | | Power BI (semantic models, reports) | CU-seconds per query/refresh | Dataset size, refresh frequency, DAX complexity | | Data Pipelines | CU-seconds per activity execution | Activity type, data volume moved | | Eventhouse / KQL | CU-seconds per query + ingestion | Ingestion rate, query frequency | | Dataflows Gen2 | CU-seconds per refresh | Transform complexity, data volume | | OneLake | Storage only (no CU for at-rest) | GB stored |

Spark CU Mapping (Critical for Migration)

Documented conversion: 1 Fabric CU = 2 Spark vCores (Fabric Spark concurrency limits). So a node's CU equivalent is vCores ÷ 2. The vCore counts below are pool node defaults; always validate effective consumption via a pilot before committing to SKU sizing.

| Spark Pool Node Size | vCores | Memory | CU Equivalent per Node (vCores ÷ 2) | |---|---|---|---| | Small | 4 vCores | 32 GB | 2 CUs | | Medium | 8 vCores | 64 GB | 4 CUs | | Large | 16 vCore