Wenn du mit Terraform arbeitest, verlässt du dich auf eine einfache Annahme: Der State beschreibt, was in der Cloud existiert, und deine Konfiguration beschreibt, was existieren soll. Solange beide übereinstimmen, plant Terraform zuverlässig.

Drift ist der Moment, in dem diese Annahme nicht mehr stimmt. Jemand hat eine Security Group über die Konsole geändert, ein Auto-Scaling-Vorgang hat eine Instanz ersetzt, ein anderes Tool hat ein Tag entfernt. Dein State weiß davon nichts. Er beschreibt weiterhin den letzten Zustand, den Terraform selbst gesetzt hat, nicht den Zustand, der jetzt tatsächlich läuft.

Das HashiCorp-Tutorial zu Resource Drift beschreibt genau diesen Effekt: Wenn eine von Terraform verwaltete Ressource außerhalb des üblichen Workflows geändert wird, gerät die State-Datei „out of sync, or ‚drift,‘ from the real infrastructure“ (HashiCorp, Manage resource drift). Drift ist damit kein Fehler im Werkzeug, sondern eine Lücke zwischen zwei Aufzeichnungen: dem, was Terraform zu wissen glaubt, und dem, was in der Cloud tatsächlich liegt.

Die häufigsten Ursachen für Drift

In deiner Infrastruktur entsteht Drift fast nie aus Bosheit, sondern aus Druck und Bequemlichkeit:

• Manuelle Console-Änderungen. Ein Hotfix unter Zeitdruck, ein schnell geöffneter Port, eine Umgebungsvariable, die direkt im Dienst gesetzt wird, weil ein Review-Zyklus zu lange dauert.
• Andere Werkzeuge greifen auf dieselben Ressourcen zu. Ein Konfigurationsmanagement-Tool, ein Cloud-Provider-eigenes Autoscaling, ein Sicherheitsteam, das im Rahmen einer Incident-Reaktion Regeln anpasst.
• Nicht deterministische Cloud-Mechanismen. Auto-Scaling-Gruppen tauschen Instanzen aus, verwaltete Datenbanken rotieren Zertifikate, Load Balancer passen Health-Check-Parameter automatisch an.
• Parallele Pipelines ohne gemeinsamen State. Zwei Teams, zwei Terraform-Workspaces, eine gemeinsam genutzte Ressource.

Jede dieser Ursachen hat eines gemeinsam: Die Änderung passiert außerhalb von terraform apply. Genau das macht sie für dich unsichtbar, bis du gezielt nachsiehst.

Drift erkennen: terraform plan als Diagnosewerkzeug

terraform plan vergleicht standardmäßig drei Dinge: deine Konfiguration, den State und den tatsächlichen Zustand der Ressourcen beim Cloud-Anbieter. Bevor Terraform einen Plan erstellt, fragt es die reale Infrastruktur ab und aktualisiert seine interne Sicht darauf. Taucht dabei eine Abweichung auf, die nicht aus einer Code-Änderung stammt, hast du es mit Drift zu tun.

Das Resource-Drift-Tutorial von HashiCorp empfiehlt für die gezielte Suche genau diesen Befehl: „Run terraform plan -refresh-only to determine the drift between your current state file and actual configuration“ (HashiCorp, Manage resource drift). Der Unterschied zum gewöhnlichen terraform plan ist der Fokus: -refresh-only zeigt ausschließlich die Abweichung zwischen State und Realität, ohne sie mit geplanten Code-Änderungen zu vermischen. Das Ergebnis liest sich dann nicht als „diese Ressource wird erstellt oder geändert“, sondern als „diese Ressource hat sich außerhalb von Terraform verändert“.

Ergänzend hilft terraform show, den aktuellen State lesbar auszugeben und eine Ressource gezielt zu prüfen, bevor du überhaupt einen Plan anstößt.

terraform plan -refresh-only: nur hinsehen, nichts anfassen

-refresh-only ist ein eigener Planungsmodus. Die offizielle CLI-Dokumentation beschreibt sein Ziel so: Der Modus „creates a plan whose goal is only to update the Terraform state and any root module output values“ (HashiCorp, Terraform CLI: plan, Planning Modes). Er verändert also nicht deine Cloud-Ressourcen und nicht deine Konfiguration, sondern ausschließlich die Aufzeichnung, die Terraform über sie führt.

Technisch solltest du wissen: Der Modus schließt laut Dokumentation andere Planungsmodi in derselben Ausführung aus, die Optionen -refresh=false und -minimal-refresh sind darin nicht zulässig, und er steht erst seit Terraform v0.15.4 zur Verfügung (HashiCorp, ebenda). Du kannst ihn sowohl mit terraform plan als auch mit terraform apply kombinieren.

refresh-only apply versus normaler apply: zwei Richtungen, ein Unterschied

Hier liegt der Punkt, an dem du Drift am häufigsten missverstehst: Ein normaler terraform apply und ein terraform apply -refresh-only laufen in entgegengesetzte Richtungen.

Der normale Modus, den die CLI-Dokumentation als Standardverhalten beschreibt, „changes the remote system to match the changes you make to your configuration“ (HashiCorp, ebenda). Dein Code und dein State sind hier die Quelle der Wahrheit, die Cloud-Ressource wird daran angepasst.

terraform apply -refresh-only tut das Gegenteil. Laut Tutorial „does not attempt to modify your infrastructure to match your Terraform configuration“ (HashiCorp, Manage resource drift). Terraform zeigt dir die erkannte Abweichung, fragt dich nach Bestätigung, und schreibt nach einem „yes“ ausschließlich den State fort, damit er wieder zur realen Infrastruktur passt. Die Cloud-Ressource bleibt unverändert, und deine Konfiguration bleibt unverändert. Willst du danach, dass dein Code dasselbe beschreibt wie der aktualisierte State, musst du die Konfiguration separat nachziehen.

Die Verwechslung beider Modi ist der teuerste Fehler, den du im Umgang mit Drift machen kannst: Führst du bei einer entdeckten Abweichung reflexartig terraform apply ohne -refresh-only aus, riskierst du, dass Terraform die manuell vorgenommene Änderung wieder zurückdreht, etwa einen Hotfix, der gerade einen Vorfall eindämmt.

ignore_changes: bewusste Ausnahme statt stille Notlösung

Manche Abweichungen sind erwünscht und sollen gar nicht als Drift gemeldet werden. Dafür steht dir im lifecycle-Block das Meta-Argument ignore_changes zur Verfügung. Die offizielle Dokumentation nennt den Anwendungsfall so: „Use the ignore_changes argument when a resource is created with references to data that may change in the future“ (HashiCorp, Terraform Language: lifecycle meta-argument), und beschreibt seine Funktion als Angabe von Attributen, „that Terraform should ignore when planning updates“ (ebenda).

Wichtig für dein Verständnis: Terraform berücksichtigt die angegebenen Attribute weiterhin beim Erstellen einer Ressource, ignoriert sie aber beim Planen einer Aktualisierung. Mit dem Schlüsselwort all kannst du die Ausnahme auf alle Attribute ausweiten, und sie greift laut Dokumentation ausschließlich auf Attribute, die der jeweilige Ressourcentyp auch tatsächlich definiert.

HashiCorp ordnet das Meta-Argument explizit seltenen Fällen zu, in denen ein externer Prozess die Verwaltung eines Objekts mit Terraform teilt (HashiCorp, ebenda). Das ist der entscheidende Unterschied zu der Praxis, die dir in echten Projekten öfter begegnet: ignore_changes wird dort häufig eingesetzt, um einen lästigen Drift-Alarm zum Schweigen zu bringen, statt die Ursache der Abweichung zu klären. Setzt du es richtig ein, steht hinter jedem ignore_changes-Eintrag eine dokumentierte Entscheidung, welcher Prozess außerhalb von Terraform dieses Attribut verändert und warum das so bleiben soll, nicht ein Reflex gegen einen roten Plan-Output.

Drift organisatorisch eindämmen

Drift technisch erkennen zu können löst dein Problem nicht, wenn niemand regelmäßig hinsieht. Drei Maßnahmen helfen dir in der Praxis:

1. Regelmäßiger Drift-Check in der CI-Pipeline. Ein geplanter Lauf, der terraform plan (oder gezielt -refresh-only) gegen jede Umgebung ausführt und bei Abweichungen einen Alarm auslöst, macht Drift für dich sichtbar, bevor er zum Problem wird, statt erst beim nächsten regulären Deployment aufzufallen.
2. ignore_changes dokumentiert statt versteckt einsetzen. Gib jeder Ausnahme einen Kommentar im Code, der sagt, welcher externe Prozess dieses Attribut verändert und seit wann die Ausnahme gilt. Ohne diese Dokumentation verschwindet mit der Zeit das Wissen, warum du die Ausnahme überhaupt eingeführt hast.
3. Policy gegen manuelle Console-Änderungen. Schränke Zugriffsrechte auf die Cloud-Konsole so weit ein, dass produktive, von Terraform verwaltete Ressourcen dort gar nicht erst verändert werden können. Was technisch nicht möglich ist, musst du organisatorisch nicht mehr verbieten.

Keine dieser Maßnahmen verhindert Drift vollständig, Hotfixes unter Zeitdruck und automatisches Skalieren lassen sich nicht komplett wegregeln. Sie verhindern aber, dass Drift unbemerkt bleibt, bis ein terraform apply eine falsche Änderung produktiv werden lässt.

Abgrenzung zu anderen Beiträgen auf diesem Blog

Zwei frühere Beiträge auf diesem Blog berühren Terraform-State, behandeln aber ein anderes Problem als dieser Artikel:

„Terraform State absichern: Remote Backend, Locking und Secrets“ (17.06.2026) geht der Frage nach, wo der State liegen soll, wie Locking parallele Läufe verhindert und wie Secrets im State abgesichert werden. Dort geht es um den Schutz des State als Datei, nicht um die Frage, ob der Inhalt des State noch zur Realität passt. Beide Themen berühren sich an der Stelle „State“, lösen aber unterschiedliche Probleme.

„Infrastructure as Code absichern: die typischen Terraform-Fehlkonfigurationen“ (31.07.2026) ist ein Katalog häufiger Fehlkonfigurationen, offene Security Groups, fehlende Verschlüsselung, Secrets im Klartext, zu weite IAM-Policies. Der Fokus liegt darauf, was im Code falsch konfiguriert sein kann, nicht darauf, dass sich eine korrekt konfigurierte Ressource nach dem Deployment unbemerkt von ihrer Beschreibung entfernt. Drift-Erkennung, -refresh-only oder ignore_changes kommen in diesem Beitrag nicht vor.

Und jetzt?

Wenn der letzte Plan-Lauf für eine deiner Umgebungen länger zurückliegt, als du aus dem Kopf sagen kannst, ist das für dich selbst schon ein Signal. Ein terraform plan -refresh-only gegen deine wichtigste produktive Umgebung zeigt dir in wenigen Minuten, ob die Abweichung zwischen State und Realität noch im Rahmen ist oder nicht.

Fragen oder Anmerkungen zu diesem Setup: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.