Microsoft Fabric-Kapazitätseinheiten erklärt: Ein Leitfaden zu F-SKUs und Carry-Forward-Schulden

Von Mirko Peters · 2026-10-29

Erfahren Sie, wie Microsoft Fabric-Kapazitätseinheiten, F-SKUs, Glättung und Carry-Forward-Schulden M365-Administratoren betreffen. Meistern Sie noch heute die Governance Ihrer Cloud-Rechenleistung.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Microsoft Fabric-Kapazitätseinheiten (CUs) bestimmen die Rechenleistung, die Leistungsgrenzen und die Abrechnung für Ihren gesamten Mandanten. Anders als bei klassischen Azure-Ressourcen mit isolierten Ressourcengruppen bündelt Fabric alle Workloads für Data Engineering, Data Warehousing und Berichterstellung in einem einzigen gemeinsamen Rechenpool. Dieser unterliegt den Regeln für F-SKUs, Burst-Grenzen und Carry-Forward-Schulden.

Das Wichtigste in Kürze

• Fabric-Kapazitätseinheiten messen die Rechenarbeit pro Sekunde über alle Arbeitsbereiche hinweg und fungieren als gemeinsamer Abrechnungs- und Leistungspool.
• F-SKUs (F2 bis zu Kapazitäten höherer Stufen) ersetzen die bisherigen Power BI Premium-Kapazitäten und lassen sich in Azure flexibel pausieren, um Kosten zu sparen.
• Bursting erlaubt eine vorübergehende Überbelegung der Rechenleistung, erzeugt jedoch Carry-Forward-Schulden, die über die Zeit zurückgezahlt werden müssen.
• Hintergrundaufträge nutzen ein 24-Stunden-Glättungsfenster, während interaktive Benutzerabfragen über wenige Minuten geglättet werden.
• Die Fabric-Kapazitätsmetriken-App ist unverzichtbar, um die Auslastung zu überwachen, die größten Ressourcenverbraucher zu identifizieren und proaktive Warnungen einzurichten.

Was ist eine Microsoft Fabric-Kapazität?

Wenn Microsoft Fabric in Ihrem Microsoft 365-Mandanten erscheint, kommt es nicht als Sammlung isolierter virtueller Maschinen oder segmentierter Azure-Abonnements. Stattdessen führt es einen einheitlichen Rechenpool ein, die sogenannte Kapazität. Dieser Pool wird in Kapazitätseinheiten (CUs) gemessen und versorgt jede Phase Ihres Datenplattform-Lebenszyklus: Ereignisaufnahme, Reasoning und Orchestrierung.

Für M365- und Plattformadministratoren ist das Verständnis dieses Modells entscheidend. Mehrere Arbeitsbereiche – oft aus verschiedenen Abteilungen – greifen auf denselben Kapazitätspool zu. Startet ein Data-Engineering-Team in der Finanzabteilung einen aufwendigen Notebook-Auftrag, verbraucht dieser Recheneinheiten, die sonst ein Marketing-Dashboard versorgen würden. Die Kapazität wirkt als gemeinsame Ressource und schafft einen Wirkungsradius, in dem rechenintensive Aufträge in einem Arbeitsbereich die Leistung völlig unabhängiger Geschäftsbereiche direkt beeinflussen.

F-SKUs, P-SKUs und Testkapazitäten im Überblick

Bei der Wahl der passenden Kapazitätsstufe müssen Sie drei unterschiedliche SKU-Familien berücksichtigen. Jede bringt für IT-Administratoren andere betriebliche Konsequenzen mit sich:

• F-SKUs (Mainline): Diese Mainline-SKUs werden direkt über Azure als F2, F4, F8 und höher erworben. Sie können stündlich bezahlt oder über Reservierungen zugesagt werden. Entscheidend ist, dass sie das Pausieren und Fortsetzen unterstützen, um Ausgaben außerhalb der Betriebszeiten zu optimieren.
• P-SKUs (Legacy): Diese älteren Power BI Premium-Kapazitäten werden von Microsoft nicht mehr verkauft. Hat Ihr Mandant eine P-SKU übernommen, läuft sie in einem Legacy-Pfad, der einen geplanten Migrationsweg erfordert.
• Testkapazitäten: Kostenlose Kapazitäten höherer Stufe (grob vergleichbar mit einer F64), die nach einer festgelegten Dauer ablaufen. Da häufig jeder berechtigte Benutzer eine Testversion starten kann, stellen sie einen administrativen blinden Fleck dar: Geschäftskritische Pipelines können unbemerkt von einer temporären Ressource abhängen.

So funktionieren Glättung, Bursting und Carry-Forward-Schulden

Rechenintensive Workloads in Microsoft Fabric werden nicht sofort blockiert, sobald sie das gekaufte Kapazitätslimit überschreiten. Stattdessen setzt die Plattform auf ausgefeilte Mechanismen namens Bursting und Smoothing, um kurzfristige Lastspitzen abzufangen.

Smoothing bei interaktiven und Hintergrundvorgängen

Benötigt ein umfangreicher Auftrag für kurze Zeit viel Rechenleistung, erlaubt Fabric, dass er die gekaufte SKU-Größe übersteigt. Um eine sofortige Drosselung zu verhindern, glättet die Plattform die Last über die Zeit mithilfe eines Smoothing-Algorithmus:

• Interaktive Vorgänge: Benutzergesteuerte Aufgaben, etwa das Öffnen eines Berichts oder das Ausführen einer manuellen Abfrage, werden über ein kurzes Zeitfenster von wenigen Minuten geglättet, damit die Reaktionszeit erhalten bleibt.
• Hintergrundvorgänge: Geplante Datenaktualisierungen, automatisierte Pipeline-Ausführungen und nächtliche Notebooks werden über ein vollständiges 24-Stunden-Fenster geglättet. Dadurch wirken sie sich deutlich weniger auf Benutzer aus, die in Echtzeit arbeiten.

Die Auswirkungen des Carry-Forward-Defizits

Bursting ist nicht kostenlos. Verbraucht ein Vorgang mehr Einheiten, als Ihre Kapazität bereitstellt, wird der Überschuss als Carry-Forward-Defizit verbucht. Dieses Defizit muss in künftigen Rechenzyklen ausgeglichen werden. Ein nicht optimierter Hintergrundauftrag, der am Montagnachmittag läuft, kann so ein Defizit aufbauen, das am Mittwochmorgen interaktive Berichte drosselt. Die Folge ist ein schwer erklärbarer Leistungseinbruch, der Endbenutzer ratlos zurücklässt.

Überwachung und Steuerung von Kapazitäten

Symptome (langsame Berichte) und Ursachen (außer Kontrolle geratene Datenmodelle) liegen häufig zeitlich und über Arbeitsbereichsgrenzen hinweg auseinander. Administratoren benötigen daher spezielle Werkzeuge, um den Überblick zu behalten. Die Microsoft Fabric Capacity Metrics App, die über AppSource verfügbar ist, dient als zentrales Diagnose-Dashboard.

Kapazitätsadministratoren können mit dieser App die Auslastungstrends in Echtzeit prüfen, die Entwicklung des Carry-Forward-Defizits verfolgen und die größten Verbraucher identifizieren, etwa bestimmte semantische Modelle, Pipelines oder Notebooks. Außerdem stellen Warnschwellen bei etwa 80 % Auslastung sicher, dass IT-Teams benachrichtigt werden, bevor es zu Drosselungen oder Fehlern für Benutzer kommt. So wechselt die Administration von reaktiver Feuerwehrarbeit zu proaktiver Governance.

Fazit

Die Verwaltung von Microsoft-Fabric-Kapazitäten erfordert den Wechsel von der klassischen Workload-Isolation hin zu einer ganzheitlichen Plattform-Governance. Wer die Dimensionierung der F-SKUs im Blick behält, das Carry-Forward-Defizit überwacht und die größten Ressourcenverbraucher über die Capacity Metrics App prüft, kann eine planbare Performance sicherstellen und die Cloud-Kosten wirksam steuern.

Wenn Sie tiefer in die Aufgaben von Administratoren, Arbeitsbereiche und die Sicherheitsgrenzen des Mandanten einsteigen möchten, hören Sie sich die vollständige Folge des M365 FM Podcasts an. Dort finden Sie fundierte Einblicke und praxisnahe Strategien.

Häufige Fragen

Was ist eine Kapazitätseinheit (Capacity Unit, CU) in Microsoft Fabric?

Eine Kapazitätseinheit ist ein gebündeltes Maß für Rechenleistung, mit der alle Microsoft-Fabric-Workloads in Ihren zugewiesenen Arbeitsbereichen betrieben werden, einschließlich Ereignisaufnahme, Schlussfolgerung und Orchestrierung.

Kann ich F-SKUs von Microsoft Fabric pausieren, um Kosten zu sparen?

Ja. F-SKUs, die über Azure erworben wurden, lassen sich pausieren und wieder fortsetzen. Dadurch wird die Abrechnung der Rechenleistung gestoppt, wenn Ressourcen ungenutzt sind, etwa über Nacht oder am Wochenende. Berücksichtigen Sie dabei allerdings ein noch offenes Carry-Forward-Defizit.

Was verursacht ein Carry-Forward-Defizit in Fabric?

Ein Carry-Forward-Defizit entsteht, wenn Arbeitsbereiche ihre gekauften Kapazitätsgrenzen überschreiten. Die zusätzlich verbrauchte Rechenleistung wird als Defizit erfasst, das in künftigen Kapazitätszyklen ausgeglichen werden muss. Dadurch kann die Leistung vorübergehend gedrosselt werden.

Worin unterscheiden sich Hintergrund- und interaktive Workloads in Fabric?

Interaktive Workloads (benutzergesteuerte Klicks in Berichten) werden über ein kurzes Zeitfenster von wenigen Minuten geglättet, während Hintergrund-Workloads (geplante Aktualisierungen und nächtliche Pipelines) über ein 24-Stunden-Fenster geglättet werden, um Störungen zu minimieren.