Bild: KI-generiert mit Google Gemini / stk
Eine an der Konsole zusammengeklickte Cloud-Umgebung lässt sich kaum überprüfen, schlecht nachbauen und nur mit Mühe umziehen. Infrastructure as Code verlegt ihre maßgebliche Beschreibung ins Repository und schafft damit die Grundlage für einen reproduzierbaren Wiederaufbau. Zusätzliche Portabilität entsteht jedoch erst mit passenden Abstraktionen, getesteten Migrationspfaden und Werkzeugen, deren Lizenz, Trägerschaft und Reife zum eigenen Exit-Plan passen.
Die peinliche Stille im Kundenaudit dauert drei Sekunden zu lang. Der Prüfer fragt, wie schnell die Produktionsumgebung bei einem anderen Anbieter wieder läuft, doch der IT-Leiter des Zulieferers mit 600 Beschäftigten hat keine Zahl parat.
Denn in diesem Szenario ist die Umgebung – wie so oft – an der Konsole gewachsen. Eine Firewall-Regel hier, ein Datenbankparameter dort, dazwischen ein Storage-Bucket, den jemand schnell selbst anlegte. Jeder Eingriff war für sich nachvollziehbar. Nach drei Jahren beschreibt die Dokumentation dennoch eine Infrastruktur, die es nicht mehr gibt.
Hier setzt Infrastructure as Code (IaC) an. Was gilt, sagt nicht die Weboberfläche, sondern das Repository. Server, Netze und Datenbanken stehen als Zielbeschreibung darin, versioniert und von Kollegen freigegeben.
Konfigurationsdrift: Handarbeit zerstört den dokumentierten Stand
Für den Abstand zwischen Papier und Produktion hat die Branche ein Wort: Drift. Er wächst mit jedem Konsolenzugriff, den niemand protokolliert hat. Im Tagesbetrieb bleibt das oft unbemerkt, die Rechnung kommt dann im Audit oder im Notfall, wenn niemand mehr weiß, welcher Stand gilt.
Terraform und OpenTofu speichern Ressourcenzuordnungen und den bekannten Stand im State. Ein Plan-Lauf vergleicht Konfiguration, State und den tatsächlichen Infrastrukturzustand, doch erst das Apply setzt die geplanten Änderungen um. Crossplane gleicht Ressourcen fortlaufend ab und korrigiert Abweichungen nach Möglichkeit selbst. Pulumi erkennt Drift über eigene Läufe, in Pulumi Deployments auch zeitgesteuert.
Mehr als das Werkzeug zählt im Betrieb die Disziplin. Keine Änderung ohne Pull Request und Pipeline, die Konsole im Regelbetrieb nur mit Leserechten, Schreibrechte nur für wenige Konten. Wer im Notfall doch direkt eingreift, trägt die Änderung danach im Code nach. Deklarativ, versioniert und unveränderlich gespeichert, automatisch abgerufen und fortlaufend abgeglichen: So fassen es die OpenGitOps-Prinzipien zusammen.
Portabilitätsebenen: Fünf Schichten bestimmen die Wechselbarkeit
IaC macht eine Umgebung aber noch nicht cloudunabhängig. Portabilität entsteht auf fünf Ebenen: Sprache, Werkzeug, Ressourcenmodell, Anwendung sowie Daten und Identitäten. Die ersten beiden sind schnell erledigt – HCL, Python und TypeScript binden an keine Cloud, und dasselbe Werkzeug bedient auch den nächsten Anbieter.
Beim Ressourcenmodell endet die Neutralität allerdings. Jeder Provider spricht die Sprache seiner Zielcloud: Hochverfügbarkeit, Back-up-Fenster und Firewall-Regeln tragen andere Namen, Einheiten und Wertebereiche. Für jeden Anbieter liegt deshalb eine eigene Ressourcenbeschreibung im Repository – gepflegt, getestet, nachjustiert.
Richtig teuer wird es auf den letzten beiden Ebenen. Beim Zulieferer gehen 800 Gigabyte über die Leitung, die Rollen aus dem alten IAM finden im neuen kein Gegenstück, während manche Schlüssel ihren Key-Management-Dienst gar nicht verlassen. Bleibt noch die Anwendung selbst – ob sie in der neuen Umgebung unverändert funktioniert, verrät kein Plan-Lauf.
Werkzeugvergleich: Jeder Ansatz setzt eigene Grenzen
Kein Werkzeug deckt alle fünf Portabilitätsebenen ab. IaC-Tools unterscheiden sich nicht nur im Funktionsumfang, sondern auch in der Kontrolle, die sie dem Team lassen. Das zeigt sich vor allem beim State, dem Zuschnitt der eigenen Abstraktion und an den Lizenzbedingungen.
| Ansatz | Stärke | Wo die Portabilität endet | Lizenz, Eigentümer |
|---|---|---|---|
| Terraform | Reifes Provider-Modell, Lock File fixiert Provider | Ressourcen bleiben cloudspezifisch, Remote-Module ungesperrt | BSL 1.1 ab 1.6, IBM seit 2/2025 |
| OpenTofu | Vertraute Bedienung, State und Plan verschlüsselt | Kompatibilitätsgrenzen zu Terraform | MPL 2.0, CNCF-Sandbox seit 4/2025 |
| Pulumi | Echte Programmiersprachen, Infrastruktur testbar | Sprachpakete verlängern die Lieferkette | Apache 2.0, Anbieter venture-finanziert |
| Crossplane | Fortlaufender Abgleich, eigene Plattform-APIs | Braucht Kubernetes, Provider binden an die Cloud | Apache 2.0, CNCF Graduated |
| TOSCA 2.0 | Beschreibt ganze Anwendungslandschaften | Steht und fällt mit Profil und Orchestrator | OASIS-Standard seit 7/2025 |
Hier fehlen noch drei weitere Kandidaten. Beim Cloud Development Kit for Terraform hat der Hersteller (HashiCorp) im Dezember 2025 den Support und die Wartung eingestellt. Bicep und CloudFormation enden hingegen dort, wo auch Azure und AWS enden. Beide bilden somit keine Ausgangsbasis für einen Umzug.
Abstraktionsebene: Plattform-APIs verlagern die Kontrolle
Am Zuschnitt der Plattform-API entscheidet sich, wie weit die Portabilität reicht. Wer nur aufnimmt, was jeder Anbieter beherrscht, hält den Wechsel offen. Wer allerdings die Spezialfunktionen der Zielcloud durchreicht, verlagert die Bindung nur eine Schicht nach oben, aber dort sucht sie später niemand.
Pulumi unterstützt TypeScript, Python, Go, Java, .NET-Sprachen und YAML. Das Werkzeug wertet den entsprechenden Code aus und leitet daraus ab, was anzulegen oder zu ändern ist. Wer eine der unterstützten Programmiersprachen ohnehin nutzt, kommt ohne zusätzliche DSL aus und kann auf vorhandene Tests, Bibliotheken und Paketmanager zurückgreifen.
Crossplane läuft als Kubernetes-Operator im Cluster. Provider und Controller verwalten die Ressourcen, darüber liegt eine Plattform-API. Aus mehreren Ressourcen entsteht über Compositions ein Baustein namens „Datenbank“ – dahinter kann je nach Umgebung ein Managed Service oder ein eigener Cluster stehen.
Terraform-Lizenz: Der Konzern bestimmt die Bedingungen
Den Bruch brachte Version 1.6, denn seitdem steht Terraform unter der Business Source License 1.1, bei der es sich gemessen an den Open-Source-Kriterien um keine Open-Source-Lizenz handelt. Im eigenen Betrieb bleibt der Einsatz erlaubt.
Eng wird es beim Hosten und beim Einbau in ein konkurrierendes kostenpflichtiges Angebot. Spätestens vier Jahre nach ihrer Veröffentlichung wechselt die jeweilige Version zur MPL 2.0. Anwenderunternehmen trifft das kaum, Softwarehäuser mit einem eigenen Plattformprodukt unter Umständen aber sehr wohl.
Neben der Lizenz zählt auch der Eigentümer: IBM kündigte die Übernahme von HashiCorp im April 2024 für 6,4 Milliarden US-Dollar an und schloss sie im Februar 2025 ab. Über Lizenz, Roadmap, Preisliste und Registry bestimmt seither IBM. Zum Konzern gehört auch Vault, die Software für Zugangsdaten und Schlüssel. Wer beides einsetzt, bezieht damit zwei zentrale Teile seiner Werkzeugkette vom gleichen Hersteller.
Ein eigener Artefaktspeicher nimmt zumindest der Registry ihre Macht: Provider und Module liegen versioniert und per Prüfsumme gesichert im Haus. Ist der Spiegel vollständig, hält ein Ausfall keinen Build mehr auf.
Vom Hersteller löst das noch nicht. Dafür braucht es den Terraform-Fork OpenTofu, der bestehende HCL-Dateien und States oft unverändert übernimmt. State und Plan verschlüsselt das Sandbox-Projekt der CNCF sogar nativ. Deckungsgleich sind die beiden Projekte seit der Abspaltung 2023 allerdings nicht mehr, was vor allem die Kompatibilität neuerer Terraform-Funktionen betrifft.
Exit-Vorbereitung: Ein Notfallkoffer verkürzt den Anbieterwechsel
Wer die Umgebung woanders neu aufbaut, braucht mehr als den Code: Historie und fixierte Versionen, einen eigenen Paketspiegel, den verschlüsselten State samt Images und Schlüsseln. Dazu Regelwerke in maschinenlesbarer Form und Datenexporte, deren Rückimport schon einmal geklappt hat.
Bei den Abhängigkeiten hakt es in der Praxis dann meist zuerst. So hält das Lock File zwar Provider mit Version und Prüfsumme fest, doch bei Modulen aus fremden Repositories greift diese Sperre nicht. Beim nächsten Initialisierungslauf zieht sich das Projekt dort im Zweifel anderen Code. Abhilfe schaffen ein fester Commit-Hash oder ein Spiegel im eigenen Artefaktspeicher.
Heikel wird es auch beim State selbst. Als sensibel markierte Werte tauchen in der CLI-Ausgabe nicht auf, in der lokalen State-Datei stehen sie aber weiterhin im Klartext. Unverschlüsselt hat diese Datei im Repository nichts zu suchen.
Als ähnlich heikel gilt das State Locking. Ob die Sperre greift, hängt am Backend. Ohne sie arbeiten zwei parallele Läufe am selben State, wodurch im schlimmsten Fall Ressourcenzuordnungen verloren gehen.
Reifegradmodell: Vier Stufen messen die Wechselfähigkeit
Stufe 1 – dokumentiert
Konfigurationsdateien beschreiben die Umgebung. Einzelne Änderungen gehen aber weiter über die Konsole in die Produktion.
Stufe 2 – kontrolliert
Jede Änderung nimmt den Weg über die Pipeline. Ein automatischer Lauf meldet Abweichungen, der State ist verschlüsselt. Während ein Lauf arbeitet, verhindert das Locking parallele Änderungen am State.
Stufe 3 – abstrahiert
Für die kritischen Dienste gibt es eine interne Plattform-API. Mindestens einer dieser Dienste davon läuft nachweislich auch bei einem zweiten Anbieter.
Stufe 4 – bewiesen
Das Team hat eine getrennte Zielumgebung aufgebaut. Wiederanlaufzeit und Handgriffe stehen im Protokoll.
Data Act: Fristen erzwingen die technische Vorarbeit
Rückenwind kommt vom Data Act der EU, der seit 2025 gilt. Er begrenzt die Ankündigungsfrist eines Wechsels auf zwei Monate und den regulären Übergang auf 30 Kalendertage. Wechselentgelte darf der alte Anbieter nur noch bis zum 12. Januar 2027 und auch nur in Höhe seiner unmittelbaren Kosten erheben.
Auf der Infrastrukturebene, grob gesagt bei IaaS, muss er außerdem beim Umzug helfen: Der Kunde soll beim neuen Anbieter zumindest ein Mindestmaß der bisherigen Funktionen wiederfinden. Bei anderen Cloud-Diensten setzt die Verordnung auf offene Schnittstellen und Interoperabilität. Fehlen dafür Standards, gibt der Anbieter die exportierbaren Daten strukturiert, gängig und maschinenlesbar heraus.
Benutzerverwaltung, Warteschlangen und Datenbankerweiterungen, die es beim nächsten Anbieter nicht gibt, entstehen dadurch allerdings nicht. Der Kunde muss sie ersetzen oder selbst nachbauen. Wer vorbaut, beschränkt die Plattform-API deshalb auf Datenbank, Objektspeicher, Queue und Cluster – sofern alle vorgesehenen Zielanbieter sie unterstützen. Für jeden Anbieter gibt es darunter einen eigenen Adapter. Spezialfunktionen bleiben in solchen Adaptern oder wandern sichtbar in die Anwendung.
Ohne einen Aufbau in einer getrennten Zielumgebung bleibt das alles aber nur Theorie. Erst dann steht im Protokoll, wie lange der Wiederanlauf gedauert hat und wie viel davon jemand von Hand erledigen musste. Was dabei an Daten und Funktionen fehlt und was die Migration gekostet hat, wiegt in der nächsten Vertragsverhandlung schwerer als jede Zusage des Anbieters.
Fazit: Der Zweitaufbau belegt die Souveränität
Infrastructure as Code liefert das Fundament, aber nicht mehr. Wechselbar wird eine Umgebung erst mit entworfenen Abstraktionen und einem Migrationspfad, den jemand ausprobiert hat. Hinzu kommt die Frage nach dem Werkzeug: Wem gehört es, wer betreibt die Registry, wer verwahrt die Schlüssel?
Den größten Aufwand verursachen Datenmigration, Identitätsverwaltung und proprietäre Plattformdienste. Die Konfigurationsarbeit, über die alle reden, fällt daneben oft kaum ins Gewicht.
Der Zulieferer kann dem Auditor inzwischen antworten. Nur dem Vorstand gefällt die Antwort nicht: Der Aufbau bei einem anderen Anbieter dauert Wochen, nicht Tage.
Autor: Stefan Kuhn