Infrastrukturdrift in Terraform für Azure verhindern und beheben

Von Mirko Peters · 2026-10-28

Erfahren Sie, wie Infrastrukturdrift in Terraform und Azure entsteht, wie Notfall-Hotfixes im Portal Statusdateien inkonsistent machen und wie Sie Abweichungen sicher erkennen und korrigieren.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Infrastrukturdrift gehört zu den häufigsten und gefährlichsten stillen Risiken in modernen Cloud-Umgebungen. Nehmen Engineers im Notfall manuelle Anpassungen direkt im Azure-Portal vor, bricht dadurch leise die Synchronisation mit den Code-Repositories ab. Dieser umfassende Leitfaden zeigt, wie Drift entsteht, welche Risiken er für Ihre Statusdateien birgt und wie Sie Abweichungen systematisch erkennen und beheben, ohne einen Produktionsausfall zu verursachen.

Das Wichtigste in Kürze

• Infrastrukturdrift entsteht, wenn manuelle Änderungen in der Cloud-Konsole von Ihrem deklarierten Terraform-Code abweichen.
• Notfall-Hotfixes, die direkt in der Produktivumgebung vorgenommen werden, umgehen die Versionskontrolle und führen bei künftigen Plan-Läufen zu stillen Fehlern.
• Die Terraform-Statusdatei fungiert als Speicherbrücke, die Ihre geschriebene Konfiguration, den vorherigen Zustand und die tatsächlichen Cloud-Ressourcen miteinander vergleicht.
• Frühzeitiges Erkennen von Drift erfordert regelmäßige automatisierte Plan-Läufe und eine strikte Richtlinie gegen nicht dokumentierte manuelle Portaländerungen.
• Um Drift zu beheben, müssen Sie entscheiden, ob Sie die Live-Umgebung an den Code zurückführen oder Ihre Konfiguration an die Realität angleichen.

Was ist Infrastrukturdrift und warum entsteht sie?

Selbst die diszipliniertesten Cloud-Engineering-Teams werden irgendwann Opfer von Infrastrukturdrift. Als Drift gilt jede nicht autorisierte, nicht dokumentierte oder im Notfall vorgenommene Änderung an Cloud-Ressourcen, durch die ein Zustand außerhalb Ihrer automatisierten Pipelines verwaltet wird. Stellen Sie sich vor: Ein Engineer wird mitten in der Nacht zu einem Vorfall alarmiert. Unter Druck meldet er sich im Azure-Portal an, erhöht ein Auto-Scaling-Limit von fünf auf zehn Instanzen, behebt das Problem und geht wieder schlafen.

Das Problem: Die versionierte Konfigurationsdatei im Repository nennt weiterhin fünf. Die Live-Umgebung hat zehn. Weil niemand die Änderung dokumentiert oder den Code angepasst hat, entsteht eine erhebliche Diskrepanz zwischen der geplanten Architektur und der Realität. Diese Lücke bleibt oft wochenlang verborgen, bis jemand einen routinemäßigen Terraform-Plan für eine ganz andere Änderung ausführt. Plötzlich zeigt die Terminalausgabe eine Warnung: Terraform will diese Instanzen wieder auf fünf reduzieren.

Der menschliche Faktor und der operative Druck

Drift entsteht selten aus böser Absicht, sondern fast immer aus operativer Dringlichkeit. Wenn Produktivumgebungen ausfallen, drängt der Instinkt dazu, den Schaden sofort mit den schnellsten verfügbaren Mitteln zu beheben. Klickbasierte Bereitstellung im Azure-Portal ist schnell, greifbar und unmittelbar. Doch jedes Mal, wenn ein Problem über das Portal behoben und nicht im Code festgehalten wird, entsteht technische Schuld, die später mit Zinsen zurückgezahlt werden muss.

Wie der Terraform-Status Abweichungen erkennt

Um zu verstehen, wie Terraform Drift erkennt, müssen Sie sich den Speichermechanismus genauer ansehen: die Statusdatei. Die Terraform-Statusdatei ist die maßgebliche Quelle der Wahrheit und ordnet Ihre Cloud-Ressourcen den Konfigurationsdateien zu. Wenn Sie einen Befehl ausführen, schiebt Terraform Dateien nicht einfach blind in die Cloud. Stattdessen führt es einen Dreiwege-Vergleich durch.

Erstens liest es, was Sie in Ihren Konfigurationsdateien geschrieben haben. Zweitens prüft es, was es bei der letzten erfolgreichen Anwendung in der State-Datei festgehalten hat. Drittens wendet es sich über Plugins an die API des Cloud-Anbieters und prüft, was in Ihrem Abonnement gerade tatsächlich existiert. Stimmen diese drei Elemente nicht überein, erkennt Terraform, dass sich die Realität still und leise verändert hat.

Die Gefahr ignorierter Warnungen

Bei der Ausführung eines Plans erstellt Terraform eine detaillierte Ausgabe mit Hinzufügungen, Änderungen und Löschungen. Liegt Drift vor, sehen Sie oft Warnungen, dass eine Ressource geändert oder sogar vollständig ersetzt werden muss. Einsteiger geraten häufig in Panik, wenn sie Warnungen zu erzwungenen Ersetzungen von Ressourcen sehen. Diese Warnung ist jedoch kein Fehler. Terraform teilt Ihnen damit mit, dass sich die reale Ressource bis zur Unkenntlichkeit verändert hat. Um sie wieder mit Ihrem Code in Einklang zu bringen, muss sie gelöscht und neu erstellt werden.

Bewährte Methoden zur Erkennung und Vermeidung von Drift

Drift zu verhindern erfordert eine Kombination aus organisatorischen Leitplanken und automatisierten technischen Kontrollen. Wenn Sie die Drift-Erkennung vollständig manuellen Prüfungen überlassen, werden Sie zwangsläufig schmerzhafte Produktionsausfälle erleben. Hier sind die grundlegenden Strategien, mit denen Teams ihre Cloud-Umgebungen abgestimmt halten:

• Nur-Lese-Zugriff erzwingen: Entziehen Sie menschlichen Benutzern Schreibberechtigungen in der Produktion. Lassen Sie alle Infrastrukturänderungen ausschließlich über Ihre CI/CD-Pipelines und Pull-Request-Reviews laufen.
• Automatisierte Plan-Läufe planen: Richten Sie Continuous-Integration-Pipelines ein, die regelmäßig „terraform plan“-Befehle ausführen, ohne sie anzuwenden. Prüfen Sie die Ausgabe auf unerwartete Änderungen.
• Monolithische State-Dateien aufteilen: Teilen Sie große Umgebungen in kleinere, modulare Komponenten auf. Kleinere State-Dateien machen es einfacher, Drift zu isolieren, zu prüfen und zu beheben.
• Remote-State-Sperren implementieren: Stellen Sie sicher, dass Ihr Team sichere Remote-Backends mit State-Sperren nutzt, damit parallele Läufe die Zustandsaufzeichnungen nicht beschädigen.

Drift beheben, sobald er auftritt

Wenn Sie feststellen, dass Ihre Live-Infrastruktur von Ihrer Konfiguration abweicht, stehen Sie vor einer strategischen Weggabelung. Für die Behebung gibt es zwei Hauptwege:

Die erste Option besteht darin, Terraform die Live-Umgebung überschreiben zu lassen. Mit dem üblichen „terraform apply“ zwingen Sie Azure, zu dem Zustand zurückzukehren, der in Ihrem Code beschrieben ist. Das ist der richtige Weg, wenn die Abweichung durch eine nicht autorisierte manuelle Änderung oder eine temporäre Debug-Einstellung entstanden ist, die nicht mehr bestehen sollte.

Die zweite Option besteht darin, Ihre Terraform-Konfiguration an die Realität anzupassen. Wählen Sie diesen Weg, wenn sich der manuelle Hotfix während eines Vorfalls als notwendig, stabil und für die Produktion vorteilhaft erwiesen hat. Indem Sie Ihren Code an die neue Realität anpassen, schließen Sie die Lücke und stellen sicher, dass künftige automatisierte Läufe die notwendige Konfiguration beibehalten.

Fazit

Infrastruktur-Drift ist eine unvermeidbare Herausforderung in dynamischen Cloud-Umgebungen, muss für Ihr Team aber nicht das Ende bedeuten. Wenn Sie verstehen, wie die State-Datei von Terraform Änderungen nachverfolgt, strikte Zugriffskontrollen umsetzen und die Drift-Erkennung als regelmäßige betriebliche Routine etablieren, behalten Sie die volle Kontrolle über Ihre Cloud-Architektur. Um die grundlegenden Mechanismen von Infrastructure as Code, Providern und State-Management ausführlicher kennenzulernen, hören Sie sich die vollständige Episode an und erhalten alle Einblicke unserer Experten, um Ihre Strategie für die Cloud-Automatisierung auf das nächste Level zu heben.

Häufige Fragen

Was verursacht Infrastruktur-Drift in Terraform?

Drift entsteht durch Änderungen außerhalb von Terraform, die direkt an Cloud-Ressourcen über Portale, CLI-Befehle oder Skripte vorgenommen werden und die Terraform-Pipeline umgehen.

Wie erkennt Terraform Konfigurations-Drift bei einem Plan-Lauf?

Terraform vergleicht die gespeicherte State-Datei mit den tatsächlichen Live-Cloud-Ressourcen über Provider-APIs und mit Ihren lokalen Konfigurationsdateien.

Was passiert, wenn jemand eine von Terraform verwaltete Azure-Ressource manuell ändert?

Beim nächsten Terraform-Plan-Lauf erkennt Terraform die Abweichung, markiert sie und versucht, die Ressource wieder an Ihren deklarierten Code anzupassen, sofern die Konfiguration nicht aktualisiert wurde.

Sollte ich meinen Terraform-Code anpassen oder die Änderung im Azure-Portal rückgängig machen?

War die manuelle Änderung ein Notfall-Hotfix, der jetzt für die Stabilität erforderlich ist, aktualisieren Sie Ihre Terraform-Konfiguration. Handelte es sich um eine nicht autorisierte oder versehentliche Änderung, lassen Sie Terraform sie zurücksetzen.