In meinen Azure-Kursen taucht eine Frage mittlerweile fast in jeder zweiten Runde auf: „Soll ich noch Blueprints verwenden, oder ist das schon veraltet?“ Die Antwort ist eindeutig – und gleichzeitig etwas komplizierter als ein einfaches Ja oder Nein. Azure Governance (die Steuerung und Absicherung von Cloud-Umgebungen nach unternehmenseigenen Regeln) hat sich in den letzten zwei Jahren erheblich gewandelt. Wer heute eine neue Azure-Umgebung aufbaut – egal ob als Freelancer, KMU oder Enterprise – sollte verstehen, welche Werkzeuge Microsoft aktiv weiterentwickelt und welche auf dem Abstellgleis stehen.
Azure Blueprints: Respektvolle Verabschiedung eines Pioniers
Azure Blueprints war lange Zeit das Werkzeug, wenn es darum ging, Subscriptions (Azure-Abonnements) reproduzierbar mit Policies, Rollen, Ressourcengruppen und ARM-Templates zu bestücken. Die Idee war gut: Eine Blueprint-Definition fasst alles zusammen, was eine Subscription von Anfang an braucht, und lässt sich versioniert zuweisen.
Das Problem: Microsoft hat Blueprints im September 2026 offiziell zur Deprecation (Abkündigung) erklärt – der Support läuft bis Ende 2026. Neue Features kommen nicht mehr. In der Praxis bedeutet das: Wer heute noch eine Blueprints-basierte Governance aufbaut, baut auf Sand.
Das Deprecation-Banner in der Blueprints-Oberfläche des Azure Portals ist unmissverständlich.
Merksatz: Azure Blueprints nicht mehr für neue Projekte einsetzen. Bestehende Deployments bis Ende 2026 auf Deployment Stacks oder Bicep-basierte Alternativen migrieren.
Deployment Stacks: Der neue Standard für verwaltete Deployments
Deployment Stacks (verwaltete Bereitstellungsstapel) sind seit 2024 Generally Available (allgemein verfügbar) und lösen einen zentralen Schwachpunkt klassischer ARM- und Bicep-Deployments: das sogenannte Drift-Problem. Ressourcen, die außerhalb des Templates manuell angelegt oder verändert wurden, blieben bisher unsichtbar für den Deployment-Prozess.
Ein Deployment Stack verwaltet alle Ressourcen, die er deployed hat, als verwaltete Ressourcen. Das bedeutet konkret:
- Ressourcen, die nicht mehr im Template stehen, können beim nächsten Update automatisch gelöscht oder in den „Detach“-Modus versetzt werden (also aus der Verwaltung entlassen, aber nicht gelöscht).
- Der Stack kann auf Subscription- oder Management-Group-Ebene deployen – nicht nur auf Ressourcengruppen-Ebene.
- Deny Assignments (Ablehnungszuweisungen) verhindern, dass verwaltete Ressourcen außerhalb des Stacks verändert werden.
Der Stack wird per Bicep oder ARM-Template definiert und über Azure CLI oder PowerShell deployt:
az stack sub create \
--name "kmu-baseline-stack" \
--location "germanywestcentral" \
--template-file main.bicep \
--deny-settings-mode "denyWriteAndDelete" \
--action-on-unmanage "deleteAll"
Die Stack-Detailansicht zeigt alle verwalteten Ressourcen inklusive aktiver Deny Assignments.
Praxistipp: Der Parameter --deny-settings-mode ist der eigentliche Gamechanger. Mit denyWriteAndDelete wird verhindert, dass jemand Ressourcen im Stack manuell verändert oder löscht – auch Subscription-Admins, sofern sie nicht explizit ausgenommen werden.
Azure Landing Zones: Kein Tool, sondern eine Architekturentscheidung
Hier liegt ein häufiges Missverständnis, das mir in meinen Azure-Kursen immer wieder begegnet: Landing Zones sind keine Software und kein Portal-Feature. Sie sind ein Architekturmuster – eine von Microsoft definierte Referenzarchitektur, die beschreibt, wie eine skalierbare, sichere und verwaltbare Azure-Umgebung strukturiert sein soll.
Die Azure Landing Zone umfasst:
- Eine Management-Group-Hierarchie (Verwaltungsgruppen-Hierarchie) mit klaren Vererbungsregeln für Policies
- Dedizierte Subscriptions für Plattform-Dienste (Connectivity, Identity, Management)
- Landing-Zone-Subscriptions für Applikationen (Corp oder Online, je nach Netzwerkanbindung)
- Einen zentralen Log-Analytics-Workspace und Monitoring-Stack
Microsoft stellt dafür den ALZ-Accelerator bereit – ein Bicep-basiertes Deployment, das die Grundstruktur automatisiert ausrollt. Deployment Stacks sind das natürliche Werkzeug, um diese Strukturen nach dem initialen Deployment konsistent zu halten.
Was passt zu welcher Umgebungsgröße?
Nicht jede Organisation braucht eine vollständige Enterprise-Landing-Zone mit zehn Subscriptions. Folgendes Problem aus der Praxis: Ein Freelancer, der Azure als Entwicklungsumgebung nutzt, wird durch eine vollständige ALZ-Implementierung eher blockiert als unterstützt. Hier lohnt sich ein abgestufter Ansatz.
| Zielgruppe | Empfohlene Struktur | Governance-Werkzeuge | Aufwand (initial) |
|---|---|---|---|
| Freelancer / Einzelentwickler | 1 Subscription, 2–3 Ressourcengruppen (Dev, Test, Shared) | Tagging-Policy, Cost Budget Alert, Azure Policy (Built-in) | Niedrig (0,5–1 Tag) |
| KMU (bis ~50 Azure-Nutzer) | 2–3 Subscriptions (Prod, Non-Prod, Connectivity), flache Management-Group-Hierarchie | Deployment Stack für Baseline, Azure Policy, Microsoft Defender for Cloud (Free Tier) | Mittel (2–5 Tage) |
| Enterprise / Konzern | Azure Landing Zone (ALZ) mit vollständiger Management-Group-Hierarchie und Plattform-Subscriptions | ALZ-Accelerator (Bicep), Deployment Stacks, Azure Policy Initiative, Sentinel, Defender for Cloud (Standard) | Hoch (Wochen bis Monate) |
Die Management-Group-Hierarchie einer typischen Azure Landing Zone – Plattform und Applikations-Subscriptions klar getrennt.
Praxisempfehlung: So bauen Sie eine KMU-taugliche Governance-Basis heute
Noch mal in Kürze – kurz, knapp und strukturiert, zum Abharken:
- Management Groups einrichten: Auch für KMUs lohnt sich eine minimale Hierarchie: Tenant Root → Unternehmens-MG → Prod / Non-Prod. Das ermöglicht Policy-Vererbung ohne Overhead.
- Azure Policy aktivieren: Mindestens: Tagging-Pflicht (z. B.
CostCenter,Environment), erlaubte Regionen auf Deutschland beschränken, Defender-Einstellungen erzwingen. - Baseline per Deployment Stack deployen: Log Analytics Workspace, Diagnoseeinstellungen, Budget-Alerts und grundlegende Netzwerkressourcen als Bicep-Template definieren und als Stack deployen – mit
denyWriteAndDelete. - Blueprints-Migration planen: Falls noch vorhanden, bis Q2 2026 auf Bicep + Deployment Stacks migrieren. Microsoft stellt dafür eine offizielle Migrationsdokumentation bereit.
- Kein ALZ-Overkill: Eine vollständige Landing Zone lohnt sich ab ca. 5–10 Applikationsteams oder wenn Netzwerksegmentierung und zentrale Sicherheitssteuerung zwingend notwendig sind.
Ich hatte mich in diesem Zusammenhang intensiv mit dem ALZ-Accelerator beschäftigt und kann sagen: Der Bicep-basierte Ansatz ist deutlich wartbarer als alles, was Blueprints je ermöglicht haben – vorausgesetzt, man versteht die zugrundeliegende Management-Group-Logik. Genau das arbeiten wir in meinen Azure-Kursen Schritt für Schritt durch, vom ersten Policy-Assignment bis zum vollständigen Stack-Deployment.
Merksatz: Azure Governance ist kein einmaliges Setup, sondern ein kontinuierlicher Prozess. Deployment Stacks halten die Baseline konsistent – aber nur, wenn die Bicep-Templates auch gepflegt werden.