.png){kind=small}
Power BI Embedded richtig planen
Aktualisiert: 27. Aug.
Power BI Embedded klingt zunächst einfach: Bericht bauen, in eine Anwendung einbetten, fertig. In produktiven Projekten entscheidet aber nicht der iFrame über Erfolg oder Misserfolg. Entscheidend sind Nutzergruppe, Authentifizierung, Mandantentrennung, Capacity und Betriebsmodell. Wer zuerst über A1, F64 oder Pro diskutiert, beginnt deshalb meistens am falschen Ende.
Power BI Embedded ist weniger eine einzelne Technologie als eine Architekturentscheidung darüber, wie Analytics ausgeliefert wird. Die zentrale Frage lautet: Wer greift auf die Analytics zu – und wer besitzt gegenüber Power BI die Identität?
Drei Arten, Power BI einzubetten
Secure Embed: für einfache interne Portale, bei denen Power-BI-Rechte bestehen bleiben und keine eigene Produkt-UX nötig ist.
Embed for your organization / User owns data: für interne Anwendungen mit Microsoft-Entra-Login; Power BI kennt den Benutzer und prüft seine Berechtigungen.
Embed for your customers / App owns data: für Kundenportale, Partnerlösungen und SaaS; die Anwendung authentifiziert sich gegenüber Power BI, Endnutzer benötigen keinen Power-BI-Login.
Secure Embed: wenn ein iFrame tatsächlich reicht
Secure Embed ist die einfachste Variante. Der Bericht wird über eine sichere URL beziehungsweise einen iFrame in eine Website oder ein Portal eingebunden. Die eigentlichen Zugriffsrechte bleiben im Power BI Service bestehen.
Benutzer verwenden Power BI bereits
keine individuelle Produkt-UX erforderlich
Power-BI-Berechtigungen bleiben maßgeblich
geringer Entwicklungsaufwand
Embed for your organization: Benutzer besitzt die Identität
Bei User owns data meldet sich der Benutzer mit seiner eigenen Microsoft-Entra-Identität an. Power BI kennt den Benutzer und prüft seine Berechtigungen auf die Inhalte. Das Modell passt vor allem zu internen Anwendungen wie CRM, Intranet, Produktionsportal oder Fachanwendung.
Bei kleineren F-SKUs oder A-SKUs brauchen Nutzer weiterhin eine geeignete Power-BI-Lizenz. Erst große geeignete Kapazitäten – insbesondere F64+ beziehungsweise bestehende P-Kapazitäten – verändern die Viewer-Lizenzlogik.
Embed for your customers: die Anwendung besitzt den Zugriff
Bei App owns data authentifiziert sich der Anwender gegenüber eurer Anwendung, nicht gegenüber Power BI. Die Anwendung authentifiziert sich anschließend gegenüber Power BI und erzeugt ein Embed Token. Endnutzer benötigen dabei weder einen Power-BI-Login noch eine Power-BI-Lizenz.
Vereinfacht: Nutzer → eure App → Entra / Service Principal → Power BI API → Embed Token → Report
Die Kernaussage des Entscheidungswegs lautet: Nutzer → Identität → Security → Capacity – in dieser Reihenfolge planen.
Service Principal statt Master User
Für neue produktive App-owns-data-Lösungen ist ein Service Principal der sauberere Ausgangspunkt. Er bildet eine Anwendungsidentität in Microsoft Entra ID ab und vermeidet ein technisches Benutzerkonto mit Passwort.
Embed Token und Entra Token sind nicht dasselbe
Die Anwendung authentifiziert sich zunächst gegenüber Microsoft Entra ID und erhält ein Access Token. Mit diesem Token ruft sie Power BI auf und erzeugt anschließend ein Embed Token für die konkrete Einbettung.
erlaubte Reports und semantische Modelle
Zugriffsebene
RLS-Identitäten
gegebenenfalls Schreib- oder SaveAs-Rechte
Token-Handling ist kein Frontend-Detail, sondern Teil der Betriebsarchitektur.
Multi-Tenant: RLS oder getrennte Workspaces?
Gemeinsames Modell + RLS
Alle Kunden arbeiten auf demselben Modell. Die Anwendung übergibt beim Embed-Token eine effektive Identität; RLS filtert auf den jeweiligen Kunden. Das reduziert Artefakte und vereinfacht Deployment, erhöht aber die Bedeutung einer fehlerfreien Security-Logik.
Workspace-Isolation
Jeder Kunde erhält einen eigenen Workspace beziehungsweise eigene Modelle und Reports. Service Principal Profiles können unterschiedliche Kundenidentitäten repräsentieren. Das schafft stärkere Sicherheitsgrenzen, erzeugt aber mehr Artefakte.
RLS skaliert Artefakte. Workspace-Isolation skaliert Sicherheitsgrenzen.
RLS funktioniert bei App-owns-data anders als im normalen Service
Bei App-owns-data bestimmt die Anwendung die effektive Identität, die beim Token-Request an Power BI übergeben wird. Euer Backend entscheidet damit, welcher Kunde welche RLS-Identität erhält. Ein Fehler in dieser Logik kann zu einem Cross-Tenant-Security-Problem werden.
A-SKU oder F-SKU?
A-SKU (Azure): spezialisiert auf Power BI Embedded, skalierbar und pausierbar, aber ohne die weiteren Fabric-Workloads.
F-SKU (Fabric): Power BI Embedded plus Fabric-Workloads wie Lakehouse, Warehouse, Data Engineering oder Data Factory – sinnvoll, wenn Embedded Teil einer größeren Fabric-Plattform ist.
Wichtig: A-SKUs sind nicht ausschließlich App-owns-data vorbehalten. Sie können technisch auch für Embed for your organization eingesetzt werden. Das macht sie aber nicht automatisch zur wirtschaftlich besten Wahl für interne Szenarien.
Capacity Planning: Nutzerzahl allein reicht nicht
Die Frage „Wie viele Nutzer passen auf A2 oder F32?“ lässt sich nicht seriös allein über Benutzerzahlen beantworten. Entscheidend sind Datenmodellgröße, Query-Komplexität, parallele Nutzung, zeitliche Lastverteilung, Refreshes und zusätzliche Workloads.
Capacity Planning ist ein Lastproblem, kein Lizenzzählproblem.
Erst optimieren, dann Last testen, dann skalieren
Reports und semantische Modelle optimieren
Mindest-SKU bestimmen
repräsentative Last testen
Capacity-Auslastung auswerten
Skalierungs- und Monitoringmodell definieren
Eine größere Capacity heilt nicht automatisch ineffiziente DAX-Measures, zu große Modelle, unnötige Visual-Queries, schlechte Beziehungen oder gleichzeitig laufende Refresh-Peaks.
Entwicklung ist nicht Produktion
Ein Proof of Concept sollte Funktionstest und Lasttest bewusst trennen: „Kann es technisch funktionieren?“ ist nicht dasselbe wie „funktioniert es unter realer Last?“. Für Produktion ist eine passende Capacity erforderlich.
R- und Python-Visuals: Änderung seit Mai 2026
Seit Mai 2026 unterstützt Power BI keine eingebetteten Reports mit R- oder Python-Visuals mehr im Embed-for-your-customers-/App-owns-data-Szenario. Wer solche Visuals in einer SaaS-Lösung verwendet hat, sollte sie inzwischen ersetzt haben.
Power BI Embedded ist nicht Microsoft Fabric Embed
Microsoft Fabric Embed ist ein separates Preview-Angebot und sollte nicht mit Power BI Embedded verwechselt werden. Power-BI-Berichte werden weiterhin über Power BI Embedded Analytics eingebettet; Fabric Embed adressiert andere Fabric-Artefakte und folgt einer eigenen Funktions- und Identitätslogik.
Aktuelle Pro- und PPU-Preise
Für Deutschland nennt Microsoft aktuell 12,10 € pro Benutzer und Monat für Power BI Pro sowie 20,80 € für Premium Per User bei jährlicher Abrechnung, jeweils zzgl. MwSt. Diese Werte können sich ändern und sollten nicht die zentrale Grundlage der Architekturentscheidung bilden.
Der Embedded-Entscheidungsrahmen
Sind Nutzer extern oder intern? → App owns vs. User owns
Müssen Nutzer Power BI kennen oder sich dort anmelden? → App owns vs. Benutzeridentität
Brauchen wir eigene Produkt-UX? → Embedded vs. Secure Embed / Service
Wie werden Kunden getrennt? → RLS vs. Workspace-Isolation
Wie sieht reale Last aus? → Capacity und Skalierung
Drei typische Zielarchitekturen
Externes SaaS-Produkt
App owns data + Service Principal + Capacity + Tenant-Isolation. Für viele externe Nutzer ist das häufig der sauberste Ausgangspunkt.
Internes Unternehmensportal
User owns data + Microsoft Entra ID + vorhandene Power-BI-Governance. Sinnvoll, wenn Mitarbeiter ohnehin im Microsoft-Ökosystem arbeiten.
Einfaches internes Reporting
Power BI Service / App oder Secure Embed. Wenn keine eigene Produkt-UX benötigt wird, ist echtes Embedded häufig unnötige Komplexität.
Fazit: Embedded beginnt mit Identität – nicht mit einer SKU
Power BI Embedded ist keine Frage, ob sich ein Bericht technisch in einen iFrame laden lässt. Die eigentliche Architektur besteht aus Nutzer → Identität → Security → Tenant-Modell → Capacity → Betrieb.
Für externe SaaS- und Kundenportal-Szenarien ist App owns data mit Service Principal häufig der richtige Ausgangspunkt. Für interne Anwendungen kann User owns data deutlich einfacher sein. Und wenn lediglich ein Report im Intranet sichtbar werden soll, reicht möglicherweise der Power BI Service beziehungsweise Secure Embed.
Die beste Embedded-Architektur ist nicht die technisch aufwendigste – sondern diejenige, deren Identitäts-, Sicherheits- und Kostenmodell zum Produkt passt.
Der nächste sinnvolle Schritt
Wenn ihr Power BI in ein Kundenportal, SaaS-Produkt oder eine interne Anwendung integrieren wollt, sollte die Auswahl der Capacity nicht am Anfang stehen. Im Power BI Consulting können wir Nutzermodell, Tenant-Isolation, Security, Capacity und Betriebsanforderungen gemeinsam strukturieren und daraus eine belastbare Embedded-Architektur ableiten.
