Terraform vs Pulumi: Lesbarkeit, Tests und Eignung fürs Team

Was die Leute wirklich mit „Terraform vs Pulumi“ meinen

Wenn Leute Terraform vs Pulumi sagen, geht es meist nicht darum, wer mehr Provider oder coolere Features hat. Es geht um eine praktische Frage: Was ist auf Dauer leichter zu handhaben, wenn wir Infrastruktur erstellen, ändern und Fehler beheben?

Im Alltag bedeutet Infrastructure as Code, dass deine Cloud‑Konfiguration in wiederholbarer Form festgehalten ist. Eine Änderung ist eine Code‑Änderung. Es gibt eine Review, bevor etwas ausgeführt wird. Dann zeigt ein Tool einen Plan dessen, was sich ändern wird, und du setzt die Änderung mit klarer Historie darüber um, wer was und warum gemacht hat.

Deshalb sind Lesbarkeit und Vorhersagbarkeit wichtiger als eine lange Feature‑Liste. Die meisten Teams scheitern nicht, weil ein Tool eine Ressource nicht erstellen kann. Sie scheitern, weil Menschen nicht schnell verstehen, was eine Änderung tut, oder dem Output nicht genug vertrauen, um schnell zu handeln.

Der Schmerz zeigt sich oft in langsamen, stressigen Reviews, ungleichmäßiger Einarbeitung, auseinanderlaufenden Umgebungen und der ständigen Angst, dass die nächste Änderung Produktion kaputtmacht.

Dieser Vergleich konzentriert sich darauf, wie sich jedes Tool in echten Reviews liest, wie Teams es übernehmen, wie Tests in der Praxis funktionieren und wie man Umgebungen verwaltet, ohne langsam Konfigurationsdrift zu erzeugen.

Lesbarkeit und Code‑Review‑Erlebnis

Die meisten Diskussionen über Terraform vs Pulumi beginnen mit einer einfachen Frage: Kann dein Team die Änderung lesen und vorhersagen, was sie tut?

Terraform verwendet HCL, das für Infrastruktur gedacht ist. Für übliche Arbeiten wie eine VPC, IAM‑Rollen oder einen App‑Service lesen sich die Dateien oft wie ein deklaratives Formular: Ressourcentyp, Name und zentrale Einstellungen. Reviews fühlen sich oft über Projekte hinweg konsistent an, selbst wenn verschiedene Personen den Code geschrieben haben.

Pulumi liest sich wie normaler Anwendungscode, weil es normaler Anwendungscode ist. Du erstellst Ressourcen mit Funktionen und Objekten und kannst Schleifen, Bedingungen und Hilfsfunktionen frei nutzen. Das kann für Entwickler sehr lesbar sein, besonders bei komplexer Infrastrukturlogik. Gleichzeitig kann es aber verbergen, was passiert, wenn Werte dynamisch erzeugt werden.

Variablen und Wiederverwendung fühlen sich anders an. Terraform drängt zu Inputs, Locals und Modulen, sodass Reviewer oft darauf achten, welche Inputs oder Modulversionen sich ändern. Pulumi fördert Wiederverwendung über Sprachmittel: Funktionen, Klassen, Pakete und gemeinsame Bibliotheken. Das reduziert Duplikation, bedeutet aber oft mehr Code‑Lesen während Reviews.

Für Nicht‑Expert*innen laufen Reviews besser, wenn das Team ein paar Gewohnheiten teilt: Namen und Tags vorhersagbar halten, einfache Ausdrücke statt cleverer Schleifen bevorzugen, das „Warum“ als kurzen Kommentar neben riskanten Einstellungen (IAM, Networking, Delete‑Protection) notieren, Diffs klein halten und Plan/Preview‑Output immer zusammen mit dem Code lesen.

Wenn eure Reviewer hauptsächlich Ops‑ und Platform‑Leute sind, hilft Terrforms einheitliche Form. Wenn eure Reviewer hauptsächlich Software‑Ingenieur*innen sind, fühlt sich Pulumi natürlicher an, solange der Code einfach bleibt.

Team‑Adoption und Lernkurve

Der eigentliche Unterschied bei der Einführung von Terraform vs Pulumi ist nicht nur die Syntax. Es geht darum, wer Vertrauen darin bekommen muss, Änderungen zu reviewen, zu genehmigen und zu unterstützen, wenn etwas schiefgeht.

Terraform verlangt von den meisten, eine zweckbezogene Sprache (HCL) und eine kleine Menge IaC‑Konzepte zu lernen. Das ist oft einfacher für Ops, Security und Platform‑Teams, weil der Code wie Konfiguration wirkt und über Projekte hinweg ähnlich aussieht.

Pulumi verlangt neben IaC‑Konzepten zusätzlich eine allgemeine Programmiersprache (häufig TypeScript oder Python). Wenn dein Team bereits in dieser Sprache entwickelt, kann die Einarbeitung schneller sein, weil Schleifen, Funktionen und Pakete vertraut sind. Ist das nicht der Fall, ist die Lernkurve spürbar — besonders für Kolleg*innen, die nur gelegentlich Reviews machen müssen.

Einarbeitung wird leichter, wenn Verantwortlichkeiten klar sind. In der Praxis teilen Teams Aufgaben oft in Rollen: Autoren (ändern täglich), Reviewer (prüfen Absicht und Risiko), Genehmiger (Security, Kosten) und On‑Call (Debugging und State‑Basics). Nicht alle brauchen dasselbe Tiefenwissen, aber alle brauchen ein gemeinsames mental Modell, wie Änderungen vorgeschlagen, previewed und angewendet werden.

Konsistenz verhindert, dass Adoption über Repos hinweg auseinanderfällt. Wählt ein kleines Set an Konventionen und setzt sie früh durch: Ordnerstruktur, Namensgebung, Tagging, wie Inputs übergeben werden, wie Umgebungen getrennt werden und was „done“ bedeutet (Formatierung, Linting und ein Plan‑Check bei jeder Änderung).

Bei Teams mit unterschiedlicher Erfahrung ist die sicherste Wahl meistens die, die maximalen Review‑Komfort bietet. Wenn die Hälfte des Teams stark in TypeScript ist, kann Pulumi gut funktionieren — aber nur, wenn Muster standardisiert werden und „cleverer“ Code vermieden wird. Wenn Reviewer überwiegend Nicht‑Entwickler sind, gewinnt oft Terrforms einfachere Form.

Wenn Entwickler Pulumi für wiederverwendbare Komponenten wollen, aber Security‑Reviewer Probleme beim Lesen haben, startet mit einem gemeinsamen Template‑Repo und strikten Review‑Regeln. Das reduziert Überraschungen, während das Team Vertrauen aufbaut.

State, Secrets und Änderungsvertrauen

Die meisten Argumente über Terraform vs Pulumi laufen auf eine Angst hinaus: „Wird diese Änderung tun, was ich denke, ohne Produktion zu zerstören?“ State, Secrets und Previews sind die Bereiche, in denen dieses Vertrauen gewonnen oder verloren wird.

Terraform verfolgt die Realität über eine State‑Datei. Sie kann lokal sein, aber Teams verschieben sie meist in ein Remote‑Backend mit Locking. Fehlt der State, ist er veraltet oder wenden zwei Personen ohne Lock gleichzeitig an, kann Terraform versuchen, Ressourcen neu zu erstellen oder zu löschen, die bereits existieren. Pulumi nutzt ebenfalls State, speichert ihn aber pro Stack. Viele Teams mögen, wie „stack = environment“ explizit ist und wie Konfig und State zusammenbleiben.

Secrets sind die nächste scharfe Kante. Bei Terraform hilft das Markieren von Outputs als sensibel, aber Secrets können trotzdem über Variablen, Logs oder State durchsickern, wenn man nicht vorsichtig ist. Pulumi behandelt Secrets als erstklassige Werte und verschlüsselt sie im Stack‑State, was versehentliche Exposition reduziert. In beiden Tools ist die sicherste Einstellung: State ist kein Secret‑Store; nutze möglichst den Secret‑Manager deiner Cloud.

Änderungsvertrauen kommt vom Diff. Terrforms Plan ist weit verbreitet und leicht in Reviews zu standardisieren. Pulumi's Preview ist ähnlich, aber die Lesbarkeit hängt davon ab, wie viel Logik du in den Code packst. Je mehr echtes Programmieren du hinzufügst, desto mehr benötigst du Konventionen.

Für Governance konvergieren Teams meist zu denselben Kernanforderungen: remote State mit Locking und Least‑Privilege‑Zugriff, ein Review‑Schritt mit Plan/Preview‑Output, manuelle Genehmigungen für Produktion und separate Umgebungen mit getrennten Zugangsdaten.

Wiederverwendungsmuster: Module vs Komponenten

Bei Terraform vs Pulumi bedeutet „Wiederverwendung“ meist eins: Kannst du denselben Stack‑Typ (VPC, Datenbank, Kubernetes, IAM) für viele Teams bauen, ohne Ordner zu kopieren und hoffen, dass niemand sie unterschiedlich ändert?

Terrforms zentrales Baustein ist das Modul: ein Ordner von Ressourcen mit Inputs und Outputs. Teams veröffentlichen oft „goldene“ Module (Netzwerk, Logging, Datenbank) und pinnen Versionen, sodass Upgrades eine bewusste Entscheidung sind, kein Überraschungspaket. Diese Versionierung ist simpel und effektiv. Du kannst eine neue Modulversion Team für Team ausrollen.

Pulumi baut mit Komponenten (oft als Bibliothek verpackt). Das ist Code, der mehrere Ressourcen als eine höhere Einheit erstellt. Wiederverwendung fühlt sich natürlicher an, weil du normale Sprachfeatures nutzt: Funktionen, Klassen und typisierte Inputs. Komponenten lassen sich als interne Pakete teilen, sodass Teams dieselben Defaults und Guardrails erhalten.

Eine praktische Herangehensweise für mehrere Teams ist, klar zwischen „Platform“ und „App“ zu trennen. Halte eine kleine Menge geteilter Bausteine in der Verantwortung einer Platform‑Gruppe (Netzwerk, Security, Basis‑Cluster). Packe meinungsstarke Defaults in den Baustein und erlaube nur die wenigen Optionen, die Teams wirklich brauchen. Füge Validierung an der Grenze hinzu (Namensregeln, Pflicht‑Tags, erlaubte Regionen). Versioniere alles und schreibe in einfacher Sprache, was sich geändert hat. Gib ein oder zwei Beispiele, die reale Anwendungsfälle abbilden.

Um Copy‑Paste zu vermeiden, behandle jedes wiederkehrende Muster als Kandidaten für ein Modul oder eine Komponente. Wenn zwei Teams „eine Postgres‑Datenbank mit Backups und Alarmen“ brauchen, sollte das eine wiederverwendbare Einheit mit wenigen Inputs (Größe, Aufbewahrung, Owner) sein — nicht zwei fast identische Verzeichnisse.

Umgebungen verwalten ohne Konfigurationsdrift

Konfigurationsdrift beginnt meist mit guter Absicht. Jemand „ändert schnell“ eine Security‑Group in der Cloud‑Konsole oder behebt eine Einstellung in Produktion. Ein Monat später sagt dein Code etwas anderes als die Realität.

Terraform und Pulumi unterstützen die Idee eines Code‑Basissystems mit mehreren Umgebungen, modellieren es aber unterschiedlich. Terraform nutzt oft Workspaces (oder separate State‑Backends) für dev, staging und prod. Pulumi nutzt Stacks, wobei jeder Stack eigene Config und State hat. In der Praxis sind die Ergebnisse sauberer, wenn der State jeder Umgebung klar getrennt ist und du vermeidest, einen State über Umgebungen zu teilen.

Ressourcennamen sind wichtiger, als viele erwarten. Wenn Namen kollidieren, bekommst du verwirrende Updates oder fehlgeschlagene Deploys. Backe die Umgebung in Namen und Tags ein, sodass ersichtlich wird, was wohin gehört. Zum Beispiel api-dev, api-staging, api-prod plus konsistente Labels wie env=prod.

Um Accounts oder Subscriptions zu trennen und trotzdem Code zu teilen, halte die Infrastruktur‑Logik an einem Ort und wechsle nur das Zielkonto und die Config pro Umgebung. Das kann ein Konto pro Umgebung sein plus ein CI‑Job, der vor dem Anwenden die richtige Rolle/Identität annimmt.

Per‑Environment Overrides sollten klein und bewusst sein. Ziel ist eine gemeinsame Basis mit einer kurzen Liste von Unterschieden: benutze überall dieselben Module/Komponenten, überschreibe nur Größen und Counts (Instance‑Type, Replikazahl), halte Config in einer Datei pro Umgebung/Stack und vermeide verstreute if env == prod‑Logik. Beschränke Console‑Änderungen und behandle Notfälle als anschließende Code‑Änderung.

Schritt‑für‑Schritt: ein sicherer Workflow für Änderungen

Ein sicherer Workflow sieht bei Terraform und Pulumi fast gleich aus. Das Ziel ist einfach: Jede Änderung wird immer auf dieselbe Weise previewed, reviewed und angewendet, mit wenig Raum für „funktioniert nur auf meinem Laptop“‑Überraschungen.

Ein Ablauf, der für die meisten Teams funktioniert, sieht so aus:

• Code aktualisieren und Formatierung sowie Basis‑Checks ausführen.
• Einen Plan/Preview erzeugen (Terraform: plan, Pulumi: preview) und die Ausgabe speichern.
• Den Diff in einem Pull Request reviewen, mit Fokus auf Deletes, Replacements und breit wirkende Änderungen.
• Vom kontrollierten Ort anwenden (oft CI) anhand des reviewed Commits.
• Mit einem kurzen Smoke‑Check verifizieren und dokumentieren, was sich geändert hat.

Wo du es ausführst, ist wichtig. Lokale Runs sind gut für schnelles Feedback, aber der finale Apply sollte konsistent sein. Viele Teams erlauben lokale Preview/Plan, verlangen Apply/Up jedoch nur aus CI mit denselben Umgebungsvariablen, derselben Credential‑Quelle und pinned Tool‑Versionen.

Version‑Pinning ist ein stiller Lebensretter. Pinnen die Terraform‑Version und Provider‑Versionen oder pinne Pulumi‑CLI und Sprachabhängigkeiten. Lock‑Files und Abhängigkeitsgrenzen reduzieren überraschende Diffs.

Um neuen Kolleg*innen das Folgen zu erleichtern, behalte eine Seite „Wie wir Änderungen hier machen“: die Happy‑Path‑Befehle, wer applyen darf und von wo, wie mit Secrets umgegangen wird (niemals im Klartext), wie man eine schlechte Änderung stoppt und was zu tun ist, wenn das Preview unerwartete Drift zeigt.

Testansätze, die Teams tatsächlich nutzen

Die meisten Teams unittesten Infrastruktur nicht auf dieselbe Weise wie App‑Code. Für IaC ist eine realistische Aufteilung: schnelle Checks, die offensichtliche Fehler früh abfangen, plus eine kleine Menge Live‑Tests, die beweisen, dass eine Änderung in einem echten Cloud‑Konto funktioniert.

Statische Checks (schnell)

Für Terraform sind die Basics Formatierung und Validierung, gefolgt von Security‑ und Policy‑Checks, die den Build fehlschlagen lassen, wenn etwas riskant ist. So fängst du offene Security‑Groups, fehlende Tags oder unverschlüsselte S3‑Buckets ab.

Für Pulumi machst du Linting und Typ‑Checks, kannst aber auch kleine assertions‑artige Tests gegen die Programmausgabe schreiben (z. B. „jede Datenbank muss Backups aktiviert haben"). Pulumi unterstützt Preview‑basierte Tests und Mocks, mit denen Tests laufen, ohne echte Ressourcen zu erstellen.

Was viele Teams in jedem Pull Request laufen lassen, ist unabhängig vom Tool ähnlich: Formatierung und Basis‑Validierung, statische Security‑Regeln, Policy‑Checks gegen die geplante Änderung, ein Dry‑Run Preview/Plan mit menschenlesbarer Zusammenfassung und ein kurzer Genehmigungsschritt bei Überschreiten einer Risikoschwelle.

Preview‑ und Live‑Tests (langsamer)

Integrationstests bedeuten meist, eine temporäre Umgebung zu erstellen, die Änderung anzuwenden und einige Schlüsselfakten zu prüfen (Dienst erreichbar, Datenbank existiert, Alarme vorhanden). Halte es klein. Zum Beispiel: Nach einer Änderung an einem Load‑Balancer‑Modul einen Test‑Stack starten, Health‑Checks prüfen und dann zerstören. Das schafft Vertrauen, ohne IaC‑Testing in einen Vollzeitjob zu verwandeln.

Konfigurationsdrift: Erkennung, Triage und Prävention

Konfigurationsdrift beginnt oft mit einem „Quick Fix“ in der Cloud‑Konsole: Jemand öffnet eine Security‑Group, ändert eine IAM‑Policy, tweakt Autoscaling oder passt eine Datenbank‑Einstellung an, um einen Alert zu stoppen. System ist wieder stabil, aber dein IaC stimmt nicht mehr mit der Realität überein.

Drift‑Erkennung funktioniert am besten als Gewohnheit, nicht als Rettungsmission. Die meisten Teams führen planmäßige read‑only Plan/Preview‑Runs und nach großen Vorfällen durch. Ob du Terraform oder Pulumi verwendest, ist weniger wichtig als die Tatsache, dass jemand tatsächlich die Ausgabe anschaut.

Wenn Drift auftaucht, triagiere, bevor du es behebst. Manche Drift ist harmloser Lärm (provider‑verwaltete Felder). Manche Drift ist echtes Risiko (temporär geöffneten öffentlichen Zugriff). Einfache Fragen helfen bei der Triage: War die Änderung beabsichtigt und genehmigt, beeinflusst sie Sicherheit/Kosten/Verfügbarkeit, lässt sie sich sauber im IaC darstellen, ist sie dringend und würde das Beheben Downtime verursachen?

Drift zu ignorieren ist nur akzeptabel, wenn sie bekannt, niedrigrisikant und dokumentiert ist. Alles andere sollte entweder in der Cloud zurückgesetzt werden, damit es zum IaC passt, oder im IaC kodifiziert werden, sodass der nächste Apply die wichtige Änderung nicht wieder entfernt.

Um Lärm niedrig zu halten, filtere wiederkehrende Diffs (z. B. berechnete Zeitstempel) und alarmiere nur bei bedeutsamen Ressourcen. Tags und Labels helfen bei der Ownership. Eine kleine Konvention hilft sehr: owner, service, env, cost_center und intent (warum das existiert).

Häufige Fehler und Fallen

Die größte Falle bei Terraform vs Pulumi ist nicht die Sprache. Es ist der Workflow. Teams stolpern über Abkürzungen, die heute schneller wirken und später Tage kosten.

Den Plan als optional zu behandeln ist ein klassischer Fehler. Wenn Leute Previews überspringen und vom Laptop aus anwenden, verlierst du eine gemeinsame Quelle der Wahrheit und eine saubere Audit‑Spur. Außerdem machen Tool‑Version‑Mismatch und Credential‑Unterschiede echte Produktionsrisiken.

Ein weiteres leises Problem sind One‑Off Overrides, die Umgebungen auseinanderlaufen lassen. Ein schneller Tweak in Staging, ein manueller Hotfix in Prod, eine andere Variablen‑Datei „nur dieses eine Mal“ — bald kannst du nicht mehr erklären, warum Prod sich anders verhält. Die nächste Änderung wird beängstigend, weil du dem Ergebnis nicht vertraust.

Zu viel dynamischer Code ist eine Pulumi‑geprägte Falle, aber Terraform kann mit heavy Templating ebenfalls hineingeraten. Wenn alles zur Laufzeit berechnet wird, werden Reviews zu Ratespielen. Wenn ein Teammitglied den Diff nicht vorhersagen kann, indem es die Änderung liest, ist das System zu clever.

Module‑ oder Komponentenversionierung wird auch leicht vernachlässigt. Ein in‑place‑Ändern eines geteilten Moduls kann Konsumenten in anderen Repos oder Umgebungen still brechen.

Die meisten Teams vermeiden diese Probleme mit wenigen Guardrails: Preview/Plan in CI für jede Änderung laufen lassen und Apply nur aus CI, Umgebungsunterschiede explizit halten (separate Stacks/Workspaces plus klare Inputs), langweiligen lesbaren Code statt cleverer Abstraktionen bevorzugen, shared Module/Komponenten versionieren und gezielt upgraden sowie manuelle Console‑Änderungen durch die Regel „Emergency, then codify“ einschränken.

Schnell‑Checkliste bevor du auswählst oder migrierst

Die Wahl zwischen Terraform vs Pulumi ist weniger eine Geschmackssache und mehr die Frage, ob dein Team sichere Änderungen Woche für Woche ohne Überraschungen durchführen kann. Bevor du dich festlegst (oder migrierst), beantworte diese Fragen schriftlich und vergewissere dich, dass die Antworten zu eurer tatsächlichen Arbeitsweise passen.

Die „Können wir Änderungen vertrauen?“‑Checkliste

• Können wir eine klare Vorschau der Änderungen sehen, bevor etwas angewendet wird, und verstehen Reviewer die Ausgabe gut genug, um riskante Änderungen zu erkennen?
• Ist der State geschützt (Zugriffssteuerung, Verschlüsselung wo nötig), gesichert und von Maintainer*innen bewohnt, die das Team entblocken können?
• Wo liegen Secrets im Alltag, und können wir sie rotieren, ohne Deploys zu brechen?
• Sind Umgebungen per Design getrennt, mit klaren Namen und Grenzen (z. B. dürfen dev und staging nicht versehentlich Prod‑Ressourcen berühren)?
• Führen wir Drift‑Checks nach Zeitplan aus, und gibt es eine benannte Person, die entscheidet, ob Drift behoben, akzeptiert oder eskaliert wird?

Wenn ein Punkt mit „wir klären das später“ beantwortet wird, ist das ein Signal zum Pausieren. Die meisten IaC‑Probleme kommen von schwacher Änderungssteuerung: unklare Previews, geteilte Umgebungen und niemand verantwortlich für Drift.

Ein praktischer Weg, deine Wahl zu prüfen, ist, einen echten Workflow durchzuspielen: „Erstelle eine neue Queue, verbinde sie mit einem Service und rolle sie zu staging und dann production aus.“ Wenn du das mit sicheren Reviews und einer sauberen Rollback‑Geschichte schaffst, bist du auf gutem Weg.

Beispielszenario und praktische nächste Schritte

Ein kleines Team (1–2 Ingenieur*innen plus ein Product Owner) betreibt ein Kundenportal mit drei Umgebungen: dev für tägliche Arbeit, staging für Release‑Checks und prod für echte Nutzer. Sie brauchen eine Datenbank, ein paar Services, Queues, Storage und Monitoring. Die typischen Schmerzpunkte sind vorhersehbar: Reviews sind langsam, Secrets‑Handhabung ist heikel und „in staging hat es funktioniert“ passiert ständig.

Mit Terraform enden solche Teams oft mit klarer Ordnerstruktur, einigen Modulen und Workspaces oder separaten State‑Dateien pro Umgebung. Der Vorteil ist ein großes Ökosystem und viele etablierte Muster. Der Nachteil ist, dass die Lesbarkeit leidet, sobald Logik wächst, und Tests oft bei „Plan‑Output‑Checks plus ein paar Smoke‑Tests“ bleiben, sofern das Team nicht mehr investiert.

Mit Pulumi wird dieselbe Einrichtung zu echtem Code: Schleifen, Funktionen und gemeinsame Bibliotheken. Reviews können einfacher werden, wenn Änderungen komplex sind, und Tests fühlen sich natürlicher an. Der Kompromiss ist die Team‑Bequemlichkeit: Du verwaltest Infrastruktur mit einer Programmiersprache und brauchst Disziplin, sie einfach zu halten.

Eine einfache Entscheidungsregel:

• Wähle Terraform, wenn dein Team ein Standard‑Tool, minimales Coden und viele etablierte Muster will.
• Wähle Pulumi, wenn dein Team täglich in einer Programmiersprache arbeitet und stärkere Wiederverwendung und Testing möchte.
• Wenn die Risikotoleranz gering ist, favorisiere die Option, die deine Reviewer sicher lesen können.

Praktische nächste Schritte, die in echten Teams funktionieren: pilotiere einen dünnen Ausschnitt (ein Service plus seine Datenbank) über dev/staging/prod, schreibe kurze Standards (Namensgebung, Umgebungs‑Trennung, Secrets‑Regeln und Review‑Pflichten), füge ein Sicherheitsgate hinzu (Plan/Preview in CI plus ein einfacher Smoke‑Test nach dem Apply) und erweitere erst, wenn der erste Ausschnitt langweilig und wiederholbar ist.

Wenn du auch interne Tools um diese Workflows herum baust, kann AppMaster (appmaster.io) dir helfen, die Anwendungsschicht (Backend, Web, Mobile) schneller zu erstellen, während du dein IaC auf die Infrastruktur fokussierst, die du wirklich verwalten musst.