Microsoft Fabric Kapazität: So planst du Kosten, Größe und Spielregeln

Definition

Eine Microsoft Fabric Kapazität ist ein dedizierter Ressourcenpool im Tenant, der Rechenleistung für Fabric- und Power-BI-Workloads bereitstellt und über F-SKUs (F2–F2048) skaliert. Sie ist kein einzelnes Produktfeature und auch keine „User-Lizenz“, sondern die gemeinsame Compute-Basis für Workspaces und deren Workloads.

Einleitung

Wenn Berichte langsam werden, Pipelines in der Warteschlange hängen oder Teams Angst vor der nächsten Kostenrechnung haben, steckt fast immer Kapazitätsplanung dahinter. Mit der richtigen Microsoft Fabric Kapazität bekommst du ein klares Betriebsmodell: Wer darf was, wie viel Compute steht wirklich zur Verfügung, und welche Kosten sind planbar. Der Artikel sortiert die Begriffe, die Abrechnung und zeigt, wie du pragmatisch zur passenden Größe kommst.

Wie Fabric-Kapazität funktioniert: CUs, SKUs und Workspaces

Fabric rechnet Compute über Capacity Units (CU) ab. Eine F-SKU entspricht einem CU-Level (z. B. F2 = 2 CU, F64 = 64 CU). Diese CUs stehen allen Workloads in den zugewiesenen Workspaces zur Verfügung: klassische Power-BI-Berichte genauso wie Data Engineering, Lakehouse/Warehouse oder Data Pipelines.

Der praktische Nutzen: Du musst nicht für jedes Team eine eigene Insel bauen. Stattdessen kannst du eine Plattform bereitstellen, auf der auch Nicht-IT-affine Nutzer auf „Gold-Daten“ zugreifen und in Power BI oder Excel direkt loslegen, ohne dass jede Auswertung als Einzelprojekt endet.

Abrechnungsmodelle: Pay-as-you-go (PayGo) vs. Reservierung

Für die Kostenlogik sind zwei Modelle entscheidend:

• Pay-as-you-go (PayGo): nutzungsbasiert über Azure; sinnvoll für Tests, Aufbauphasen und schwankende Last. Vorteil: Kapazität kann skaliert oder (je nach Setup) pausiert werden.
• Reserved / Reservierung (Reserved Instance): feste Laufzeit, dafür bessere Planbarkeit und typischerweise günstiger, wenn die Kapazität dauerhaft läuft.

Entscheidungsregel: Wenn ihr täglich produktive Workloads betreibt und die Kapazität „immer an“ ist, lohnt sich eine Reservierung oft schneller als man denkt. Wenn ihr dagegen erst migriert, Proofs baut oder Lastspitzen habt (z. B. Monatsabschluss), ist PayGo häufig der bessere Start.

Compute-Kosten vs. Speicher: OneLake und SQL-Speicher verständlich

In Fabric werden Compute und Speicher getrennt betrachtet. Die Kapazität (F-SKU) zahlt primär für Rechenleistung: Refreshes, Transformationen, Abfragen, parallele Nutzerzugriffe, Hintergrundprozesse.

Speicher kostet zusätzlich – und zwar dort, wo Daten dauerhaft liegen. OneLake ist dabei der zentrale Speicher für Fabric (Lakehouse, Files, Tabellen). Der Mehrwert ist nicht „noch ein Data Lake“, sondern ein gemeinsamer Datenort, auf den Fachbereiche kontrolliert zugreifen können: „eine Wahrheit“, weniger Excel-Kopien, weniger Streit über KPI-Definitionen.

SQL-Speicher (z. B. im Fabric Warehouse) ist für typische BI-Fragen relevant, wenn ihr bewusst auf SQL-Modelle setzt oder viele Abfragen über strukturierte Tabellen laufen. In der Budgetplanung solltest du deshalb getrennt schätzen: (1) Compute der Kapazität, (2) GB-Monat Speicher in OneLake/SQL, (3) Wachstum pro Monat.

Overages und Grenzwerte: Was passiert bei Überlast?

„Fabric Capacity Overage“ meint vereinfacht: Eure Workloads wollen mehr Compute, als die Kapazität hergibt. Dann zeigen sich typische Symptome: längere Laufzeiten, Warteschlangen, Timeouts, unzuverlässige Refresh-Fenster oder unzufriedene Nutzer, weil Reports zu Stoßzeiten zäh werden.

Wichtiger als die Theorie ist die Reaktion:

• Scale up: kurzfristig höhere SKU (mehr CU) für Stabilität, z. B. um ETL-Last und Reporting gleichzeitig zu tragen.
• Workloads trennen: kritische Berichte in eigene Workspaces/Kapazitäten, damit sie nicht von Pipelines „weggedrückt“ werden.
• Optimieren: Datenmodell, Refresh-Strategie, Direct Lake/Import-Entscheidung, unnötige parallele Jobs reduzieren.

Die Kennzahlen dafür liefert die Fabric Capacity Metrics App: Sie zeigt, welche Workspaces und Workloads die CUs verbrauchen und ob ihr dauerhaft am Limit fahrt.

Benchmark: Welche Kapazität passt zu welchem Nutzungsmodell?

Für eine erste Einordnung helfen drei Modelle statt „irgendwas mit F4“:

• Starter: wenige Ersteller, kleines Datenvolumen, Fokus auf 1–2 Berichte und erste Pipelines. Ziel: Lernen, Messen, Architektur sauber setzen.
• Business: mehrere Teams, regelmäßige Refreshes, stabile Datenprodukte (Gold-Layer), Standard-Reporting plus erste Self-Service-Use-Cases.
• Enterprise: hohe Parallelität, mehrere Domänen, klare Trennung von kritischen Workloads, Dev/Test/Prod und Governance als Pflicht.

Wichtig: Die passende Größe hängt weniger an der Mitarbeiterzahl als an (a) Anzahl gleichzeitiger Nutzer, (b) Datenvolumen und Wachstum, (c) Komplexität der Transformationen, (d) Taktung der Refreshes, (e) ob ihr Data Engineering und BI auf derselben Kapazität bündelt.

Kalkulationshilfe: So baust du einen Budget-Plan (ohne Ratespiel)

Ein belastbarer Budget-Plan entsteht in drei Schritten:

• Workload-Liste erstellen: Welche Berichte, welche Pipelines, welche Datenquellen, welcher Refresh-Takt, welche Peak-Zeiten (z. B. Monatsabschluss)?
• Trial + Messen: Mit einer Testversion bzw. kostenlosen Trials starten, Workspaces zuweisen und reale CU-Nutzung über Metrics beobachten.
• Preisrechner nutzen: Im Azure-Preisrechner Region, SKU und Laufzeitmodell (PayGo vs. Reservierung) durchspielen; Speicher (GB/Monat) separat ansetzen.

So beantwortest du ROI-Fragen sauber: Nicht „Fabric ist teuer“, sondern „so viel manuelle Excel-Konsolidierung fällt weg, so stabil werden Refreshes, so viele Stunden sparen Teams pro Monat“. Das ist messbar, wenn ihr vorher den Ist-Aufwand dokumentiert.

Mini-Beispiel aus der Praxis

Ein Team konsolidiert ERP-, CRM- und Excel-Listen monatlich manuell, baut daraus Power-BI-Berichte und kämpft mit inkonsistenten Zahlen. Mit Fabric wird ein Gold-Datenprodukt in OneLake aufgebaut und die Refreshes zentral geplant; Fachbereiche nutzen dieselben Daten für Power BI und Excel. Ergebnis: weniger Abstimmungsrunden, verlässliche KPI-Definitionen und deutlich weniger „ich pflege noch schnell eine Tabelle“-Arbeit.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn ihr eine dieser Situationen habt:

• Budgetdruck: Ihr braucht schnell einen belastbaren Kapazitäts- und Kostenplan (inkl. PayGo vs. Reservierung) und wollt Überraschungen vermeiden.
• Migrationsdruck: Ihr kommt von Tableau, Qlik oder einer SQL-/DWH-Welt und müsst entscheiden, wie viel in Fabric gehört und wie ihr ohne Big Bang umstellt.
• Betriebsrisiko: Overages, instabile Refreshes oder unklare Verantwortlichkeiten zwischen IT und Fachbereich.

Dann geht es weniger um „Setup klicken“, sondern um eine saubere Zielarchitektur, klare Governance für Workspaces und ein Kapazitätsdesign, das Report-Performance und Data Engineering gleichzeitig tragen kann.