Infrastructure as Code (IaC): Infrastruktur automatisieren

Infrastructure as Code (IaC) bedeutet, Infrastruktur per Code zu definieren, zu versionieren und automatisiert bereitzustellen. Statt manuell in Konsolen zu klicken oder Systeme „per Hand“ aufzusetzen, wird der gewünschte Zustand beschrieben – reproduzierbar, reviewbar und auditierbar.

IaC ist damit nicht nur ein Automatisierungsthema, sondern ein Governance‑Baustein: Änderungen an Netz, Compute, Storage und Plattformen werden wie Software behandelt. Gerade im Cloud‑Kontext ist das eine Voraussetzung für skalierbare Migrationen:

• Cloud-Strategie & Migrationsplanung

Warum IaC: typische Probleme ohne Standardisierung

Manuelle Provisionierung erzeugt vorhersehbare Risiken:

• Snowflake‑Infrastruktur: Umgebungen unterscheiden sich, Fehler sind schwer reproduzierbar.

• Langsame Bereitstellung: Neue Umgebungen dauern Tage statt Minuten.

• Fehleranfällige Changes: Kleine Klickfehler werden zu Incidents.

• Unklare Nachvollziehbarkeit: Wer hat wann was geändert – und warum?

• Security Drift: Baselines werden nicht konsistent durchgesetzt.

IaC adressiert das, indem Änderungen in Pull Requests landen, automatisiert geprüft werden und mit klarer Historie ausgerollt werden können.

IaC vs. Configuration Management: sauber trennen

In der Praxis werden Begriffe oft vermischt:

• IaC: Ressourcen erzeugen/ändern (Netz, Accounts, VMs, Managed Services, Kubernetes‑Cluster).

• Configuration Management: Systeme konfigurieren (Packages, Dienste, Konfigdateien, Baselines).

Beide ergänzen sich:

• Automatisiertes Config-Management

Tooling: welche Optionen gibt es?

Terraform (deklarativ, provider‑agnostisch)

Terraform ist der De‑facto‑Standard für IaC in vielen Organisationen:

• Terraform Docs: https://developer.hashicorp.com/terraform/docs

Stärken: großes Provider‑Ökosystem, deklaratives Modell, verbreitete Patterns (Module, Remote State, Workspaces). Wichtig ist ein sauberes Betriebsmodell (State, Locking, Reviews).

OpenTofu (open-source Terraform-Fork)

OpenTofu ist der Community-Fork von Terraform unter der OpenTofu Foundation. Volle Kompatibilität mit bestehenden Terraform-Modulen und States:

• OpenTofu Docs: https://opentofu.org/docs/

Cloud‑native Templates (CloudFormation/ARM/Bicep)

Tiefe Provider‑Integration, oft sinnvoll in stark „single cloud“-orientierten Organisationen – aber mit höherem Lock‑in.

Best Practices, die IaC produktionsreif machen

Modulare Struktur und wiederverwendbare Standards

IaC skaliert über Module/Komponenten:

• wiederverwendbare Module (z. B. Netzwerk, Kubernetes, Datenbank‑Pattern),

• klare Interfaces (Inputs/Outputs), Versionierung der Module,

• „Golden Paths“ statt Copy‑Paste.

Damit werden Standards (Security, Tags, Logging) automatisch mitgeliefert.

State‑Management und Collaboration

Gerade Terraform braucht ein sauberes State‑Modell:

• Remote State (z. B. S3/GCS/Azure Blob),

• Locking gegen parallele Applies,

• getrennte States pro Environment/Workload,

• keine Secrets im State (oder Verschlüsselung/Access Controls sauber lösen).

State ist ein Betriebsmittel – und sollte wie ein kritisches System behandelt werden (Backups, Zugriff, Audit).

Git‑Workflow: Plan/Review/Apply

Ein praxistauglicher Prozess:

• PR erzeugt plan (als Output/Kommentar),

• Review prüft Diff + Policy‑Ergebnisse,

• apply nur aus einem kontrollierten Kontext (CI/CD, nicht vom Laptop),

• klarer Ausnahmeprozess für Notfälle.

Das passt direkt zu CI/CD‑Standards:

• CI/CD-Pipeline-Aufbau

Policy‑as‑Code: Guardrails automatisch prüfen

IaC ist ideal für Guardrails: „Verschlüsselung muss an“, „keine öffentlichen Buckets“, „Tags Pflicht“. Tools:

• Open Policy Agent (OPA): https://www.openpolicyagent.org/

Policy‑as‑Code macht Compliance wiederholbar und verhindert, dass Regeln nur in PDFs existieren.

Testing: Syntax ist nicht genug

Sinnvolle Stufen:

• terraform validate / Lints (z. B. tflint),

• Unit‑Tests für Module (je nach Setup),

• Integration‑Tests für kritische Workflows (z. B. Terratest),

• Policy‑Checks in PRs.

Ziel ist nicht „100% Tests“, sondern Vertrauen: „Änderungen sind beherrschbar“.

Drift, Betrieb und Observability

IaC reduziert Drift – aber verhindert sie nicht automatisch (z. B. manuelle Änderungen, Provider‑Side Effects). Bewährte Maßnahmen:

• klare „No ClickOps“-Regel für produktive Ressourcen,

• regelmäßige Drift‑Erkennung (Plan ohne Apply),

• Logging/Audit‑Events zentralisieren,

• Runbooks für IaC‑Incidents (State Lock, partial applies, Rollbacks).

Weiterführend:

• Dokumentation & Runbooks

• Monitoring & Observability

Häufige Stolpersteine (und wie man sie vermeidet)

Viele IaC‑Einführungen scheitern nicht am Tooling, sondern an Betriebsdetails:

• State als Nebensache: fehlende Backups, zu breite Zugriffe oder kein Locking führen zu kaputten States und riskanten Notfallaktionen.

• Module ohne Ownership: Wenn jeder Module „mal eben“ anpasst, entstehen Breaking Changes und Copy‑Paste‑Forks. Besser: Versionierung, Changelogs, klare Maintainer.

• ClickOps bleibt erlaubt: Manuelle Änderungen in Prod erzeugen Drift und sorgen für Überraschungen beim nächsten Apply. Eine klare Regel („Prod nur per IaC“) und Drift‑Erkennung helfen.

• Zu große Applies: Riesige Change‑Sets sind schwer reviewbar. Besser: kleinere States/Workspaces, klare Slices, gestaffelte Rollouts.

• Secrets im falschen Ort: Secrets gehören nicht in Repos oder ungeschützte Variable Stores. Das muss früh sauber gelöst werden.

Wer diese Stolpersteine adressiert, bekommt deutlich schneller ein IaC‑System, dem Teams vertrauen – und das sich im Alltag betreiben lässt.

FAQ

Terraform oder OpenTofu?

Beide sind praktisch identisch in der Nutzung. OpenTofu ist der Open-Source-Fork unter der Linux Foundation, Terraform wird von HashiCorp unter BSL-Lizenz entwickelt. Für neue Projekte empfehlen wir OpenTofu wegen der offenen Governance. Entscheidend ist das Betriebsmodell (State, Reviews, Policies), nicht der Name.

Wie schützt man den Terraform State?

Remote State mit Locking, restriktive Zugriffe, Backups und klare Notfallprozesse. State ist ein kritisches Betriebsmittel – wie eine Datenbank.

Wie bringt man Compliance in IaC-Changes?

Über Policy‑as‑Code in PRs/CI: Guardrails prüfen, bevor apply läuft, und Ergebnisse versioniert nachweisen. Das ist meist wirksamer als manuelle Checklisten.

Checkliste: IaC‑Einführung in 30–60 Tagen

• Landing Zone/Grundstandards definiert (Tags, IAM, Logging, Netz)

• Repository‑Struktur und Modulstrategie festgelegt

• Remote State + Locking produktionsreif (Zugriff, Backups)

• PR‑Workflow: Plan/Review/Apply in CI etabliert

• Policy‑as‑Code aktiv (mind. kritische Guardrails)

• Runbooks für typische IaC‑Fehlerfälle vorhanden

Fazit

IaC macht Infrastrukturänderungen reproduzierbar, auditierbar und skalierbar. Mit Modulen, sauberem State‑Betrieb, PR‑Workflows und Policy‑as‑Code entsteht ein System, das Cloud‑Adoption beschleunigt – und gleichzeitig Risiken (Security, Kosten, Stabilität) besser kontrollierbar macht.