Infrastructure as Code ist schon vor Jahren kein Differenzierungsmerkmal mehr gewesen; 2026 gehört es zum Pflichtprogramm. Was Teams nach wie vor unterscheidet, ist, wie gut sie es betreiben: ob der State ein Risiko oder ein Nicht-Ereignis ist, ob Policies vor dem Apply durchgesetzt oder erst nach einem Incident entdeckt werden, und ob die Frage „Was läuft eigentlich in Produktion?" von Git beantwortet wird oder eine archäologische Ausgrabung erfordert. Dieser Artikel behandelt die Terraform-Grundlagen, die IaC angenehm unspektakulär halten, sowie die GitOps-Schicht, die dieselbe Disziplin auf Kubernetes-Workloads ausdehnt.

Terraform-Grundlagen richtig gemacht

Der State ist das Kronjuwel

Der Terraform-State bildet Ihren Code auf reale Ressourcen ab und enthält häufig Secrets im Klartext. Er gehört in ein verschlüsseltes Remote-Backend mit Locking, mit einem Zugriff, der so streng beschränkt ist wie Ihre Produktions-Credentials — niemals ins Repository. Seit Terraform 1.10 unterstützt das S3-Backend natives Locking auf Lockfile-Basis, sodass für neue Konfigurationen keine separate DynamoDB-Tabelle mehr nötig ist:

terraform {
  required_version = ">= 1.10"

  backend "s3" {
    bucket       = "org-terraform-state"
    key          = "network/prod/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

Teilen Sie den State nach Blast Radius auf: eine State-Datei pro Umgebung und Komponente, damit ein Fehler in einem Staging-Modul nicht das Produktionsnetzwerk beschädigen kann. State-Chirurgie mit terraform state mv ist gelegentlich notwendig; sie wöchentlich zu brauchen, ist ein Design-Smell.

Module: klein, versioniert, komponierbar

Gute Module kapseln genau eine Entscheidung — ein VPC-Layout, eine gehärtete Datenbankinstanz, einen Standardsatz an IAM-Rollen — und bieten eine kleine Variablenoberfläche. Pinnen Sie Modulversionen über Registry-Constraints oder Git-Tags, damit eine Upstream-Änderung niemals implizit in Produktion landet. Widerstehen Sie dem riesigen „Plattform-Modul", das alles umschließt: Es koppelt jeden Konsumenten an jede Änderung und macht aus jedem Upgrade ein Koordinationsprojekt.

Workspaces haben eine eng umrissene Aufgabe

Terraform-Workspaces eignen sich für kurzlebige Kopien derselben Konfiguration — Preview-Umgebungen, Test-Stacks pro Branch. Für die Trennung von Dev und Prod sind sie das falsche Werkzeug, denn jeder Workspace teilt dieselbe Backend-Konfiguration, denselben Codepfad und allzu oft dieselben Credentials. Für echte Umgebungen sind separate Verzeichnisse (oder Repositories) mit separatem State und separaten Cloud-Konten vorzuziehen; die Verzeichnisstruktur macht dann den Blast Radius explizit sichtbar.

Policy as Code

Code-Review skaliert nicht als Compliance-Mechanismus. Kodieren Sie die Regeln — keine öffentlich lesbaren Buckets, verpflichtende Kostenzuordnungs-Tags, freigegebene Instance-Familien, überall TLS 1.2 oder neuer — als Policies, die in der CI gegen den Terraform-Plan ausgewertet werden, mit Werkzeugen wie OPA mit Conftest, HashiCorp Sentinel oder Checkov. Ein fehlgeschlagener Policy-Check blockiert den Merge mit einer Meldung, auf die der Autor reagieren kann — das ist schneller und weniger konfliktträchtig, als wenn ein Mensch zum zehnten Mal auf dasselbe Problem hinweist. Policy-Checks gehören in dieselbe Pipeline wie terraform plan; falls Sie diese Pipeline gerade aufbauen, behandelt unser Grundlagenartikel darüber, was CI/CD tatsächlich umfasst, die Fundamente.

Drift ist ein Signal, kein Ärgernis

Drift entsteht, wann immer die Realität vom Code abweicht: ein Konsolen-Hotfix während eines Incidents, ein Operator, der „nur kurz etwas prüft", ein Autoscaler, der seine Arbeit tut. Erkennen Sie ihn, indem Sie einen geplanten terraform plan gegen jeden State laufen lassen und bei nicht-leeren Diffs alarmieren. Behandeln Sie dann jeden Befund als Information — wiederkehrender Drift an derselben Stelle bedeutet meist, dass dem Code ein Stellrad fehlt, das die Leute wirklich brauchen; die Lösung ist, die Variable hinzuzufügen, nicht, dem Team eine Standpauke zu halten.

GitOps mit ArgoCD und Flux

Für Kubernetes-Workloads kehrt GitOps das Deployment-Modell um: Statt dass die CI Manifeste in den Cluster pusht, zieht ein Controller im Cluster — ArgoCD oder Flux — kontinuierlich den Soll-Zustand aus Git und gleicht den Cluster darauf ab. Die Vorteile sind struktureller Natur. Drift-Korrektur ist eingebaut, weil der Controller bei jedem Sync die Git-Version der Wahrheit erneut anwendet. Die Credential-Lage verbessert sich, weil nichts außerhalb des Clusters Apply-Zugriff benötigt. Und Rollback ist git revert — mit dem vollständigen Audit-Trail, den das impliziert.

ArgoCD passt zu Teams, die eine UI, Health-Ansichten auf Anwendungsebene und App-of-Apps-Komposition wollen; Flux passt zu Teams, die ein schlankeres, CRD-getriebenes Toolkit bevorzugen, das sich mit Kustomize und Helm kombinieren lässt. Beide sind ausgereift — die Wahl ist eine Frage der Ergonomie, nicht der Fähigkeiten. Für welches Sie sich auch entscheiden: Aktivieren Sie automatisches Sync mit Self-Healing in Produktion erst, wenn Ihr Alerting Ihnen sagen kann, warum ein Sync fehlgeschlagen ist; die Muster aus unserem Beitrag Kubernetes im echten Leben gelten hier unmittelbar.

Änderungen über Umgebungen hinweg promoten

Environment Promotion ist der Punkt, an dem sich IaC- und GitOps-Disziplin auszahlt oder zerbricht. Die Regel: Promoten Sie Artefakte, keine Rebuilds. Das Container-Image, das Staging bestanden hat, ist Byte für Byte dasselbe Image, das Produktion erreicht; nur die Konfiguration — Replica-Anzahl, Ressourcenlimits, Endpoints — unterscheidet sich, ausgedrückt als Kustomize-Overlays oder umgebungsspezifische Helm-Values. Die Promotion selbst ist ein Pull Request, der ein Image-Tag oder eine Values-Datei im Verzeichnis der Umgebung aktualisiert — geprüft und gemergt wie jede andere Änderung auch. Keine Umgebung ist ein Sonderfall: Dev, Staging und Prod unterscheiden sich in Daten und Größenordnung, niemals im Mechanismus.

Teams, die das richtig umsetzen, liefern Infrastrukturänderungen mit derselben Taktung und Zuversicht aus wie Anwendungscode. Wenn Ihres noch nicht so weit ist — State verstreut auf Laptops, Konsolenänderungen, die niemand dokumentiert hat, Deployments, die von einer einzigen Person abhängen —, hilft unsere DevOps-Solutions-Practice Teams dabei, Terraform, Policy as Code und GitOps in geordnete Bahnen zu bringen.

Planen Sie eine Migration? Unsere AWS-Migrationsleistungen bringen Sie in 8–16 Wochen auf ein Well-Architected-Fundament — Festpreis, gestaffelter Cutover, Rollback-Plan in Schriftform.

Tags: #Terraform #GitOps #ArgoCD #Flux #IaC