# Infrastructure as Code > State-Ownership, Modulversionierung und die Übernahme bestehender Ressourcen beherrschen. Track: [Cloud Infrastructure & Platform Engineering](https://physar.tech/learn/cloud-infra) Kanonische Fassung: https://physar.tech/learn/cloud-infra/infrastructure-as-code Stand: 2026-09-13 Interaktiver Teil: 9 Checks (nur im Browser) ## Infrastructure als kontrollierten Zustandsübergang betreiben ### Der Zustand ist das eigentliche Artefakt Ein Provisionierungsskript beschreibt **Schritte**. Deklarative Infrastruktur beschreibt einen **Zielzustand** — und braucht dafür ein Gedächtnis: eine Abbildung zwischen den Objekten in deinem Code und den real existierenden Ressourcen beim Anbieter. Manche Werkzeuge halten diese Abbildung in einer eigenen State-Datei, andere lesen sie bei jedem Lauf aus der Cloud zurück. Die Konsequenzen sind dieselben: Wer diese Abbildung besitzt, besitzt die Ressourcen. Code beschreibt den Zielzustand → Werkzeug liest den bekannten Zustand → Werkzeug liest den realen Zustand beim Anbieter → **Plan = Differenz der drei** → Apply verändert die Realität und schreibt den Zustand fort Daraus folgt die wichtigste Betriebsregel: Der Zustand ist **kritische Infrastruktur**. Er gehört remote, versioniert, verschlüsselt und mit einer Sperre gegen parallele Läufe — nicht auf einen Laptop und nicht ins Git-Repository, weil er Klartext-Attribute enthalten kann. Ein verlorener Zustand bedeutet nicht, dass Ressourcen weg sind; er bedeutet, dass das Werkzeug sie **nicht mehr kennt** und beim nächsten Lauf neu erstellen will. > **Merksatz:** Ein Plan, der viel mehr Änderungen zeigt als du beabsichtigt hast, ist fast nie ein Cloud-Problem. Er ist eine Aussage über den Zustand. ### Schnitt: wie groß darf eine Zustandseinheit sein? Ein einziger, alles umfassender Zustand ist bequem — bis der erste Lauf zwanzig Minuten dauert, jede Änderung die gesamte Produktion in den Plan zieht und zwei Teams sich gegenseitig blockieren. Viele kleine Zustände sind schnell und risikoarm, erzeugen aber Abhängigkeiten zwischen den Einheiten, die jemand explizit verdrahten muss. | | | | --- | --- | | Schnittkriterium | Wechselrate: Langlebiges (Netz, Organisation, Identität) gehört nicht in dieselbe Einheit wie Häufig-Wechselndes. | | Zweites Kriterium | Blast Radius: Was darf ein fehlerhafter Apply höchstens zerstören? | | Drittes Kriterium | Eigentümerschaft: Eine Zustandseinheit sollte genau ein Team haben, das sie freigibt. | | Kein Kriterium | Die Ordnerstruktur im Repository — sie ist Folge des Schnitts, nicht sein Grund. | Zwischen Einheiten fließen Werte. Die haltbare Variante ist, den **erzeugenden** Stack seine Ergebnisse veröffentlichen zu lassen und den konsumierenden sie über eine stabile Abfrage lesen zu lassen. Werte per Hand zu kopieren ist der Anfang von Drift, den niemand als Drift erkennt. ### Module und Versionen Module sind Wiederverwendung — und damit auch geteiltes Risiko. Ein Modul, das per Referenz auf den Hauptzweig eingebunden wird, ändert das Verhalten aller Nutzer in dem Moment, in dem jemand den Zweig anfasst. Der nächste Apply eines fremden Teams zieht die Änderung mit, ohne dass jemand dafür ein Review gemacht hat. - Module **nach Version** referenzieren, damit ein Upgrade eine bewusste, reviewbare Änderung ist. - Provider- und Werkzeugversionen ebenfalls binden — sonst wandert die Infrastruktur, während der Code stillsteht. - Ein Modul ist kein Ort für Umgebungslogik: Wenn es innen `wenn Produktion, dann anders` enthält, sind es zwei Module oder ein Parameter. - Breaking Changes im Modul brauchen denselben Umgang wie in einer Bibliothek: neue Hauptversion, Migrationsnotiz, alte Version bleibt eine Weile nutzbar. > **Antipattern:** Ein „Modul“, das genau einmal benutzt wird und nur Werte durchreicht, erhöht die Kopplung ohne Nutzen. Abstraktion braucht mindestens zwei ernsthafte Nutzer. ### Übernahme bestehender Ressourcen In der Praxis beginnt IaC selten auf der grünen Wiese. Für existierende Ressourcen gibt es genau drei Wege — und die Wahl ist eine Risikoentscheidung, keine Geschmacksfrage. | | | | --- | --- | | Import | Ressource bleibt bestehen, wird nur in den Zustand aufgenommen. Kein Ausfall. Verlangt, dass der Code den Ist-Zustand exakt trifft, sonst zerstört der erste Apply Attribute. | | Neu bauen und umschwenken | Sauberster Code, klar definierter Startpunkt. Verlangt ein Umschaltverfahren und akzeptiert Migrationsrisiko. | | Bewusst außerhalb lassen | Legitim für Ressourcen mit fremder Eigentümerschaft oder kurzer Restlebensdauer — aber **dokumentiert**, sonst ist es Schatten-Infrastruktur. | Der Import hat eine Falle: Er füllt den Zustand, nicht den Code. Erst ein Plan, der **keine** Änderung zeigt, beweist, dass Code und Realität übereinstimmen. Ein Import, nach dem der Plan „ersetzen“ sagt, ist ein scharfgestellter Ausfall. ### Was IaC nicht löst IaC macht Änderungen reviewbar und wiederholbar. Es macht sie nicht **sicher**: Ein grüner Plan sagt nichts über die fachliche Richtigkeit, und `apply` ist ein Vorgang mit Blast Radius wie jeder andere. Die Kontrollen, die tatsächlich schützen, liegen daneben — Plan-Review vor der Freigabe, Policy-Prüfung auf dem Plan, gestaffelte Ausbringung, und ein Zustand, aus dem sich rekonstruieren lässt, wer wann was verändert hat. Ebenso wenig löst IaC die Frage der Datenhaltung: Ein `replace` auf einer Datenbankressource ist im Plan eine Zeile und in der Realität ein Datenverlust. Genau deshalb ist das Lesen des Plans eine Fertigkeit und keine Formalie. > **Gleich im Check:** In den folgenden Entscheidungen geht es um Zustands-Eigentümerschaft, Modulversionierung, die Übernahme bestehender Ressourcen und das Lesen eines Plans, der mehr ankündigt, als jemand gewollt hat. ### Der Betriebsvertrag braucht messbare Invarianten **Betriebsinvariante:** Eine Aussage über eine deklarativ verwaltete Infrastrukturdomäne, die vor und nach einem erlaubten Übergang nachweisbar wahr sein muss. Ein technisches Feature wird erst dann zu einem Betriebsvertrag, wenn Sollzustand, Verantwortlicher, Messpunkt und Reaktion zusammenpassen. Für eine deklarativ verwaltete Infrastrukturdomäne besteht der prüfbare Kern aus **Plan, Konfiguration, Abhängigkeits-Lock und versionierter Zustands-Snapshot**. Der Vertrag nennt außerdem den gültigen Scope und die Bedingungen, unter denen ein Übergang abgebrochen wird. Das verhindert, dass Teams dieselben Wörter verwenden, aber unterschiedliche Garantien erwarten. das Plattformteam als State-Owner gemeinsam mit dem Workload-Team als Ressourcen-Owner bestätigt nicht nur eine Konfiguration, sondern die Fähigkeit, ihre Wirkung zu beobachten und bei Abweichung zu handeln. Invarianten müssen von außen prüfbar sein. Eine Aussage wie **ist sicher** hilft nicht; eine Aussage wie **jede schreibende Operation trägt terraform plan, stammt aus einer freigegebenen Identität und erzeugt innerhalb des Messfensters einen Auditnachweis** kann getestet werden. Neben dem positiven Pfad gehören negative Fälle in die Abnahme: unzulässiger Scope, fehlende Freigabe, veraltetes Artefakt und nicht erreichbare Kontrollabhängigkeit. Erst diese Gegenproben zeigen, ob die Grenze technisch durchgesetzt oder nur dokumentiert ist. **Kurzcheck:** Welche Beschreibung ist für eine deklarativ verwaltete Infrastrukturdomäne als Invariante geeignet? - [x] Jeder erlaubte Übergang ist über terraform plan, Owner, Scope und Ergebnis korrelierbar - [ ] Das Team arbeitet vorsichtig und hält sich normalerweise an die gemeinsame Dokumentation - [ ] Die eingesetzte Cloudfunktion gilt allgemein als zuverlässig > Die Aussage benennt prüfbare Merkmale und lässt sich automatisiert oder im Review widerlegen. ### Grenzen und Eigentum entscheiden über den Blast Radius Die wirksame Grenze liegt bei **Backend, Ausführungsidentität und Zustandsadresse**. Sie bestimmt, welche Ressourcen, Daten und Teams von einer fehlerhaften Entscheidung gemeinsam betroffen sein können. Organigramme und Repository-Grenzen sind dafür nur Hinweise. Maßgeblich ist, wo Identitäten, Zustand, Kapazität oder Kontrollpfade tatsächlich geteilt werden. kleine State-Einheiten begrenzen den Blast Radius, erhöhen aber Abhängigkeiten und Orchestrierungsaufwand Diese Abwägung wird explizit dokumentiert, damit eine spätere Konsolidierung nicht unbemerkt mehrere unabhängige Fehlerbereiche wieder koppelt. Eigentum bedeutet Entscheidungs- und Reaktionspflicht. das Plattformteam als State-Owner gemeinsam mit dem Workload-Team als Ressourcen-Owner legt fest, wer den Sollzustand ändern, wer eine Ausnahme genehmigen und wer im Vorfall handeln darf. Ein RACI ohne technische Rechteprüfung reicht nicht. Regelmäßig wird verglichen, ob Gruppen, Pipeline-Identitäten und Notfallrollen noch zum dokumentierten Modell passen. Gemeinsame Komponenten erhalten einen eigenen Service-Owner, SLO und Eskalationsweg, weil sonst jedes konsumierende Team nur seine lokale Sicht optimiert. > **Grenztest:** Frage für jede gemeinsame Abhängigkeit: Welcher maximale Teil des Dienstes fällt aus, wenn genau diese Abhängigkeit falsche Daten liefert, nicht erreichbar ist oder kompromittiert wird? ### Der Normalablauf wird als kontrollierte Zustandsmaschine beschrieben Änderung referenzieren → Abhängigkeiten auflösen → **Ist-Zustand lesen** → Plan erzeugen → Fachlich prüfen → Exklusiv anwenden und Ergebnis verifizieren Der Ablauf ist eine Zustandsmaschine und keine lose Checkliste. Jeder Schritt besitzt Eingangsdaten, einen ausführenden Prinzipal, ein Ergebnis und eine Abbruchbedingung. Ein nachfolgender Schritt darf nur starten, wenn das vorherige Ergebnis unverändert referenziert wird. Dadurch kann ein Review nicht versehentlich ein anderes Artefakt prüfen als die Automatisierung später verwendet. Wiederholungen müssen entweder idempotent sein oder eine eindeutige Vorgangskennung erkennen, damit ein Timeout nicht zu einer zweiten konkurrierenden Änderung führt. Für Ein Netzwerkmodul soll umbenannt und eine bereits existierende Routingtabelle übernommen werden, ohne sie neu zu erstellen wird der Ablauf zuerst in einem kleinen, repräsentativen Scope ausgeführt. Die Plattform protokolliert Eingaben und Ergebnis, aber keine Secrets oder unnötigen Nutzdaten. Menschliche Freigaben beziehen sich auf Digest, Plan oder Version, nicht auf einen veränderlichen Namen. So bleibt die Kette auch dann prüfbar, wenn zwischen Review und Ausführung Zeit vergeht oder ein anderer Runner übernimmt. ### Vorbedingungen und Gates stoppen unsichere Übergänge Ein Gate ist nur sinnvoll, wenn sein Ergebnis die Ausführung tatsächlich stoppt. Mindestgates prüfen Identität und Scope, Vollständigkeit des Artefakts, bekannte Richtlinien, verfügbare Kapazität sowie einen beobachtbaren Rückweg. Das Gate liefert **bestanden**, **abgelehnt** oder **befristete Ausnahme** mit maschinenlesbarem Grund. Warnungen, die bei jedem Lauf ignoriert werden, sind keine Kontrolle; sie werden entweder in eine harte Bedingung, einen befristeten Behebungsauftrag oder eine bewusst entfernte Regel überführt. Die Vorbedingungen müssen zum Risiko passen. kleine State-Einheiten begrenzen den Blast Radius, erhöhen aber Abhängigkeiten und Orchestrierungsaufwand Deshalb wird nicht jede Änderung durch denselben schweren Prozess geschickt. Kleine, reversible Schritte mit engem Scope können automatisiert freigegeben werden. Irreversible Datenänderungen, neue Vertrauensbeziehungen oder eine Vergrößerung der Fehlerdomäne verlangen zusätzliche Evidenz und unabhängiges Review. Die Risikoklasse stammt aus der beobachtbaren Wirkung, nicht aus der Zahl geänderter Codezeilen. - Ist das Ziel eindeutig und der Scope kleiner als die maximal erlaubte Fehlerdomäne? - Sind Eingaben und Abhängigkeiten unveränderlich referenziert? - Existieren Abbruchsignal und benannter Owner? - Ist der Rückweg technisch möglich und mit aktuellen Daten geprobt? - Wird die Wirkung nach dem Übergang gegen eine Baseline geprüft? ### Fehlerbilder werden vor dem Ernstfall operationalisiert Die wichtigsten Fehlerbilder sind **parallele Schreibläufe, manuelle Drift, falsche Imports und implizite Provider-Upgrades**. Für jedes Bild wird festgehalten, wie es erkannt wird, welche automatischen Schutzmechanismen greifen und welche manuelle Entscheidung übrig bleibt. Ein Runbook, das erst mit der Ursachenanalyse beginnt, kommt zu spät. Zuerst werden Nutzerwirkung und Ausbreitung begrenzt; danach wird die Hypothese mit möglichst kleinen, reversiblen Tests geprüft. Änderungen an mehreren Grenzen gleichzeitig sind zu vermeiden, weil ihr Ergebnis keine Ursache mehr isoliert. Übungen testen nicht nur den glücklichen Failover. Ein sinnvoller Versuch nimmt zusätzlich eine Kontrollabhängigkeit weg, verzögert Telemetrie oder lässt einen Schritt nach erfolgreicher Außenwirkung mit Timeout enden. Das Team muss dann erkennen, ob die Operation wiederholt, fortgesetzt oder gestoppt werden darf. Beobachtet werden sowohl technische Metriken als auch die Qualität der Entscheidung: Zeit bis zur klaren Führung, Anzahl konkurrierender Änderungen und Vollständigkeit der Evidenz. ### Fehlerprobe mit begrenztem Scope Ein Netzwerkmodul soll umbenannt und eine bereits existierende Routingtabelle übernommen werden, ohne sie neu zu erstellen **Anforderungen** - Explizite Hypothese und erwartetes Signal - Begrenzter Zielscope mit Abbruchschwelle - Aktueller Rückweg und erreichbarer Owner - Zeitlich korrelierbare technische und fachliche Messung **Schritte** - Baseline sichern - Eine Fehlerannahme auslösen - Schutzreaktion beobachten - Kontrolliert wiederherstellen - Abweichungen als Arbeit erfassen **Merksatz:** Eine bestandene Übung beweist den geprobten Fall unter den beobachteten Bedingungen, nicht die Abwesenheit aller Risiken. ### Telemetrie verbindet technische Signale mit Nutzerwirkung Für den Betrieb werden **Lock-Wartezeit, Drift-Befunde, Planumfang, fehlgeschlagene Applies und Alter des letzten erfolgreichen Zustands-Backups** gemeinsam betrachtet. Einzelne Messwerte ohne Scope und Zeitbezug sind gefährlich: Ein globaler Durchschnitt kann einen vollständigen Ausfall einer Zone verdecken, eine erfolgreiche API-Antwort kann eine verzögerte Wirkung verschleiern. Jede Metrik nennt Quelle, Dimensionen, erwartete Aktualität und Verhalten bei Messlücken. Fehlende Telemetrie gilt bei kritischen Übergängen als eigener Fehlerzustand und kann die Fortsetzung blockieren. Alarme werden an einer konkreten Handlung ausgerichtet. Ein Alarm nennt betroffenen Scope, beobachtete Invariante, wahrscheinlichen Owner und den ersten sicheren Prüfschritt. Tickets eignen sich für langsamen Kapazitäts- oder Complianceabbau; Paging bleibt akuter Nutzerwirkung oder unmittelbar drohendem Kontrollverlust vorbehalten. Dashboards und Auditabfragen verwenden dieselben IDs wie terraform plan, damit Einsatzleitung, Plattform und Workload-Team nicht drei widersprüchliche Zeitlinien rekonstruieren. > **Messlücke:** Wenn ein Übergang erfolgreich gemeldet wird, seine erwartete Wirkung aber nicht innerhalb des Messfensters beobachtbar ist, bleibt der Zustand unbekannt. Unbekannt ist kein Erfolg. ### Recovery beginnt mit einem sicheren Kontrollpunkt Der Recovery-Vertrag lautet: **Schreiber stoppen, Backend sichern, letzten konsistenten Snapshot bestimmen, reale Ressourcen inventarisieren und Bindungen einzeln reparieren**. Er nennt den letzten sicheren Kontrollpunkt, die Reihenfolge der Schritte und die Daten, die nach einer Umschaltung fachlich geprüft werden müssen. Rollback ist nur dann ein Rückweg, wenn alte Software, Konfiguration und Datenzustand noch kompatibel sind. Andernfalls ist ein kontrollierter Roll-forward oft sicherer. Diese Entscheidung wird vor dem Vorfall für die wichtigsten Änderungsklassen getroffen. Backups und Exportdateien zählen erst nach einem Restore-Test als Recovery-Fähigkeit. Ebenso zählt eine sekundäre Umgebung erst, wenn Identität, Quotas, Netzpfade, Schlüssel und Telemetrie dort unter realistischer Last funktionieren. Die Übung protokolliert erreichten Wiederherstellungspunkt, Dauer, Datenabweichung und manuelle Abhängigkeiten. Ein verfehltes Ziel führt zu einer priorisierten Architektur- oder Prozessänderung; das bloße Herabsetzen des Zielwerts benötigt eine fachliche Risikoentscheidung. Schreibende Änderungen stoppen → **Sicheren Kontrollpunkt bestimmen** → Abhängigkeiten und Zielkapazität prüfen → Kleinste wirksame Recovery-Maßnahme ausführen → Technische und fachliche Konsistenz messen → Schrittweise in den Normalbetrieb zurückkehren Für die technische Abnahme wird eine kleine Nachweismatrix gepflegt. Ihre Zeilen sind Normalbetrieb, Grenzfall, abgelehnter Fall, Kontrollausfall und Recovery; ihre Spalten sind Eingabe, erwarteter Zustand, Messpunkt, Frist und Owner. Dabei werden **Provider- oder Modulupgrade, Import und Refactoring** getrennt betrachtet, weil eine erfolgreiche Probe der einen Klasse keine Aussage über die anderen liefert. Als gemeinsame Referenzen dienen `State-Snapshot, Lock-ID und Plan-Digest`. Die IDs müssen bereits bei der Ausführung entstehen und durch Telemetrie, Ticket und Auditstrom weitergereicht werden. Nachträgliches Zusammenführen anhand ungefähr gleicher Uhrzeiten ist nur eine schwache Ersatzlösung. Die Matrix wird bei einer neuen Abhängigkeit, einem geänderten Scope oder einer geänderten Wiederherstellungsannahme aktualisiert und als Teil des Changes geprüft. Der wichtigste Abnahmesatz lautet, dass **ein Import dieselbe reale Ressource genau einer Zustandsadresse zuordnet**. Um ihn zu widerlegen, braucht der Test mindestens einen erlaubten und einen bewusst unerlaubten Fall. Zusätzlich wird geprüft, was bei einem Timeout nach bereits eingetretener Wirkung geschieht. Die Automatisierung darf einen solchen Schritt nicht blind wiederholen. Sie liest zuerst den beobachtbaren Zustand und entscheidet dann zwischen Fortsetzen, kompensierender Aktion und Eskalation. Für schreibende Übergänge existiert ein Idempotenzschlüssel oder ein fachlich gleichwertiger Schutz. Dadurch wird aus einem Transportfehler kein doppelter Infrastruktur-, Daten- oder Berechtigungseingriff. Die regelmäßige Betriebsprüfung nimmt anschließend reale Veränderungen in den Blick. Sie vergleicht dokumentierte Owner mit aktiven Berechtigungen, erwartete mit beobachteten Abhängigkeiten, vereinbarte mit gemessenen Wiederherstellungszeiten und geplante mit tatsächlich genutzten Ausnahmen. Abweichungen werden nach möglicher Nutzerwirkung und verbleibendem Zeitfenster priorisiert. Ein Befund gilt erst als geschlossen, wenn die technische Ursache behoben, die Kontrolle erneut ausgeführt und die Evidenz am selben Objekt verknüpft wurde. Wiederholte manuelle Eingriffe sind ein Signal für eine fehlende Plattformfähigkeit und werden in einen standardisierten Self-Service-Pfad oder eine bewusst akzeptierte Sonderverantwortung überführt. ## Quellen - Google Cloud: What is Infrastructure as Code — https://cloud.google.com/discover/what-is-infrastructure-as-code - Microsoft Azure Cloud Adoption Framework: Infrastructure as code — https://learn.microsoft.com/azure/cloud-adoption-framework/ready/considerations/infrastructure-as-code - AWS Well-Architected Framework, Operational Excellence Pillar — https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html - HashiCorp Terraform: State — https://developer.hashicorp.com/terraform/language/state - HashiCorp Terraform: Module versions and sources — https://developer.hashicorp.com/terraform/language/modules/sources - HashiCorp Terraform: State and remote state — https://developer.hashicorp.com/terraform/language/state/remote - HashiCorp Terraform: State locking — https://developer.hashicorp.com/terraform/language/state/locking - HashiCorp Terraform: Version constraints — https://developer.hashicorp.com/terraform/language/expressions/version-constraints - HashiCorp Terraform: Backend configuration — https://developer.hashicorp.com/terraform/language/backend - HashiCorp Terraform: Import — https://developer.hashicorp.com/terraform/language/import - HashiCorp Terraform: The lifecycle meta-argument — https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle