Kosten: drei Blöcke, und einer wird leicht zweimal bezahlt

Azure Virtual Desktop erhebt den nutzungsabhängigen Zugriffspreis auch für Nutzer, die bereits eine Lizenz haben, die ihnen den Zugriff ohnehin erlaubt. Wer eigene Beschäftigte über ein Abonnement laufen lässt, das für diesen Preis eingeschrieben ist, zahlt für sie effektiv zweimal — und die Rechnung sagt nicht, dass es vermeidbar war. Dieses Modul behandelt alle drei Kostenblöcke einer Sitzungsplattform: welche Stellschrauben die Infrastrukturkosten tatsächlich bewegen, warum ein externer Dienstleister im Sinne der Lizenzierung ein interner Nutzer ist, warum für externe Kunden auf Windows Server gar kein Lizenzmodell existiert, wie die beiden Preisstufen dem Verhalten folgen statt der Zuweisung — und was jede einzelne Einsparung auf der anderen Seite kostet.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-13

Drei Kostenblöcke, nicht einer

Die Rechnung einer Sitzungsplattform setzt sich aus drei Teilen zusammen, die getrennt entstehen und getrennt gesteuert werden: die Azure-Infrastruktur mit Rechenleistung und Netz, der Speicher für Profile und Anwendungen, und die Lizenzen für den Zugriff.

Wer nur den ersten Block betrachtet, optimiert die sichtbarste Position und übersieht regelmäßig die teuerste. Dieses Modul behandelt alle drei — und eine Konstellation, in der eine Organisation für dieselben Menschen zweimal zahlt, ohne es zu merken.

LernzielDu kannst die Kostentreiber einer Sitzungsplattform benennen, eine Einsparung gegen ihre Wirkung auf das Erlebnis abwägen und die Lizenzfrage für interne und externe Nutzung auseinanderhalten.

Wo das Geld in der Infrastruktur hingeht

Wie viele Hosts laufen→Wie lange sie laufen→Wie viele Nutzer auf einem Host arbeiten

Drei Größen, drei Hebel

Jede dieser Größen lässt sich verändern, und jede zahlt der Nutzer mit Erlebnis oder Wartezeit. Die Kunst liegt nicht darin, eine davon zu drücken, sondern zu wissen, welche in der eigenen Umgebung den größten Hebel bei der geringsten Wirkung hat.

Zahl der Hosts: Folgt der gleichzeitigen Last und der Ausfallreserve. Reserve ist per Definition ungenutzte Kapazität.
Laufzeit: Wird über den Skalierungsplan gesteuert. Nachts abgeschaltete Maschinen kosten nichts.
Nutzerdichte: Wird über die Sitzungsgrenze und die VM-Größe bestimmt. Höhere Dichte senkt die Rechnung und die Leistung je Sitzung.

Der Unterschied zum klassischen ArbeitsplatzEin physischer Arbeitsplatz kostet unabhängig davon, ob jemand daran sitzt. Eine Sitzungsplattform kostet nach Laufzeit — und genau deshalb ist die Frage, wann Maschinen laufen müssen, hier eine Kostenfrage und dort keine.

Konkret hängen diese drei Größen an benennbaren Stellschrauben: die Zahl laufender Hosts an RampUpMinimumHostsPct und RampUpCapacityThresholdPct des Skalierungsplans, die Laufzeit an den Phasenzeiten und an RampDownForceLogoffUser, die Dichte an MaxSessionLimit und der gewählten VM-Größe. Wer über Kosten spricht, sollte diese Namen nennen können — sonst bleibt die Diskussion bei Absichten und erreicht nie eine Einstellung.

Nutzerdichte gegen Erlebnis

Die Dichte ist der größte Einzelhebel und zugleich der gefährlichste. Sie entsteht aus zwei Werten: der Größe der virtuellen Maschine und der Sitzungsgrenze je Host.

Eine höhere Sitzungsgrenze verteilt dieselben Kosten auf mehr Menschen — und teilt dieselben Ressourcen auf mehr Menschen auf.
Der richtige Wert wird gemessen, nicht geraten: Sitzungszahl und Leistung je Host lassen sich in der Auswertung gegenüberstellen.
Die Grenze ist keine Garantie — bei hoher gleichzeitiger Verbindungslast kann die Zahl der Sitzungen sie überschreiten. Wer bis an die Kante dimensioniert, hat im Morgenpeak keine Luft.
Anwendungsprofile unterscheiden sich um ein Vielfaches: Eine Gruppe in Textverarbeitung verträgt eine ganz andere Dichte als eine mit Videokonferenzen.

Warum die Einsparung nicht ankommtEine Dichteerhöhung senkt die Rechnung sofort und sichtbar. Ihre Kosten entstehen verteilt und unsichtbar: etwas längere Anmeldungen, etwas trägere Anwendungen, etwas mehr Supportanfragen. Beides gehört in dieselbe Rechnung — sonst wird eine Verschlechterung für alle als Erfolg verbucht.

Zu beachten ist die Wechselwirkung mit dem Algorithmus: MaxSessionLimit steuert bei DepthFirst unmittelbar, wie voll ein Host wird, bevor der nächste startet. Bei BreadthFirst wirkt der Wert dagegen kaum — dort verteilt der Algorithmus ohnehin, und eine Umstellung auf DepthFirst ohne Anpassung der Grenze hat schon ganze Pools auf einen einzigen Host gedrückt.

Laufzeit: der Hebel ohne Erlebnisverlust

Anders als die Dichte kostet die Laufzeit das Erlebnis nur an den Rändern des Tages. Nachts abgeschaltete Maschinen stören niemanden — vorausgesetzt, morgens steht rechtzeitig wieder etwas bereit.

Der Mindestanteil der Hosts je Phase hält die Kapazität vor, die eine Anmeldewelle ohne Wartezeit auffängt.
Die Kapazitätsschwelle bestimmt, wann zusätzliche Hosts starten — niedriger heißt mehr Reserve und mehr Kosten.
Beim Absenken entscheidet die erzwungene Abmeldung darüber, ob Maschinen planmäßig frei werden oder auf getrennte Sitzungen warten.
Start VM on Connect ist das Auffangnetz für Zeiten ohne vorgehaltene Hosts — es kostet Wartezeit beim ersten Zugriff, aber keine Laufzeit.

Der stille KostentreiberGetrennte Sitzungen halten Hosts am Leben, weil sie in die belegte Kapazität zählen. Eine Zeitlimitrichtlinie für getrennte Sitzungen ist deshalb eine Kostenmaßnahme — und eine der wenigen, die niemandem aktive Arbeit nimmt.

Beim Absenken ist RampDownWaitTimeMinute die Stellschraube, an der Kosten und Anstand aufeinandertreffen. Ein kurzer Wert gibt Maschinen schnell frei und reißt Menschen aus der Arbeit; ein langer Wert verschiebt die Einsparung nach hinten. Die Dokumentation nennt keine empfohlene Zahl — die Entscheidung gehört mit den Fachbereichen getroffen und im Betriebshandbuch festgehalten, zusammen mit dem Text aus RampDownNotificationMessage, den die Betroffenen tatsächlich lesen.

Der Algorithmus als Kostenhebel

Depth-first füllt einen Host bis zur Sitzungsgrenze, bevor der nächste an die Reihe kommt. Genau dafür ist er gedacht: Die Dokumentation nennt ihn ideal für kostenbewusste Organisationen, weil sich bei sinkender Nutzerzahl mehr Maschinen abschalten lassen.

Breadth-first verteilt Sitzungen über die vorhandenen Hosts und optimiert damit die Leistung je Sitzung — Prozessor, Speicher und Platte sind weniger umkämpft. Er ist die Wahl, wenn das Erlebnis vor der Rechnung steht.

Die Wahl gilt nicht für den ganzen TagWeil jede Skalierungsphase einen eigenen Algorithmus trägt, lässt sich beides haben: morgens verteilen, damit die Anmeldewelle kurze Zugriffszeiten findet, nachmittags verdichten, damit abends Maschinen frei werden. Die Phaseneinstellung übersteuert dabei die des Host Pools.

Der Preis von DepthFirst ist nicht nur Leistung je Sitzung, sondern auch Blast Radius: Wer dreißig Menschen auf eine Maschine packt, setzt dreißig Menschen demselben Hostausfall aus. Bei BreadthFirst verteilt sich derselbe Ausfall auf weniger Betroffene je Host. Diese Abwägung gehört in dieselbe Entscheidung wie die Kostenfrage — sie wird aber fast immer getrennt geführt, weil Kosten und Verfügbarkeit in verschiedenen Sitzungen besprochen werden.

Die Lizenzfrage entscheidet sich an einem Wort

Der zweite Kostenblock folgt einer Unterscheidung, die in Projekten regelmäßig falsch getroffen wird: interne gegen externe kommerzielle Zwecke. Sie hat nichts damit zu tun, ob jemand im eigenen Gebäude sitzt.

Interne Nutzer: Mitglieder der eigenen Organisation — Beschäftigte, Studierende — einschließlich externer Lieferanten und Auftragnehmer.
Externe Nutzer: Keine Mitglieder der eigenen Organisation, sondern Kunden, denen man etwa eine Anwendung als Dienst bereitstellt.

Die Verwechslung, die teuer wirdEin externer Dienstleister, der für die eigene Organisation arbeitet, ist im Sinne der Lizenzierung ein interner Nutzer — er dient internen Zwecken. Für ihn gilt die normale Lizenzpflicht, und der nutzungsabhängige Zugriffspreis ist ausdrücklich nicht anwendbar. Nicht zu verwechseln ist das mit externen Identitäten: Gastkonten und B2B-Identitäten sind eine technische Kategorie und sagen über die Lizenzart nichts aus.

Praktisch heißt das: Die Lizenzfrage gehört an den Anfang eines Projekts, nicht ans Ende. Sie entscheidet über das Sitzungsbetriebssystem, über die Zahl der Azure-Abonnements und darüber, welche Nutzergruppen überhaupt in derselben Umgebung arbeiten dürfen. Wer sie nachgelagert klärt, findet gelegentlich heraus, dass die gebaute Umgebung für den vorgesehenen Zweck kein Lizenzmodell hat.

Welche Lizenz gilt

Windows 10/11 Enterprise, auch multi-session: Intern: Microsoft 365 E3, E5, A3, A5, F3, Business Premium oder Student Use Benefit; Windows Enterprise E3, E5; Windows Education A3, A5; Windows VDA je Nutzer.
Windows Server 2016 bis 2025: Intern: RDS-Clientzugriffslizenz mit Software Assurance, je Nutzer oder je Gerät — oder RDS User Subscription Licenses.
Extern, Windows-Client: Nutzungsabhängiger Zugriffspreis über ein eingeschriebenes Azure-Abonnement.
Extern, Windows Server: Nicht unterstützt — der nutzungsabhängige Zugriffspreis steht für Windows Server nicht zur Verfügung.

Die letzte Zeile ist eine Entwurfsgrenze: Wer eine Anwendung für Kunden bereitstellen will und dabei auf Windows Server als Sitzungsbetriebssystem setzt, hat für diesen Fall kein Lizenzmodell. Die Wahl des Betriebssystems ist damit zugleich eine Lizenzentscheidung.

Der Fall, in dem zweimal gezahlt wird

Hier liegt der Befund, der diesem Modul seinen Titel gibt — und er steht als Warnung in der Dokumentation.

Doppelt bezahltAzure Virtual Desktop erhebt den nutzungsabhängigen Zugriffspreis auch für Nutzer, die bereits eine zugewiesene Lizenz haben, die ihnen den Zugriff ohnehin erlaubt. Wer interne Nutzer über ein Abonnement laufen lässt, das für den nutzungsabhängigen Preis eingeschrieben ist, zahlt für diese Menschen effektiv zweimal. Die Empfehlung lautet, internen Nutzern den Zugriff über ein getrenntes Abonnement zu geben, das nicht eingeschrieben ist.

Eine zweite Regel begrenzt den Schaden an anderer Stelle: Je Nutzer und Abrechnungszeitraum entsteht höchstens eine Zugriffsgebühr. Hat jemand Zugriff über zwei Abonnements desselben Mandanten, belastet nur das zuerst genutzte.

Kurzcheck

Eine Organisation stellt sowohl eigenen Beschäftigten als auch zahlenden Kunden Desktops bereit — beide über dasselbe Azure-Abonnement, das für den nutzungsabhängigen Zugriffspreis eingeschrieben ist. Alle Beschäftigten haben Microsoft 365 E3.

Für die Beschäftigten wird doppelt gezahlt — sie gehören in ein eigenes Abonnement.
Kein Problem — vorhandene Lizenzen werden automatisch verrechnet.
Kein Problem, solange jeder Nutzer nur ein Abonnement nutzt.
Die Beschäftigten müssen ihre Microsoft-365-Lizenz abgeben.

Treffer. Richtig. Der Zugriffspreis wird auch für Nutzer mit berechtigender Lizenz erhoben. Die Dokumentation empfiehlt dafür ausdrücklich ein getrenntes, nicht eingeschriebenes Abonnement.

Zwei Preisstufen, ein Verhalten

Der nutzungsabhängige Zugriffspreis kennt zwei Stufen, und welche gilt, entscheidet sich automatisch je Abrechnungszeitraum danach, mit welcher Art von Anwendungsgruppe sich jemand verbunden hat.

Apps: Pauschalpreis für jeden Nutzer, der mindestens eine veröffentlichte Anwendung genutzt hat, aber keinen vollständigen Desktop.
Desktops + apps: Pauschalpreis für jeden Nutzer, der mindestens einen vollständigen Desktop genutzt hat — Anwendungen darf er zusätzlich nutzen.

Belastet werden nur Nutzer, die im Abrechnungszeitraum mindestens einmal verbunden waren. Wer nicht zugreift, kostet nichts.
Der Preis ist eine Pauschale: Die Zahl der Stunden spielt keine Rolle.
Die Stufe folgt dem Verhalten, nicht der Zuweisung — wer einen Desktop hätte nutzen dürfen und nur eine Anwendung genutzt hat, liegt in der günstigeren Stufe.

Die Steuerungsmöglichkeit dahinterWer Kunden nur eine Anwendung schuldet, sollte ihnen keinen vollständigen Desktop zuweisen — das ist hier nicht nur eine Sicherheits-, sondern unmittelbar eine Kostenentscheidung. Umgekehrt gilt: Eine einzige Desktopverbindung im Monat hebt einen Nutzer in die teurere Stufe.

Für die Planung folgt daraus eine ungewohnte Rechnung: Die monatlichen Zugriffskosten hängen nicht an der Zahl der berechtigten Personen, sondern an der Zahl derer, die tatsächlich verbunden waren — und an der Ressourcenart, die sie genutzt haben. Ein Angebot, das saisonal schwankt, hat damit saisonal schwankende Zugriffskosten. Die Azure-Infrastruktur darunter schwankt nur, wenn der Skalierungsplan sie schwanken lässt.

Was die Zugriffslizenz nicht enthält

Eine verbreitete Annahme lautet, der nutzungsabhängige Zugriffspreis sei ein vollständiger Ersatz für eine Windows- oder Microsoft-365-Lizenz. Die Dokumentation widerspricht ausdrücklich.

Enthalten sind nur die Zugriffsrechte auf Azure Virtual Desktop — und FSLogix.
Nicht enthalten sind Microsoft Office, Microsoft Defender XDR und Universal Print.
Wer diese Produkte in der Sitzung anbieten will, lizenziert sie getrennt.
Für Office nennt die Dokumentation drei Wege: eigene Anmeldung der Nutzer, Weiterverkauf über einen Cloud-Anbieter oder ein Dienstleistervertrag.

Und bei externen MitarbeitendenLizenzen, die einem externen Mitarbeitenden in seinem eigenen Mandanten zugewiesen sind, begründen im Regelfall keine Berechtigung in deinem Mandanten. Empfohlen wird, dieselbe Art von Lizenz wie für interne Nutzer zu kaufen und sie dem Identitätsobjekt dieser Person im eigenen Mandanten zuzuweisen. Dieselbe Logik gilt zwischen Mandanten einer Organisation — eine Lizenz in Mandant A begründet keine Rechte in Mandant B.

Der dritte Block: Speicher

Der Speicher wird bei der Kostenplanung regelmäßig vergessen, weil er je Einheit billig wirkt. Er wächst aber mit der Nutzerzahl und mit der Zeit, und er hat die meisten stillen Treiber.

Profilcontainer wachsen dynamisch mit ihrem Inhalt, und ihre Obergrenze lässt sich nach unten nicht mehr korrigieren.
Geplant wird für die Obergrenze und die tatsächliche Belegung — beide Zahlen beantworten unterschiedliche Fragen.
Cloud Cache legt zusätzlich lokalen Platz auf jedem Session Host an und verlangt Durchsatz für das Schreiben an alle Anbieter.
Anwendungsabbilder für App Attach liegen auf einer eigenen Freigabe — von derselben wie für Profile rät die Dokumentation ab.
Karteileichen kosten dauerhaft: Container von Menschen, die die Organisation längst verlassen haben, verschwinden nicht von selbst.

Der Speicher ist auch ein ErlebnisfaktorAnders als bei Rechenleistung ist die billigste Speicherklasse hier oft die falsche: Die Latenz zum Profilspeicher geht unmittelbar in die Anmeldedauer ein. Eine Einsparung an dieser Stelle bezahlt jeder Mensch jeden Morgen.

Für Profile ist SizeInMBs die kostenrelevante Größe, und sie ist eine Einbahnstraße: Der Standardwert 30000 entspricht rund 30 GB je Nutzer, bestehende Container werden bei der Anmeldung automatisch auf den eingestellten Wert erweitert, und eine spätere Absenkung lässt sie unverändert. Wer bei tausend Nutzern großzügig ansetzt, legt damit eine Obergrenze fest, die sich nur durch Neuanlage jedes einzelnen Containers zurücknehmen lässt.

Aufräumen gehört zum BetriebWeil Container nicht von selbst verschwinden, braucht es einen wiederkehrenden Vorgang, der Profile ausgeschiedener Personen erkennt und nach einer vereinbarten Frist entfernt. Ohne ihn wächst der Profilspeicher monoton — und niemand traut sich später, eine einzelne Datei zu löschen, weil unklar ist, wem sie gehört.

Was jede Einsparung kostet

Höhere Sitzungsgrenze: Weniger Hosts für dieselbe Nutzerzahl — und weniger Ressourcen je Sitzung für alle.
Aggressives Absenken: Kürzere Laufzeiten — und abgebrochene Arbeit am Abend, wenn die Wartezeit zu knapp bemessen ist.
Depth-first ganztags: Mehr abschaltbare Maschinen — und mehr Menschen, die derselbe Hostausfall trifft.
Kleinere Hosts: Niedrigerer Stundenpreis — und eine niedrigere tragbare Dichte, was die Ersparnis oft aufzehrt.
Günstigerer Profilspeicher: Weniger Speicherkosten — und längere Anmeldungen für jeden, jeden Tag.
Keine Ausfallreserve: Kein leerer Host in der Rechnung — und keine Verfügbarkeitszusage, die man einhalten kann.

Eine Bemerkung zur Messgröße: Die einzige Zahl, die Dichte, Hostgröße und Laufzeit vergleichbar macht, ist der Betrag je aktivem Nutzer und Stunde. Ein Vergleich über die Monatsrechnung allein führt in die Irre, weil er Änderungen der Nutzerzahl, der Arbeitszeiten und der Anwendungslandschaft mit den eigenen Maßnahmen vermischt. Wer eine Einsparung belegen will, rechnet sie auf diese Bezugsgröße um — und stellt ihr die Entwicklung der Anmeldedauer und der Supportanfragen gegenüber.

Keine dieser Zeilen ist ein Argument gegen Sparen. Sie sind ein Argument dafür, jede Einsparung mit ihrem Preis zu dokumentieren — sonst erscheint die Ersparnis in einer Tabelle und die Wirkung in Supportanfragen, und niemand verbindet beides.

Die Reihenfolge, die sich bewährtZuerst die Laufzeit, weil sie am wenigsten Erlebnis kostet. Dann die Lizenzkonstellation, weil sie ohne jede Wirkung auf Nutzer korrigierbar ist und die größten Einzelbeträge enthält. Erst danach die Dichte, weil sie alle trifft. Und die Ausfallreserve bleibt außen vor — sie ist keine Einsparung, sondern eine Zusage.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität4 Primärquellen · zuletzt geprüft: 2026-09-13