.png){kind=small}
Microsoft Fabric Kosten verstehen
Aktualisiert: 27. Aug.
Microsoft Fabric Kosten lassen sich nicht sinnvoll über eine einzelne Preistabelle bewerten. Eine F-SKU ist nur ein Teil der Rechnung. Power-BI-Lizenzen, OneLake-Speicher, Workload-Verbrauch und inzwischen auch separate Modelle wie Spark Autoscale Billing oder Capacity Overage können zusätzlich relevant werden. Wer deshalb nur fragt „Welche F-SKU brauchen wir?“, startet die Kostenplanung an der falschen Stelle.
Der entscheidende Punkt für Unternehmen lautet: Fabric ist kein klassisches Lizenzprodukt mit einem festen Preis pro Nutzer. Es ist eine Analytics-Plattform mit mehreren miteinander verbundenen Kosten- und Verbrauchsebenen.
Wer diese Ebenen auseinanderhält, kann Kosten deutlich besser planen und steuern.
Die fünf Kostenebenen von Microsoft Fabric
Für eine belastbare Kostenrechnung lässt sich Fabric in fünf Ebenen betrachten. Diese Trennung verhindert einen der häufigsten Denkfehler: Der Preis der Kapazität ist nicht automatisch gleich den Gesamtkosten von Fabric.
Fabric-Kapazität: der gemeinsame Compute-Pool
F-SKUs reichen von F2 bis zu sehr großen Kapazitäten. Jede SKU stellt eine bestimmte Anzahl Capacity Units bereit. Diese CUs werden von den verschiedenen Fabric-Workloads gemeinsam genutzt.
Power BI, Warehouse, Lakehouse, Data Factory, Data Engineering und weitere Fabric-Erlebnisse konkurrieren damit grundsätzlich um denselben Compute-Pool.
Microsoft bietet F-Kapazitäten nutzungsabhängig über Azure an. Kapazitäten lassen sich skalieren sowie pausieren und später wieder fortsetzen. Wird eine Kapazität pausiert, endet der Compute-Verbrauch; der OneLake-Speicher wird jedoch weiterhin berechnet.
Reservierungen können die Compute-Kosten gegenüber Pay-as-you-go deutlich reduzieren. Microsoft nennt auf der aktuellen Azure-Preisseite eine mögliche Ersparnis von ungefähr 41 Prozent gegenüber PAYG. Die konkreten Preise hängen von Region, SKU und Vertragsmodell ab.
Damit wird bereits deutlich: Eine dauerhaft ausgelastete Produktionskapazität sollte anders kalkuliert werden als eine Entwicklungs- oder Projektkapazität, die nur zeitweise benötigt wird.
Warum 100 Prozent Auslastung nicht automatisch ein Problem sind
Fabric verhält sich beim Kapazitätsverbrauch anders als viele klassische Servermodelle.
Mit Bursting darf ein Workload kurzfristig mehr Compute nutzen, als die nominelle SKU bereitstellt. Mit Smoothing verteilt Fabric diesen Verbrauch anschließend über einen längeren Zeitraum.
Interaktive Operationen werden mindestens über einige Minuten geglättet, Hintergrundoperationen können über bis zu 24 Stunden verteilt werden. Dadurch kann Fabric kurze Leistungsspitzen abfangen, ohne dass sofort eine größere SKU benötigt wird.
Deshalb ist eine Capacity-Metrics-Anzeige oberhalb von 100 Prozent nicht automatisch gleichbedeutend mit einem kaputten oder zu kleinen System. Entscheidend ist, ob langfristig mehr Compute verbraucht wird, als die Kapazität wieder abbauen kann.
Wann Fabric tatsächlich throttelt
Fabric erlaubt zunächst einen gewissen Verbrauch zukünftiger Kapazität.
Microsoft unterscheidet dabei drei relevante Schwellen: Nach ungefähr zehn Minuten zukünftiger Kapazitätsauslastung können interaktive Operationen verzögert werden. Bei etwa einer Stunde können interaktive Requests abgelehnt werden. Bei einer Belastung, die mehr als 24 Stunden zukünftiger Kapazität bindet, können schließlich auch Hintergrundoperationen abgelehnt werden.
Das verändert die Kapazitätsplanung fundamental. Nicht jeder Peak rechtfertigt eine größere SKU. Wiederkehrende Carryforward-Last und Throttling sind dagegen ein echtes Signal, Architektur oder Sizing zu überprüfen.
Capacity Overage: teurer Puffer statt reguläres Sizing
Mit Fabric Capacity Overage kann eine Kapazität bei Überlast automatisch zusätzliche CUs bereitstellen und dadurch verhindern, dass Fabric Requests throttelt oder ablehnt. Die Funktion befindet sich derzeit in Preview.
Der Komfort ist teuer: Overage-CUs werden laut Microsoft mit dem Dreifachen des normalen Pay-as-you-go-Tarifs berechnet.
Capacity Overage sollte deshalb nicht als Dauerlösung betrachtet werden. Ein sinnvoller Einsatz wäre beispielsweise ein geschäftskritischer Monatsabschluss mit seltenen, unvorhersehbaren Peaks. Wenn Overage dagegen regelmäßig benötigt wird, ist ein größeres SKU, eine getrennte Kapazität oder eine Optimierung der Workloads häufig wirtschaftlicher.
Surge Protection verfolgt die umgekehrte Strategie
Während Capacity Overage zusätzliche Kapazität einkauft, versucht Surge Protection problematische Last frühzeitig zu begrenzen.
Administratoren können Hintergrundoperationen früher stoppen oder Workspace-Verbrauch begrenzen, bevor eine gesamte Capacity tief ins Throttling läuft. Damit kann verhindert werden, dass ein einzelner Workspace einen unverhältnismäßig großen Teil des Compute-Budgets verbraucht.
Für größere Plattformen wird damit Kostensteuerung zunehmend zu echter Workload Governance.
Spark kann einen eigenen Kostenpfad bekommen
Data Engineering und Data Science sind häufig schwer planbar. Ein großes Notebook oder ein intensiver Spark-Job kann kurzzeitig deutlich mehr Rechenleistung benötigen als der normale Plattformbetrieb.
Dafür bietet Microsoft Autoscale Billing for Spark. Ist diese Option aktiviert, laufen Spark-Jobs nicht mehr auf der gemeinsam genutzten Fabric-Kapazität. Sie nutzen dedizierte serverlose Ressourcen und werden Pay-as-you-go abgerechnet.
Das kann wirtschaftlich sinnvoll sein, wenn Spark-Last stark schwankt. Eine dauerhafte stabile Spark-Workload ist dagegen möglicherweise günstiger innerhalb der regulären Capacity.
Damit entsteht eine echte Workload-Entscheidung: Shared Capacity oder separater verbrauchsabhängiger Compute?
Power BI Pro, PPU und F64 bleiben Teil der Rechnung
Fabric ersetzt Power-BI-Benutzerlizenzen nicht automatisch.
Bei F-SKUs unterhalb F64 benötigen Konsumenten von Power-BI-Inhalten grundsätzlich weiterhin eine geeignete Benutzerlizenz. Ab F64 können Benutzer mit einer Fabric-Free-Lizenz Power-BI-Inhalte konsumieren, wenn die Inhalte vollständig in einer entsprechenden Kapazität liegen und der Nutzer die passende Viewer-Berechtigung besitzt.
PPU ist ebenfalls kein Ersatz für eine Fabric Capacity. PPU bietet Premium-Power-BI-Funktionen pro Nutzer, provisioniert aber keine Fabric-Kapazität für Lakehouses, Warehouses oder Notebooks.
Gerade bei vielen reinen Reportkonsumenten kann die Grenze F64 deshalb einen erheblichen Einfluss auf die Gesamtkosten haben.
OneLake-Speicher kostet unabhängig von Compute
Ein weiterer Punkt wird häufig übersehen: OneLake Storage ist nicht einfach Bestandteil des CU-Pools.
Gespeicherte Daten werden nutzungsabhängig pro GB abgerechnet und verbrauchen selbst keine Fabric Capacity Units. Lese-, Schreib- und andere OneLake-Operationen können dagegen CUs verbrauchen.
OneLake unterstützt inzwischen Hot-, Cool- und Cold-Storage-Tiers. Daten, die nur selten benötigt werden, können damit günstiger gespeichert werden. Lifecycle-Regeln können historische Daten automatisiert in günstigere Ebenen verschieben.
Damit wird auch Data Lifecycle Management zu einem Kostenhebel.
Mirroring ist kostenseitig ein Sonderfall
Microsoft macht Core Mirroring bewusst attraktiv. Die Compute-Leistung für die eigentliche Replikation nach OneLake verbraucht grundsätzlich keine Fabric Capacity. Außerdem steht für Mirroring ein kapazitätsabhängiger kostenloser Speicheranteil zur Verfügung.
Abfragen auf diesen Daten über SQL, Spark oder Power BI verbrauchen dagegen wieder reguläre Kapazität. Zusätzliche Mirroring-Funktionen wie Delta Change Data Feed oder bestimmte View-Funktionen können separat nutzungsabhängig abgerechnet werden.
„Mirroring ist kostenlos“ ist deshalb genauso verkürzt wie „Mirroring kostet“.
Copilot und AI verbrauchen ebenfalls Capacity
Mit der zunehmenden Nutzung von KI wird noch ein weiterer Verbrauch relevant.
Copilot in Fabric wird über die Anzahl der verarbeiteten Tokens in Capacity Units umgerechnet. Microsoft unterscheidet dabei Input-, gecachte Input- und Output-Tokens; Output-Tokens verbrauchen deutlich mehr CUs als Input-Tokens.
Bei intensiver Nutzung von Copilot, AI-Funktionen oder agentischen Szenarien sollte dieser Verbrauch deshalb genauso überwacht werden wie Refreshes, Pipelines oder Warehouse-Abfragen.
Die zentrale Kostenfrage verschiebt sich damit weiter: Nicht „Welche Features haben wir lizenziert?“, sondern „Welche Workloads verbrauchen tatsächlich Capacity?“
Die Capacity Metrics App wird zum Controlling-Instrument
Die Microsoft Fabric Capacity Metrics App zeigt Verbrauch nach Kapazität, Item und Operation und hilft zu erkennen, welche Workloads Compute verbrauchen, welche Kapazitäten throtteln und wo Optimierung oder Skalierung sinnvoll sein könnte.
Eine Capacity sollte deshalb nicht einmal dimensioniert und anschließend vergessen werden.
Ein sinnvoller Betriebszyklus lautet: messen → Ursachen analysieren → optimieren → Workloads verschieben → erst danach skalieren.
Das ist meist wirtschaftlicher als reflexartig die nächsthöhere SKU zu kaufen.
Wann eine größere SKU tatsächlich sinnvoll ist
Eine größere Kapazität ist dann sinnvoll, wenn eine gut optimierte Plattform regelmäßig mehr Compute benötigt, als die aktuelle Capacity bereitstellen kann.
Sie ist weniger sinnvoll, wenn ein einziges schlecht modelliertes semantisches Modell, ein ineffizientes Notebook oder redundante Pipelines die gesamte Capacity belasten.
Microsoft empfiehlt deshalb, Capacity-Sizing zunächst über reale Workloads zu messen und beispielsweise mit PAYG-Kapazitäten Erfahrungen zu sammeln, bevor längerfristige Commitments eingegangen werden.
Damit wird Kostenoptimierung gleichzeitig zu Architekturarbeit.
Fazit: Fabric-Kosten sind ein Betriebsmodell
Microsoft Fabric hat kein einzelnes Kostenmodell.
Die Basis bildet die Fabric Capacity. Hinzu kommen je nach Architektur Power-BI-Benutzerlizenzen, OneLake-Speicher sowie zusätzliche verbrauchsabhängige Komponenten wie Copilot, Spark Autoscale Billing, Mirroring-Erweiterungen oder Capacity Overage.
Die entscheidende Frage lautet deshalb nicht: „Was kostet eine F64?“ Sondern: „Welche Workloads wollen wir betreiben, wie viel Capacity verbrauchen sie – und welche davon gehören überhaupt in denselben gemeinsamen Compute-Pool?“
Erst daraus entsteht eine belastbare Kostenrechnung.
Der nächste sinnvolle Schritt
Wenn ihr Microsoft Fabric einführen oder eine bestehende Capacity wirtschaftlicher betreiben möchtet, sollten Use Cases, Architektur, Power-BI-Lizenzierung, Capacity-Verbrauch und Betriebsmodell gemeinsam betrachtet werden.
In unserer Microsoft-Fabric-Beratung betrachten wir genau dieses Zusammenspiel – vom Sizing über Workload-Architektur bis zur laufenden Kosten- und Capacity-Steuerung.
