Hybride Arbeit ist heute selbstverständlich: Mitarbeiter wechseln ständig zwischen Büro, Homeoffice und unterwegs – oft mit wechselnden Geräten und fragwürdigen Netzwerken. Für die IT heißt das, überall den sicheren, stabilen und schnellen Zugriff zu etablieren – ohne Ausreden. Viele Unternehmen setzen dafür weiterhin auf eine klassische Virtual Desktop Infrastructure (VDI) im eigenen Rechenzentrum. Das kann sinnvoll oder sogar vorgeschrieben sein, etwa wenn Datenschutz, Sicherheitsrichtlinien oder branchenspezifische Vorgaben eine lokale Verarbeitung erzwingen. Auch besonders sensible Anwendungen bleiben damit bewusst im eigenen Haus.

Trotzdem hat das Modell klare Grenzen, denn eine lokale VDI müssen IT-Verantwortliche immer an der erwarteten Lastspitze ausrichten. Doch dies ist oft nur geschätzt, was in der Praxis dazu führt, dass die Hardware 70 Prozent der Zeit im Leerlauf ist, während sie in seltenen Spitzenmomenten plötzlich kämpfen muss. Dazu kommen der übliche Storage-Ballast, wachsende Betriebsaufwände und Hardwarezyklen, die nie zum Budget passen. Genau hier spielt Azure Virtual Desktop (AVD) seine Stärken aus: flexible Skalierung, Sicherheit und ein Betrieb, der nicht mehr am eigenen RZ hängt.

Azure Virtual Desktop bringt Funktionen mit, die genau zu den Anforderungen moderner hybrider Arbeitsplätze passen. Microsoft betreibt die komplette Steuerungsebene mit Broker, Gateway und Management als Cloudservice. Der Zugriff der Clients läuft dabei zunächst über Azure Front Door, das als globaler Einstiegspunkt dient und Anfragen automatisch zum nächstgelegenen AVD-Endpunkt leitet. Admins verwalten nur die Session-Hosts, also die virtuellen Windows-Desktops im Virtual Network (VNET). Das senkt den operativen Aufwand deutlich und entlastet das IT-Team von Routing-, Skalierungs- und Hochverfügbarkeitsfragen.

Die angesprochenen zentralen Dienste übernehmen in AVD folgende Aufgaben:

- Broker: Vermittelt Verbindungen und entscheidet, welcher Session-Host eine neue Nutzerverbindung übernimmt.

- Gateway: Stellt den gesicherten RDP-Websocket-Tunnel bereit und ermöglicht den Zugriff aus beliebigen Netzwerken ohne eigenes Gateway.

- Management und Steuerungsebene: Halten die Hostpool-Konfigurationen, sorgen für Lastverteilung, verwalten Registrierungen und stellen das zentrale API sowie Portal bereit.

Zentral ist dabei die Multi-Session-Fähigkeit von Windows 10 und 11 in der Enterprise-Lizenz. Mehrere Nutzer teilen sich eine VM, ohne sich in die Quere zu kommen, was einen klaren Kostenvorteil darstellt. Zusätzlich lassen sich einzelne Anwendungen als RemoteApps bereitstellen. Diese Programme wirken für Anwender wie lokal gestartete Software, laufen aber vollständig in der Azure-Infrastruktur und gelangen per RDP-Datenstrom auf das Endgerät.

Im Vergleich zu Windows 365, das einen festen Cloud-PC pro Nutzer bereitstellt, bleibt AVD flexibler. Windows 365 sorgt für dedizierte Maschinen und ein möglichst einfaches Nutzererlebnis. AVD dagegen richtet sich an IT-Abteilungen, die Skalierung, Images, Identität und Kosten selbst steuern möchten. Funktional ersetzt AVD vieles von dem, was klassische VDI-Produkte wie Citrix oder Horizon leisten, nur ohne eigene Broker-Server oder Gateway-Farmen.

Für die Verbindung zwischen Client und Session-Host setzt AVD standardmäßig auf den klassischen RDP-Datenpfad über den Gateway-Dienst. Zusätzlich gibt es RDP Shortpath, das – sofern möglich – einen direkten UDP-Kanal zwischen Client und Session-Host aufbaut. Das kann über verwaltete Netzwerke wie ExpressRoute oder Site-to-Site-VPNs laufen (Managed Networks) oder über direkte Internetpfade (Public Networks). Shortpath reduziert Latenz und Paketverluste spürbar und verbessert damit die Nutzererfahrung, besonders bei schlechteren Leitungen.

In der Summe entsteht eine Plattform, die moderne Sicherheitsmechanismen wie Entra ID und Conditional Access nutzt, global erreichbar ist und sich flexibel an Last, Regionen oder Änderungen in der Unternehmensstruktur anpassen lässt. Und all das ohne eigene Infrastruktur für Broker, Gateways oder Datenbanken.

AVD setzt vollständig auf Entra ID, was die Absicherung deutlich vereinfacht. Sie kontrollieren den Zugriff über Conditional Access: Standort, Gerätezustand oder Risikoeinstufung entscheiden, ob eine Anmeldung erlaubt wird. Bei der Risikoeinstufung geht es etwa um auffällige An- meldeversuche, kompromittierte Passwörter oder ungewöhnliche Login-Standorte. Eine Multifaktor-Authentifizierung (MFA) ist dabei Standard und sorgt dafür, dass ein gestohlenes Passwort nicht ausreicht, um Zugriff auf AVD zu bekommen. Zusammen mit Zero Trust entsteht ein Modell, das jede Session einzeln bewertet.

Wichtig ist auch ein sauberes Rollenmodell. Berechtigungen vergeben Sie über Entra ID oder, falls nötig, über Gruppen in einem hybriden AD. Wer AVD verwaltet, sollte nicht automatisch Vollzugriff auf die darunterliegenden VMs besitzen. RBAC in Azure trennt diese Bereiche sauber: eine Rolle für Hostpools, eine für Images, eine für Zuweisungen auf App-Gruppen. In der Praxis liegen solche Rollen oft trotzdem bei denselben Personen oder Teams, aber technisch lassen sie sich klar trennen, und genau das verhindert später schwer korrigierbare "Jeder-darf-alles"-Setups.

Für die Nutzerprofile kommt FSLogix ins Spiel. Die Profile liegen als Container auf einem zentralen Storage und werden beim Login eingebunden. Das sorgt für eine konsistente Nutzererfahrung, erfordert aber schnellen Storage. Zu Details wie Größenplanung, IOPS und typischen Stolperfallen folgt später ein eigener Abschnitt. Complianceaspekte deckt AVD grundsätzlich gut ab, indem sensible Daten im Session-Host verbleiben, Endgeräte nur Bildschirminhalte erhalten und Zugriffe sich vollständig protokollieren lassen. Das ist besonders in regulierten Bereichen ein Vorteil.

Hostpools sind der zentrale organisatorische Baustein in Azure Virtual Desktop. Sie bestimmen, welche Maschinen zusammengehören und welche Nutzergruppe sie verwendet. Ein solcher Pool enthält immer mehrere Session-Hosts, also virtuelle Windows-10/11-Multi-Session-VMs, an denen sich Nutzer anmelden. Dadurch lassen sich Lasten verteilen, Ausfälle abfangen und Maschinen gezielt nach Leistungsanforderungen gruppieren. In der Praxis trennen viele Unternehmen Hostpools nach Abteilungen, Regionen oder Anwendungsgruppen, um klarere Zuständigkeiten und eine bessere Skalierung zu erreichen.

An die Hostpools sind die sogenannten App-Gruppen gekoppelt. Darüber legen Sie fest, was die Anwender letztlich präsentiert bekommen: einen vollständigen Desktop oder nur eine oder mehrere Anwendungen. Der umfassende Desktop eignet sich für breit ausgelegte Arbeitsplätze, bei denen User ein komplettes Windows-System erwarten. RemoteApps dagegen sind ideal, um einzelne Programme bereitzustellen, zum Beispiel für Fachverfahren oder Tools, die lokal nicht installiert werden dürfen. Aus Nutzersicht wirkt eine RemoteApp wie eine lokale Anwendung, doch tatsächlich läuft sie auf dem Session-Host und wird lediglich per RDP übertragen.

Bei der Größe und Ausstattung der Session-Hosts haben Sie breite Auswahl. Standard-Workloads laufen gut auf D- oder E-Serien, während speicherintensive oder rechenlastige Aufgaben B- oder F-Serien benötigen. Für Grafik- oder CAD-Anwendungen gibt es dedizierte GPU-Varianten wie die NVadsA- oder NCas- T4_v3-Serien.

Ein wichtiger Bestandteil stabiler AVD-Umgebungen sind Golden Images. Statt jeden Session-Host einzeln aufzusetzen, definieren Sie ein Basis-Image in der Azure Compute Gallery, das alle benötigten Anwendungen und Konfigurationen enthält. Jede Aktualisierung (Windows Updates, neue Applikationen, Patches) wandert in eine neue Image-Version. Diese Version wird anschließend gezielt auf Hostpools ausgerollt, wie es Bild 2 zeigt: Die Hostpools "Blue" und "Green" erhalten die aktuelle Image-Version automatisch und lassen sich zeitversetzt aktualisieren. So erreichen Sie planbare Deployments und verhindern, dass einzelne Maschinen unkontrolliert auseinanderlaufen. Sobald Sie anfangen, Hosts manuell zu verändern, entsteht Image-Drift und damit die Gefahr von Fehlern, die später kaum nachvollziehbar sind.

Für viele Unternehmen ist die Integration dieser Abläufe in bestehende Build- und Deployment-Pipelines inzwischen Standard. Die Kombination aus Packer für die Image-Erstellung, Terraform für die Bereitstellung und Azure DevOps oder GitHub Actions für Automatisierung sorgt für reproduzierbare Builds und nachvollziehbare Änderungen. Jede Änderung wandert in ein Repository, wird durch einen Pipeline-Lauf verarbeitet und landet versioniert in der Azure Compute Gallery. Anschließend entscheiden Sie, welcher Hostpool welche Version erhält – kontrolliert, dokumentiert und ohne manuelle Eingriffe auf den VMs.

Dieses Zusammenspiel aus Hostpools, App-Gruppen, passenden VM-Größen und sauber versionierten Images bildet die Grundlage für eine stabile und skalierbare AVD-Umgebung. Bild 3 zeigt den skizzierten Ablauf: Nutzer werden App-Gruppen zugewiesen, Hostpools erhalten neue Image-Versionen und Session-Hosts beziehen ihre Konfiguration konsistent aus der Galerie. So bleibt die Umgebung wartbar, selbst dann, wenn Sie viele hundert Maschinen betreiben.

Mit Terraform beschreiben Sie den Zielzustand Ihrer Umgebung in Textdateien und das Tool kümmert sich um den Abgleich mit Azure. Das passt perfekt zu AVD, weil Sie Hostpools, App-Gruppen, Workspaces und Netzwerke wiederholt und reproduzierbar bereitstellen müssen. Natürlich können Sie alles im Azure-Portal zusammenklicken, aber spätestens bei der zweiten oder dritten Umgebung wird das fehleranfällig und schwer nachvollziehbar.

Im Folgenden legen wir zentrale Bausteine für eine AVD-Umgebung mit Terraform an. Diese Skripte stellen jedoch nur einen Auszug dar, das vollständige Beispiel mit Resource Group, Netzwerk, Session-Host-Subnetz und so weiter liefert [1]. Der Code-Block in Listing 1 legt den zentralen Hostpool an. Mit "type = "Pooled"" definieren Sie, dass sich mehrere Nutzer gleichzeitig eine Maschine teilen können – das senkt Kosten und ist Standard in AVD. Mit "load_balancer_type = "BreadthFirst" steuern Sie, wie sich die Verbindungen verteilen. In diesem Beispiel versucht AVD, möglichst viele Hosts gleichmäßig auszulasten, statt zuerst einen Host vollzumachen. Über "maximum_ sessions_allowed = 20" legen Sie fest, wie viele gleichzeitige Sessions ein einzelner Session-Host maximal aufnehmen darf. Genau diese drei Parameter bestimmen später, wie effizient und stabil der Hostpool arbeitet. Der Hostpool selbst ist anschließend der zentrale Ankerpunkt, der App-Gruppen und Session-Hosts miteinander verknüpft.

In Listing 2 entsteht die Desktop-App-Gruppe, die auf dem Hostpool aus Listing 1 aufsetzt. Der Typ "Desktop" sorgt dafür, dass Anwender einen vollständigen Desktop sehen. Wollen Sie nur einzelne Anwendungen bereitstellen, müssen Sie hier eine RemoteApp-Gruppe mit einem anderen Typ eintragen.

Schließlich legt Listing 3 den Workspace an, also das, was die Nutzer im AVD-Client sehen. Über die Assoziation wird die Desktop-App-Gruppe mit diesem Workspace verbunden. Ohne diese Verknüpfung taucht der Desktop später im Client nicht auf. Mit diesen drei Bausteinen steht die AVD-Steuerungsebene bereits sauber als Code. In der Praxis ergänzen Sie dazu noch Netzwerk, Storage für FSLogix und die Session-Hosts selbst.

Der Zugang zu einer AVD-Umgebung ist bewusst niedrigschwellig gehalten. Die Nutzer benötigen keinen komplexen Spezialclient, keine VPN-Verbindung und auch keine lokale Active-Directory-Mitgliedschaft. Microsoft bietet einen dedizierten AVD-Client für Windows, macOS, Android und iOS an und zusätzlich einen reinen HTML5-Client, der direkt im Browser läuft. Damit können sich selbst externe Partner oder Geräte im Homeoffice ohne großen Aufwand verbinden.

Der klassische Remote-Desktop-Client kann zwar grundsätzlich RDP sprechen, reicht für AVD aber nicht aus. Der Dienst nutzt mehrere zusätzliche Komponenten wie den Broker und das Gateway, die der Standard-RDP-Client nicht kennt. Der "Remote Desktop Client for Azure Virtual Desktop" (oft AVD-Client genannt) spricht diese Protokolle nativ, baut automatisch den Websocket-Tunnel über das AVD-Gateway auf und unterstützt Funktionen wie Feed-Abonnements, RemoteApps und AVD-spezifische Sicherheitsrichtlinien.

Beim Browserzugang ruft der User einfach die AVD-Webseite auf, meldet sich mit Entra ID an und der Dienst zeigt den zugewiesenen Workspace mit Desktops und RemoteApps. Die Verbindung läuft ebenfalls über das Gateway und nutzt ein RDP-Websocket-Protokoll. Für einfache Tests, Schulungen oder Geräte ohne Installationsrechte ist das ideal. Sobald der Nutzer im Client angemeldet ist, erscheint sein Workspace mit den darin enthaltenen App-Gruppen. Ein Klick auf den Desktop oder die RemoteApp reicht, und der Client baut die Verbindung zum passenden Session-Host auf, gesteuert durch den Broker, der entscheidet, welcher Host verfügbar ist oder wie die Lastverteilung erfolgt. Bei guter Netzwerkqualität nutzt AVD automatisch RDP Shortpath, also einen optimierten UDP-Datenpfad, der spürbar performanter ist als herkömmliches TCP-RDP.

FSLogix ist in AVD ein zentrales Bauteil, denn ohne diesen Profilcontainer-Mechanismus würden Anmeldungen deutlich länger dauern und die Session-Hosts sehr schnell voneinander abweichen. FSLogix sorgt dafür, dass jedes Nutzerprofil sauber getrennt bleibt, unabhängig davon, auf welchem Session-Host sich der Anwender anmeldet. Das verbessert nicht nur die Stabilität, sondern auch die Performance (gerade in Umgebungen mit vielen gleichzeitigen Logins).

Das Prinzip ist einfach: Statt ein Profil jedes Mal neu zu übertragen, mountet FSLogix beim Login eine VHD- oder VHDX-Datei, die auf einem zentralen Storage liegt. Aus Sicht des Betriebssystems verhält sich das wie ein normales Benutzerprofil, technisch handelt es sich aber um eine Container-Datei. Dadurch bleiben die Daten konsistent, Logins werden schneller, und es spielt keine Rolle mehr, auf welchem Server der Nutzer landet – das Profil reist als Container mit.

Für die Ablage dieser Container stehen verschiedene Optionen bereit. Azure Files ist die gängigste Variante und lässt sich direkt mit Entra-ID-Kerberos oder klassischem AD verwenden. Wer höhere Performanceanforderungen hat oder mit vielen gleichzeitigen Zugriffen rechnet, nutzt Azure Files Premium oder Azure NetApp Files. Beide liefern deutlich mehr IOPS und niedrigere Latenzen, was sich bei vielen parallelen Anmeldungen sofort bemerkbar macht. In kleineren oder hybriden Umgebungen kann es auch ein klassischer Fileserver sein, technisch funktioniert das gut. In der Cloud skaliert Azure Files aber meist sauberer.

Cloudkosten entstehen auf den ersten Blick aus Compute, Storage und ein bisschen Netzwerk. In der Realität zeigt sich aber schnell, dass sich AVD nur dann wirtschaftlich betreiben lässt, wenn Sie die Nutzung verstehen und richtig einordnen. Eine grobe Kostenschätzung vorab ist möglich, aber sie bleibt nun mal eine Annäherung. Der tatsächliche Verbrauch hängt stark davon ab, wie intensiv Nutzer arbeiten, wie viele Sessions gleichzeitig laufen, welche Anwendungen genutzt werden und ob GPU-Leistung nötig ist. Genau deshalb lohnt es sich, das Thema Kosten systematisch anzugehen.

AVD folgt einem klaren Verbrauchsmodell. VMs verursachen Kosten, solange sie laufen, Storage skaliert je nach Größe und IOPS und die Netzwerkauslastung hängt vom Nutzerverhalten ab. Die Erfahrung zeigt jedoch, dass viele Unternehmen mit zu großen Maschinen oder zu vielen Hosts starten, weil sie On-Premises-Denken gewohnt sind. Das führt schnell zu hohen Grundkosten. Die Kostenfalle entsteht oft dort, wo IT-Verantwortliche für den Fall der Fälle überdimensionieren und die Hosts dann 70 Prozent der Zeit arbeitslos sind. AVD bietet aber gerade hier die Möglichkeit, klein anzufangen und gezielt nach oben zu skalieren.

Autoscaling ist dabei der wichtigste Hebel. Mit den richtigen Regeln fahren Hostpools außerhalb der Spitzenzeiten herunter und starten erst bei wirklichem Bedarf neue Maschinen. Das drückt die Compute-Kosten massiv. Alternativ lassen sich Reserved Instances oder Savings Plans nutzen, wenn die Auslastung stabil und vorhersehbar ist. Beim Storage lohnt sich ebenfalls ein genauer Blick: FSLogix-Container auf Azure Files Premium oder Azure NetApp Files sind schneller, aber auch teurer. Hier hängt die Entscheidung von der gewünschten Performance und vom Profilverhalten ab.

Für eine realistische Kostenplanung hat sich in größeren Unternehmen bewährt, Personas zu bilden. IT-Admins arbeiten ganztägig mit Tools wie MMC, VS Code oder PowerShell ISE, Grafiker benötigen GPU-Leistung, Knowledge Worker arbeiten überwiegend in Office-Anwendungen. Statt die gesamte Firma über einen Kamm zu scheren, erstellen Sie für jede Persona ein Testset mit passenden Hostpools. Diese Gruppen arbeiten dann über einen klar definierten Zeitraum – zwei bis vier Wochen reichen oft aus. Danach lassen sich die tatsächlichen Kosten pro Persona aus Azure Monitor und Cost Management ablesen und realistisch auf die gesamte Nutzerbasis hochrechnen. Das ist deutlich genauer als jede theoretische Kalkulation. Über den Azure Pricing Calculator [2] können Sie verschiedene Annahmen und Szenarien abbilden und kostentechnisch untersuchen.

Azure Virtual Desktop trifft den Kern dessen, was hybride Arbeitsplätze heute brauchen: Flexible Bereitstellung, ortsunabhängigen Zugriff und eine klare Sicherheitslinie, die nicht auf das Firmennetz beschränkt ist. Gerade dort, wo klassische VDI-Umgebungen an Hardwaregrenzen stoßen oder der Betrieb zu schwerfällig wird, bietet AVD eine moderne Alternative, die sich schnell an wechselnde Anforderungen anpassen lässt.

Die Kombination aus zentral gemanagter Plattform, moderner Authentifizierung, sauberem Image-Management und Automatisierung mit Terraform macht AVD zu einem Werkzeug, das sich sowohl für kleine Teams als auch für große Unternehmen eignet. Skalierung nach Bedarf, reproduzierbare Deployments und einheitliche Profile sorgen dafür, dass der Betrieb kalkulierbar und stabil bleibt.