Infrastructure as Code
In fast jeder gewachsenen AWS-Umgebung gibt es zwei Wahrheiten: die in der Konsole und die im Repository. Solange sie auseinanderlaufen, ist jede Änderung ein kleines Risiko und keine Umgebung reproduzierbar. Ich bringe beide zusammen, und zwar in der Richtung, die nichts kaputt macht: Der Bestand wird importiert, nicht nachgebaut.
Bestandsaufnahme und erster Import als abgegrenztes Zwei- bis Vier-Wochen-Mandat, weiter nach Umfang. Der Betrieb bleibt bei Ihrem Team, dafür ist die Übergabe Teil der Arbeit.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Wenn eine Umgebung in der Konsole entstanden ist, gibt es zwei Wege zu Infrastructure as Code. Der erste: alles neu bauen, umschwenken, das Alte abräumen. Der sieht schneller aus, ist aber ein Rewrite – mit allen bekannten Folgen: Er dauert länger als geschätzt, er kann nicht in Schritten geliefert werden, und am Umschaltpunkt hängt alles gleichzeitig. Der zweite Weg ist der Import: Das Bestehende wird beschrieben und unter Verwaltung gebracht, ohne es anzufassen. Seit Terraform 1.5 geht das über import-Blöcke in der Konfiguration, und terraform plan -generate-config-out schreibt daraus einen ersten Entwurf, den man aufräumt statt ihn zu tippen.
Der zweite Befund ist fast immer der State. Er liegt auf einem Laptop, oder in einem Bucket ohne Versionierung, oder es gibt drei davon und niemand weiß, welcher gilt. Dazu fehlt die Sperre, und dann überschreiben zwei gleichzeitige Läufe einander. Das ist heute einfacher zu lösen als früher: Der S3-Backend sperrt seit Terraform 1.11 selbst über eine .tflock-Datei neben dem State, eingeschaltet mit use_lockfile = true; eine eigene DynamoDB-Tabelle braucht es nicht mehr, ihre Argumente sind abgekündigt. Versionierung im Bucket, getrennte Zustände je Umgebung, Verschlüsselung – das ist eine halbe Stunde Arbeit und der Unterschied zwischen einem Werkzeug und einem Risiko.
Der dritte Befund heißt Drift und ist ein Prozessproblem, kein technisches. Solange jemand in der Konsole „nur schnell" etwas ändert, läuft die Beschreibung weg, und beim nächsten apply will Terraform es zurückdrehen. Dagegen hilft kein Werkzeug, sondern eine Entscheidung: Was als Code beschrieben ist, wird nur noch als Code geändert, und wer Schreibrechte in der Konsole behält, weiß warum. Dazu ein regelmäßiger Plan, der Abweichungen meldet, bevor sie jemand im Vorfall entdeckt.
Kommt Ihnen etwas davon bekannt vor?Was ich mache
Zuerst die Frage, welche Ressourcen es überhaupt gibt und welche davon jemand noch braucht. Aus einer gewachsenen Umgebung fällt dabei regelmäßig ein Viertel heraus: Testinstanzen, verwaiste Volumes, Sicherheitsgruppen ohne Ziel. Was weg kann, wird nicht importiert – Aufräumen ist billiger als Beschreiben.
Der Bestand kommt über import-Blöcke unter Verwaltung, bereichsweise und in einer Reihenfolge, die Abhängigkeiten respektiert: erst Netz und Identität, dann Daten, dann Anwendung. Nach jedem Schritt muss terraform plan leer sein – das ist die Abnahmebedingung und gleichzeitig der Beweis, dass die Beschreibung stimmt.
Ein Ort für den State: S3 mit Versionierung, Verschlüsselung und Sperre über use_lockfile, getrennt je Umgebung und je Bereich. Getrennt heißt auch: klein genug, dass ein Lauf Minuten dauert und nicht eine halbe Stunde, denn ein langsamer Plan wird nicht gelesen.
Module entstehen aus Wiederholung, nicht aus Vorfreude. Zwei gleiche Dinge sind Zufall, drei sind ein Muster. Was ein Modul kapselt, wird an seiner Schnittstelle entschieden, und Umbenennungen laufen über moved-Blöcke, damit ein Refactoring im Plan nicht wie Löschen und Neuanlegen aussieht.
Der Plan läuft in der Auslieferungsstrecke: bei jedem Pull Request als Vorschau, nach dem Merge als Anwendung, mit Freigabe für die Produktionsstufe. Dazu ein regelmäßiger Lauf, der Abweichungen meldet. Rechte holt sich die Pipeline über OIDC statt über hinterlegte Schlüssel – dazu gibt es eine eigene Seite.
Zum Abschluss die Dinge, die das Ergebnis haltbar machen: eine kurze Anleitung, wie man eine Ressource hinzufügt, die Regel für Konsolenzugriff, ein Runbook für den Fall eines beschädigten State, und eine Übergabesitzung. Danach legt Ihr Team Infrastruktur an, ohne zu fragen.
Wie lange dauert bei Ihnen eine zweite Umgebung?
Schreiben Sie mir, was heute als Code beschrieben ist und was nicht. Sie bekommen eine Einschätzung, bevor Sie etwas beauftragen.
Ablauf
Vier Schritte, und nach dem zweiten ist ein erster Bereich unter Verwaltung. Kein Schritt setzt voraus, dass Sie den nächsten beauftragen.
Was existiert, was davon wird gebraucht, was ist schon beschrieben. Ergebnis ist eine Karte mit Reihenfolge und Aufwand, und die Liste dessen, was vor dem Import wegkann. Lesezugriff genügt.
Ein abgegrenzter Bereich kommt unter Verwaltung, mit saubererem State und leerem Plan als Abnahme. Damit sehen Sie an einem echten Beispiel, was das Vorgehen kostet und was es bringt.
Bereich für Bereich, nach Abhängigkeiten geordnet. Jeder Schnitt ist einzeln nützlich, und zwischen zwei Schnitten ist die Umgebung immer in einem gültigen Zustand.
Plan und Anwendung laufen in der Auslieferungsstrecke, Drift wird gemeldet, das Team bekommt die Anleitung und eine Sitzung dazu.
Das Ergebnis
Wenn eine Umgebung aus Code entsteht, ist die nächste eine Variable und kein Projekt. Das zahlt sich beim ersten Testsystem aus, das jemand wirklich braucht.
Wer was wann geändert hat, steht im Repository statt in CloudTrail. Das ist auch die Antwort auf die Revisionsfrage, und sie kostet nichts extra.
Was nicht im Code steht, gibt es nicht mehr. Allein das Aufräumen davor senkt in gewachsenen Konten regelmäßig die Rechnung.
Kleine Zustände, kurze Läufe, verständliche Ausgabe. Ein Plan, den man in zwei Minuten prüft, ist der Unterschied zwischen einer Kontrolle und einem Ritual.
Eingesetzte Technologien
Aus der Praxis
Revenue-Reporting im neunstelligen Umsatzbereich, gewachsen ohne Tests und ohne beschriebene Infrastruktur, mit manuellen Deployments und regelmäßigen Incidents. Die Infrastruktur wurde beschrieben, während das System weiterlief: null Tage Ausfall, danach 90 Prozent weniger Incidents.
Case Study lesenEbenfalls aus echten Projekten
Bevor eine gewachsene Umgebung als Code beschrieben wird, fällt auf, was niemand mehr braucht. In diesem Projekt war genau das ein Teil der Einsparung: Ressourcen ohne Nutzer, Speicher in der falschen Klasse, Aufbewahrung ohne Bedarf.
Case Study lesen
Mit wem Sie es zu tun haben
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, dazu die HashiCorp-Zertifizierung für Terraform. Was ich an Infrastruktur baue, beschreibe ich als Code, weil ich es sonst selbst nicht wiederfinde. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
Häufige Fragen
Für die meisten Umgebungen ist das eine revidierbare Entscheidung, weil die Sprache dieselbe ist – deshalb steht sie nicht am Anfang. Zum Stand: HashiCorp hat die Lizenz im August 2023 von MPL auf BUSL 1.1 umgestellt, daraufhin entstand OpenTofu als Fork der letzten freien Version unter dem Dach der Linux Foundation, und HashiCorp gehört inzwischen IBM. OpenTofu hat seither eigene Fähigkeiten ergänzt, unter anderem State-Verschlüsselung; GitLab hat seine CI/CD-Vorlagen 2025 darauf umgestellt. Wenn Ihre Rechtsabteilung mit BUSL ein Problem hat oder Sie die Verschlüsselung im Werkzeug brauchen, nehmen wir OpenTofu. Sonst Terraform, weil Ökosystem und Dokumentation größer sind.
Manchmal ja, und dann sage ich das. CDK ist stark, wenn Ihr Team ohnehin TypeScript oder Python schreibt und die Infrastruktur nah an der Anwendung entsteht; CloudFormation ist richtig, wenn Sie ausschließlich AWS haben und Service Catalog oder StackSets nutzen. Terraform ist meine Voreinstellung, weil es mehr als AWS beschreibt – Cloudflare, GitHub, Datadog gehören in derselben Sprache dazu – und weil der Plan vor dem Anwenden gut lesbar ist. Wer schon CDK hat, bekommt von mir keine Migration empfohlen, nur weil ich Terraform lieber mag.
Nein, und das ist der Kern des Vorgehens. Der Bestand wird importiert, nicht nachgebaut: Seit Terraform 1.5 gibt es dafür import-Blöcke in der Konfiguration, und ein erster Konfigurationsentwurf lässt sich aus dem Import erzeugen statt tippen. Die Abnahmebedingung je Schritt ist ein leerer Plan – dann ist bewiesen, dass die Beschreibung dem Bestand entspricht, und nichts wurde angefasst.
Abgerechnet wird nach Aufwand, Bestandsaufnahme und erster Import als abgegrenztes Zwei- bis Vier-Wochen-Mandat. Anders als bei den Upgrade-Seiten gibt es hier bewusst kein Festpreispaket: Zwischen „nichts ist beschrieben" und „die Hälfte ist beschrieben, aber der State ist kaputt" liegt zu unterschiedliche Arbeit. Nach der Bestandsaufnahme kann ich den Rest zum Festpreis anbieten, vorher wäre es geraten.
Reparabel, und meistens der erste Handgriff. Der State wandert in einen S3-Bucket mit Versionierung und Verschlüsselung, die Sperre übernimmt seit Terraform 1.11 der Bucket selbst über use_lockfile = true – eine eigene DynamoDB-Tabelle braucht es dafür nicht mehr. Danach ist der Zustand an einer Stelle, gegen gleichzeitige Läufe geschützt und im Zweifel auf eine frühere Version zurückholbar.
Nicht ungefragt. Beim Import wird der Ist-Zustand beschrieben, nicht ein Wunschzustand, deshalb ist der erste Plan leer. Danach ist Drift eine Entscheidung: Was in der Konsole geändert wurde, wird entweder in den Code übernommen oder bewusst zurückgedreht, Position für Position. Was dauerhaft hilft, ist die Regel dahinter – beschriebene Ressourcen werden nur noch über Code geändert – und ein regelmäßiger Lauf, der Abweichungen meldet, bevor sie im Vorfall auffallen.
Nein, und das ist der häufigste Fehler nach dem Import. Ein Modul entsteht aus einer Wiederholung, die man dreimal gesehen hat, nicht aus der Erwartung, dass es einmal drei werden. Zu früh gebaute Module verstecken genau die Details, die man beim Debuggen braucht, und ihre Schnittstellen sind dann falsch. Ich fange flach an und ziehe zusammen, wenn es sich zeigt.
Nein, und das ist eine Festlegung. Ich bringe die Umgebung unter Verwaltung, richte die Pipeline ein und übergebe. Infrastruktur, deren Beschreibung ein Externer pflegt, ist genau dann ein Problem, wenn es schnell gehen muss. Was bleibt, sind Fragen – die beantworte ich gern – und keine Zuständigkeit.
Begriffe, die hier vorkommen
Zum GlossarWeitere Leistungen
Vom eigenen Rechenzentrum oder aus einer anderen Cloud nach AWS, mit Kostenmodell vor dem Umzug und Rollback-Pfad für jeden Schritt.
Mehr erfahrenVon einer Pipeline, die niemand anfassen will, zu Deployments am Dienstagvormittag: ein Artefakt durch alle Stufen, Zugänge ohne Langzeitschlüssel, geprobter Rückweg.
Mehr erfahrenDamit ein einzelner Fehler nicht die ganze Anwendung mitnimmt: Abhängigkeiten und Single Points of Failure gefunden, Wiederanlauf geprobt statt dokumentiert, Änderungen als Terraform.
Mehr erfahren