IaC Struktur Bicep Terraform

Ziel: Änderbarkeit ohne Chaos

Gute IaC-Struktur sorgt dafür, dass Änderungen:

• reviewbar sind (kleine Diffs, klare Verantwortlichkeit)
• reproduzierbar sind (Umgebung = Code + Parameter)
• sicher ausgerollt werden (Staging/Prod, Rollback-Optionen)

Der häufigste Fehler ist nicht das Tool (Bicep vs Terraform), sondern ein Repo, das “alles irgendwie” enthält.

Strukturprinzipien (tool-agnostisch)

• Trenne Plattform und Workloads: Landing-Zone-Assets (MG, Policy, Connectivity) sind andere Changes als App-Ressourcen.
• Module zuerst: Wiederverwendbarkeit entsteht über Module/Components, nicht über Copy/Paste.
• Environments sind Parameter, nicht Kopien: Vermeide identische Ordnerbäume für dev/, prod/, wenn es nur Werte sind.

Ein mögliches Layout:

iac/
  modules/
    network/
    monitoring/
    identity/
  stacks/
    platform/
      mgmt-groups/
      policy/
      connectivity/
    workloads/
      app1/
      app2/
  env/
    nonprod.json
    prod.json

Terraform-spezifisch: State und Isolation

• State pro Stack: Plattform-Connectivity getrennt von Workload-Stacks.
• Remote State: zentral, gesichert, mit Locking.
• Least Privilege für CI: Deployment-Identitäten auf den jeweiligen Stack-Scope begrenzen.

Wenn ein State “alles” enthält, sind Releases unkontrollierbar: eine kleine Workload-Änderung kann eine Plattform-Änderung triggern.

Bicep-spezifisch: Modulare ARM-Lieferung

• Bicep ist stark, wenn du Azure-native Deployments (ARM) sauber modularisierst.
• Nutze Module (lokal oder Registry) und klare Parameterverträge.
• Behalte im Blick: manche Plattformthemen (Policy, MG) sind weniger “app-like” und brauchen andere Release-Zyklen.

Naming, Tagging, Contracts

IaC ist auch ein Contract zwischen Teams:

• Namenskonventionen müssen maschinenlesbar sein.
• Tagging ist nicht “nice to have”, sondern Grundlage für Kosten und Ownership.
• Module sollten Input/Output sauber dokumentieren (was erwartet das Modul, was liefert es?).

Delivery: Pipeline-Patterns

• “Plan”/“What-if” in PRs, Apply nur nach Review.
• Automatisierte Policy Checks (z. B. keine Public IPs, Diagnostics Pflicht) als CI-Guardrails.
• Rollout in Wellen: zuerst Non-Prod, dann Prod.

Praktische Gates, die sich bewährt haben:

• Format/Lint (schnell, deterministisch)
• Validation/Plan/What-if im Pull Request
• Apply nur nach Review und mit klarer Identität (OIDC/Federation bevorzugt)
• Post-Deploy Smoke Checks (z. B. “Policy Assignments sichtbar”, “Diagnostics greifen”)

Je stärker du Guardrails (Policies) einsetzt, desto wichtiger ist dieser PR-Loop: Teams sollen Deploy-Fails in PRs sehen, nicht nachts in Prod.

Häufige Anti-Patterns

• Ein Repo, ein State, ein Pipeline-Job für alles.
• “Umgebungen” als Kopien ganzer Ordnerbäume.
• Secrets im Repo statt Identity-basierter Auth.