Azure

Deployment Stacks (Bereitstellungsstapel)

Overview

Ein Deployment Stack ist eine eigene Azure-Ressource (Microsoft.Resources/deploymentStacks), die sich merkt, welche Ressourcen ein Bicep-File, ein ARM-Template oder eine Template Spec angelegt hat. Damit lässt sich eine Anwendung, die über mehrere Resource Groups oder Subscriptions verteilt ist, als Einheit aktualisieren, schützen und wieder entfernen. Stacks gibt es auf Ebene Resource Group, Subscription und Management Group.

Microsoft hat Deployment Stacks im Mai 2024 nach einer Preview-Phase allgemein verfügbar gemacht. Sie sind der offizielle Nachfolger für den Lebenszyklus- und Sperrteil von Azure Blueprints, das bis zum 31. Januar 2027 abgeschaltet wird.

Abgrenzung: ARM-Templates und Bicep beschreiben Ressourcen, ein normales Deployment vergisst sie danach aber. Der Stack hält die Zuordnung dauerhaft. Azure Policy regelt Vorgaben für alle Ressourcen eines Bereichs, ein Stack schützt nur seine eigenen. Die Deny-Einstellungen wirken ähnlich wie Ressourcensperren, lassen sich aber gezielt für Pipelines oder Admin-Gruppen öffnen.

How it works

Ein Stack arbeitet mit zwei zentralen Einstellungen:

  1. ActionOnUnmanage legt fest, was mit Ressourcen passiert, die aus dem Template verschwinden oder beim Löschen des Stacks frei werden: detachAll (nur lösen, Standard), deleteResources (Ressourcen löschen, Resource Groups lösen) oder deleteAll (Ressourcen und Resource Groups löschen).
  2. DenySettingsMode schützt die verwalteten Ressourcen über eine Deny Assignment: none, denyDelete oder denyWriteAndDelete. Bis zu fünf Principals (am besten Entra-Gruppen) und bis zu 200 Aktionen lassen sich ausnehmen, DenySettingsApplyToChildScopes erweitert den Schutz auf untergeordnete Ressourcen.
  3. Angelegt und aktualisiert wird per Azure CLI (az stack group, az stack sub, az stack mg) oder PowerShell (New-AzResourceGroupDeploymentStack, New-AzSubscriptionDeploymentStack, New-AzManagementGroupDeploymentStack, jeweils mit Set-, Get-, Remove- und Save-Varianten). Vorausgesetzt werden Azure CLI ab 2.61.0 oder Az PowerShell ab 12.0.0.

Die Deny-Einstellungen wirken nur auf der Steuerungsebene, nicht auf Datenebene wie Blob-Inhalte oder Secrets, und nicht auf implizit erzeugte Ressourcen, etwa die VMs eines AKS-Clusters. Für Stacks mit Deny-Einstellung braucht es die Rolle Azure Deployment Stack Owner, Azure Deployment Stack Contributor darf keine Deny Assignments setzen. Weicht die Ressourcenliste vom tatsächlichen Zustand ab, verweigert der Stack Änderungen, bis Du den Abgleich bewusst überspringst.

Benefits

  • Eine Anwendung über mehrere Resource Groups lässt sich mit einem Befehl entfernen, weil der Stack Abhängigkeiten und Ressourcenliste selbst kennt
  • Aus dem Template entfernte Ressourcen werden je nach Einstellung gelöst oder gelöscht, dadurch bleiben keine vergessenen Altlasten mit laufenden Kosten zurück
  • denyWriteAndDelete verhindert manuelle Änderungen im Portal, während die Pipeline über eine ausgenommene Gruppe weiter deployen darf
  • Sicherere Alternative zum Complete-Modus bei Deployments, weil gelöschte Ressourcen sichtbar im Stack protokolliert werden
  • Allgemein verfügbarer Migrationspfad für Blueprints-Umgebungen mit vorhandenen Bicep- oder ARM-Dateien

Practical example

Ein Logistikdienstleister mit 600 Beschäftigten betreibt seine Landing Zone für Lagerverwaltungssysteme über Bicep in Azure DevOps. Bisher schützten Blueprints-Sperren das Hub-Netz vor versehentlichem Löschen. Die IT legt einen Stack auf Subscription-Ebene mit denyWriteAndDelete an und nimmt nur die Entra-Gruppe der Pipeline-Identität und die Notfall-Admins aus. Weil der Stack oberhalb der Resource Group liegt, können Projektadmins mit Rechten nur auf der Resource Group die Sperre nicht entfernen. Die Blueprint-Zuweisung wird danach abgebaut.

Things to keep in mind

  • deleteAll nur bewusst setzen, weil der Stack dann ganze Resource Groups samt Inhalt löscht, sobald sie aus dem Template verschwinden
  • Stack eine Ebene höher anlegen als die verwalteten Ressourcen, damit Admins der Ziel-Resource-Group die Deny Assignment nicht entfernen können
  • Ausnahmen über Entra-Gruppen statt einzelne Objekt-IDs pflegen, das Limit von fünf Principals ist sonst schnell erreicht, und verschachtelte Gruppen vorab testen
  • Den Schalter zum Überspringen des Out-of-Sync-Fehlers nicht standardmäßig in Pipelines einbauen, sonst gehen echte Abweichungen unter
  • Datenebene separat absichern, etwa mit RBAC auf Key Vault und Storage, weil Deny-Einstellungen dort nicht greifen

Licensing & availability

Deployment Stacks und Template Specs kosten nichts extra, abgerechnet werden nur die bereitgestellten Ressourcen. Allgemein verfügbar seit Mai 2024. Stand: Oktober 2026.

Conclusion

Deployment Stacks sind der Standard, um Bicep- oder ARM-Bereitstellungen über ihren ganzen Lebenszyklus zu steuern und zu schützen. Wer noch Blueprints nutzt, sollte jetzt auf Stacks umstellen.

Further reading

Related articles