Terraform Drift in AWS: Früherkennung und sichere Korrektur

Terraform Drift bedeutet, dass der echte Zustand in AWS nicht mehr zum Zustand im Terraform-Code oder State passt. Genau das macht Infrastruktur unberechenbar. Plötzlich greift ein terraform apply Dinge an, die niemand bewusst ändern wollte, oder ein Security-Change aus der Konsole verschwindet beim nächsten Rollout wieder.

Was ist Terraform Drift?

Drift entsteht, wenn Ressourcen außerhalb von Terraform verändert werden. Das passiert schnell: ein Security-Group-Rule wird manuell ergänzt, ein Load Balancer in der Konsole angepasst oder ein Tag von einem anderen Tool überschrieben. Der State kennt diese Änderung nicht sauber oder bewertet sie anders als der Live-Zustand.

Praxisregel: Je mehr Personen oder Tools direkt in AWS schreiben, desto höher das Drift-Risiko.

Warum entsteht Drift in AWS so oft?

AWS macht manuelle Eingriffe extrem einfach. Genau das ist im Incident hilfreich, langfristig aber gefährlich. Typische Ursachen:

Hotfixes direkt in der AWS-Konsole
Mehrere Automationstools schreiben an dieselben Ressourcen
Fehlende Ownership für einzelne Terraform-Stacks
Importierte Legacy-Ressourcen wurden nie vollständig bereinigt

Besonders kritisch wird es bei IAM, Security Groups, Route Tables und Autoscaling-Regeln. Dort führen kleine Abweichungen schnell zu echten Betriebs- oder Sicherheitsproblemen.

Drift früh erkennen, bevor sie Schaden macht

Drift sollte nicht erst bei einem Produktions-Apply sichtbar werden. Sinnvoll ist ein fester Kontrollpfad im Alltag:

regelmäßiges terraform plan in CI oder Cron
Plan-Ausgaben als Review-Artefakt speichern
kritische Stacks mit klarer Freigabe vor jedem Apply
manuelle AWS-Änderungen in Incident-Runbooks dokumentieren

bash

terraform init
terraform plan -detailed-exitcode

# Exit Code 0 = keine Änderung
# Exit Code 2 = Drift oder geplante Änderung erkannt
# Exit Code 1 = Fehler

Für kleine Teams reicht oft schon ein täglicher Read-only-Plan auf die wichtigsten Produktions-Stacks. Wichtig ist nur: Das Ergebnis muss sichtbar sein und jemand muss dafür verantwortlich sein.

Sichere Korrektur ohne neues Chaos

Nicht jede Drift sollte sofort blind zurückgerollt werden. Die richtige Reihenfolge ist:

verstehen, was wirklich geändert wurde
prüfen, ob die Live-Änderung gewollt oder ein Notfall-Fix war
entscheiden, ob Code oder Infrastruktur der neue Soll-Zustand wird
erst dann Terraform-State und Code sauber angleichen

Wenn die Live-Änderung korrekt war, gehört sie in den Code. Wenn sie ein Fehler war, wird sie bewusst per Terraform zurückgeführt. Alles andere erzeugt nur neue Unsicherheit.

Was kleine Teams vermeiden sollten

direkt in Produktion apply ausführen, ohne Plan zu lesen
mehrere Root-Module auf dieselbe Ressource loslassen
Notfall-Änderungen nachträglich nicht dokumentieren

Fazit

Terraform Drift ist kein Spezialproblem großer Plattformteams, sondern ein normales Risiko im AWS-Alltag. Wer Drift früh erkennt, Ownership sauber regelt und Korrekturen bewusst statt hektisch macht, hält Infrastruktur stabil und nachvollziehbar.