Azure

Bicep

Allgemeine Infos

Bicep ist eine domänenspezifische Sprache (DSL) für Azure-Deployments. Du beschreibst den gewünschten Zustand, Azure Resource Manager setzt ihn um. Bicep ist kostenlos, Open Source und wird vom Microsoft-Support abgedeckt.

Anders als Terraform braucht Bicep keine eigene State-Datei, weil Azure den Deployment-Zustand selbst speichert. Neue Ressourcentypen und API-Versionen sind ab dem Tag nutzbar, an dem der Ressourcenanbieter sie veröffentlicht. Dafür ist Bicep auf Azure beschränkt.

Rund um Bicep sind Azure Verified Modules als geprüfte Bausteine, Parameterdateien im .bicepparam-Format, private Modul-Registries in Azure Container Registry und Deployment Stacks für den Lebenszyklus entstanden. Deployment Stacks sind auch der offizielle Nachfolger von Azure Blueprints.

Funktionsweise & Details

Bicep im Arbeitsalltag:

  1. Ressourcen werden mit symbolischen Namen deklariert. Verweist eine Ressource auf eine andere, erkennt Bicep die Abhängigkeit selbst, dependsOn ist meist überflüssig.
  2. Module kapseln wiederverwendbare Teile, etwa ein Standard-VNet oder einen Key Vault.
  3. Parameter, Variablen, Schleifen und Bedingungen machen eine Datei für mehrere Umgebungen nutzbar.
  4. Beim Deployment per Azure CLI oder Azure PowerShell wird die Datei zu ARM-JSON kompiliert und an ARM übergeben.
  5. What-if zeigt vorab Änderungen, Linter-Regeln in VS Code prüfen Stil und Fehler.

Bestehende ARM-Templates lassen sich mit dem Befehl decompile nach Bicep übertragen, das Ergebnis sollte aber manuell nachgearbeitet werden.

Vorteile & Nutzen

  • Deutlich weniger Code als JSON, dadurch leichter zu lesen, zu prüfen und zu warten
  • Sofortige Unterstützung neuer Azure-Funktionen ohne Warten auf einen Provider
  • Keine State-Datei, die gesichert, gesperrt und geschützt werden muss
  • Module und Azure Verified Modules sparen Entwicklungszeit und sorgen für einheitliche Standards

Praxisbeispiel

Das IT-Team eines Kunststoffverarbeiters mit zwei Administratoren hat seine Azure-Umgebung bisher per Klick im Portal gebaut. Für eine zweite Region schreibt es Bicep-Module für Hub-VNet, Firewall-Regeln und Log Analytics, gestützt auf Azure Verified Modules. Eine Pipeline in Azure DevOps führt What-if aus und wartet auf Freigabe. Der Aufbau der zweiten Region dauert damit einen Tag statt einer Woche, und beide Regionen sind nachweislich gleich konfiguriert.

Worauf sollte man achten?

  • Modulstruktur und Namenskonventionen vor dem ersten großen Projekt festlegen
  • Secrets nie hart codieren, sondern Parameter mit @secure() und Key-Vault-Referenzen verwenden
  • What-if fest in jede Pipeline einbauen, bevor Änderungen produktiv gehen
  • Eigene Module versionieren und in einer privaten Registry bereitstellen
  • Für Multi-Cloud-Szenarien prüfen, ob Terraform die bessere Wahl ist

Lizenz & Verfügbarkeit

Kostenlos und Open Source, vom Microsoft-Support abgedeckt (ausgenommen experimentelle Funktionen). Stand: Oktober 2026.

Fazit

Bicep ist der Standardweg für Infrastructure as Code in reinen Azure-Umgebungen. Fang mit kleinen Modulen an und baue darauf eine Bibliothek auf.

Weiterführende Links

Verwandte Artikel