Pulumi vs. Terraform: Welches IaC-Tool passt wirklich zu deinem Team-Profil?

Infrastructure as Code (IaC) ist längst kein rein technisches Thema mehr. Es ist eine Frage von Zusammenarbeit, Verantwortlichkeiten und Teamkultur.

Lange Zeit wurde vor allem darüber gestritten, welches Tool „besser” ist. In der Praxis zeigt sich jedoch: Die wichtigere Frage lautet, welches Tool besser zu eurem Team, euren Rollen und euren Arbeitsweisen passt.

Pulumi und Terraform sind heute die beiden prägendsten IaC-Ansätze, und sie stehen sinnbildlich für zwei unterschiedliche Denkweisen:

• Terraform: eine eigene deklarative Sprache (HCL), standardisiert, stark operativ geprägt.
• Pulumi: allgemeine Programmiersprachen, flexibel und näher an klassischer Softwareentwicklung. Im Ergebnis ebenfalls deklarativ (Desired State), aber der Weg dorthin wird imperativ beschrieben.

Ich habe in den letzten Jahren mit beiden Tools produktiv gearbeitet: Terraform in größeren, stärker regulierten Umgebungen, Pulumi in kleineren, entwicklergetriebenen Teams. Was ich dabei gelernt habe: Beide Tools funktionieren. Aber sie scheitern auf völlig unterschiedliche Weise. Und genau das sollte die Entscheidung treiben.

Kurzer Überblick: Terraform & Pulumi in der DevOps-Praxis

Terraform – Der stabile, konsistente Klassiker

Terraform von HashiCorp ist das am weitesten verbreitete IaC-Tool in der Cloud-Welt. Es nutzt HashiCorp Configuration Language (HCL), eine deklarative Sprache, speziell für Infrastruktur. HCL ist bewusst eingeschränkt: Man kann keine beliebigen Funktionen schreiben, keine Vererbungshierarchien bauen und keine externen Libraries importieren. Das ist kein Versehen, sondern eine Designentscheidung. Die Sprache sagt dir: Beschreibe den Zustand, den du haben willst. Den Weg dahin übernehme ich.

In der Praxis sieht das so aus:

resource "aws_subnet" "app" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index)
  availability_zone = var.availability_zones[count.index]
} 

Ein Subnet pro Availability Zone, dynamisch erzeugt. Jeder im Team, der HCL lesen kann, versteht sofort, was hier passiert und was sich bei einem terraform plan ändern würde. In vielen Organisationen ist Terraform genau deshalb das „sichere Fundament”: vorhersehbar, gut dokumentiert und für Teams mit heterogenen Skillsets leicht zugänglich. Dazu kommt ein praktischer Vorteil, der oft unterschätzt wird: Terraform unterstützt nativ tausende Provider. Wer Infrastruktur für weniger verbreitete Zielumgebungen verwaltet, findet bei Terraform mit deutlich höherer Wahrscheinlichkeit einen fertigen Provider. 

Pulumi – Infrastruktur als echte Software

Pulumi verfolgt einen anderen Ansatz: Statt einer eigenen DSL nutzt es allgemeine Programmiersprachen wie TypeScript, Python, Go oder C#/.NET. Das bedeutet, Infrastruktur wird mit denselben Mitteln geschrieben wie Anwendungscode: Funktionen, Schleifen, Klassen, Libraries und Tests. Unter der Haube arbeitet Pulumi trotzdem deklarativ über eine Desired State Declaration. Man beschreibt den Zielzustand in einer imperativen Sprache, das Tool gleicht dann ab.

Ein Punkt, den man früh kennen sollte: Pulumi bringt nativ nur Hunderte Provider mit. Deutlich weniger als Terraform. Zwar lassen sich Terraform-Provider über eine Bridge einbinden, in der Praxis ist das aber fehleranfällig und funktioniert nicht für jeden Provider zuverlässig. Wer exotischere Zielumgebungen bedienen muss, sollte das vor der Tool-Entscheidung prüfen.

In meiner Erfahrung fühlt sich Pulumi oft an wie „Terraform, aber in echter Software“. Das macht es sehr flexibel, aber auch anspruchsvoller in der Governance.

Das gleiche Szenario in Pulumi (TypeScript):

const subnets = availabilityZones.map((az, i) => {
  return new aws.ec2.Subnet(`app-${az}`, {
    vpcId: vpc.id,
    cidrBlock: `10.0.${i}.0/24`,
    availabilityZone: az,
  });
}); 

Skills- und Rollen-Fokus: Wer fühlt sich mit welchem Ansatz wohler?

Hier zeigen sich die größten Unterschiede in der Realität.

Wer profitiert eher von Terraform?

Terraform passt besonders gut zu klassischen Ops-Teams, Plattform-Teams, Cloud Engineers und Organisationen, die starke Standards brauchen. Ein oft unterschätzter Vorteil: Gerade weil HCL auf Konstrukte wie Methoden, Imports oder komplexe Kontrollstrukturen verzichtet, kommen auch Einsteiger:innen schneller zu einem funktionierenden Ergebnis. Die Sprache begrenzt kreative „Ausreißer” und Wildwuchs, Reviews bleiben gut lesbar und vergleichbar. Wenn ein Platform-Team Terraform-Module für andere bereitstellt, will man nicht, dass Konsument:innen beliebige Logik einbauen. Die Einschränkung ist die Governance.

Terraform fördert eine strukturierte, konsistente Arbeitsweise und eine klare Trennung zwischen Entwicklung und Infrastruktur. Das passt oft besonders gut für größere Organisationen.

Wer profitiert eher von Pulumi?

Pulumi glänzt in Teams mit vielen Softwareentwickler:innen, DevOps- oder SRE-orientierter Kultur und hohem Automatisierungsgrad. Wenn eure Entwickler ohnehin in TypeScript, Python oder Go arbeiten, fühlt sich Pulumi natürlicher an. Statt eine neue Sprache zu lernen, können sie ihre bestehenden Skills nutzen. Kein Kontextwechsel zwischen Anwendungscode und Infrastrukturcode. Keine zweite Sprache. Gemeinsame Testinfrastruktur. Entwickler:innen können Infrastruktur wie jeden anderen Code reviewen, weil es das auch ist.

Pulumi unterstützt damit stärker einen „Developers-own-infrastructure”-Ansatz.

Workflows & Zusammenarbeit: Wo die Unterschiede im Alltag spürbar werden

Terraform-Workflow: klar, konsistent, manchmal starr

Der typische Terraform-Flow ist bewusst linear: Code schreiben, terraform plan, Review, terraform apply. Die Trennung zwischen „Was will ich?” und „Was passiert?” ist explizit und eingebaut. Das macht Reviews verständlich, auch für Leute, die nicht täglich in der Codebasis arbeiten.

Aber sobald die Anforderungen die Ausdruckskraft von HCL übersteigen, wird es schwierig. Manche Dinge werden umständlich, andere lassen sich schlicht nicht umsetzen. In einem Projekt musste ich kürzlich eine Umgebung bauen, in der Ressourcen je nach Konfiguration entweder in einer oder drei Regionen deployt werden, mit unterschiedlichen Netzwerk-Topologien je nach Region. In HCL wurde das schnell unübersichtlich: verschachtelte for_each-Ausdrücke über Maps of Maps, try()-Aufrufe für optionale Werte, locals-Blöcke, die länger waren als die eigentlichen Ressourcen.

Der Code funktionierte. Aber im Review sagte ein Kollege den Satz, den man in Terraform-Projekten irgendwann immer hört: „Ich verstehe, was es tut, aber ich würde mich nicht trauen, daran etwas zu ändern.”

Terraform fördert tendenziell einen Platform-first-Ansatz. Das ist eine Stärke, solange die Anforderungen in den Rahmen passen.

Pulumi-Workflow: mehr Freiheit, mehr Verantwortung

Pulumi fühlt sich näher an klassischer Softwareentwicklung an: gängige Testframeworks, Wiederverwendung über Funktionen, Klassen und Libraries, Integration in CI/CD wie jeder andere Anwendungscode. Die gleiche Multi-Region-Logik, die in Terraform zum Problem wurde? In Pulumi eine Funktion mit Parametern:

function deployRegion(config: RegionConfig): RegionResources {
  const vpc = new aws.ec2.Vpc(`vpc-${config.region}`, {
    cidrBlock: config.cidr,
  }, { provider: config.provider });
  const subnets = config.azs.map((az, i) =>
    new aws.ec2.Subnet(`subnet-${config.region}-${az}`, {
      vpcId: vpc.id,
      cidrBlock: `${config.cidrPrefix}.${i}.0/24`,
      availabilityZone: az,
    }, { provider: config.provider })
  );
  return { vpc, subnets };
}
const regions = regionConfigs.map(deployRegion);  

Typsicher. Testbar. Ein Code Review wie bei jeder anderen TypeScript-Komponente. Das liest sich gut. Das Problem liegt woanders.

In einem Team, in dem ich Pulumi eingesetzt habe, hat ein Entwickler angefangen, die Infrastruktur-Definitionen in ein eigenes internes Framework zu abstrahieren. Factory-Pattern für Ressourcen. Generics. Vererbung. Nach sechs Wochen war die Infrastruktur technisch sauber aufgebaut. Aber nur noch zwei Leute im Team konnten Änderungen vornehmen, ohne das Framework im Detail zu verstehen.

Das ist der Pulumi-typische Failure Mode: Nicht schlechte Infrastruktur, sondern zu clevere Infrastruktur. Die gleiche Ausdruckskraft, die komplexe Anforderungen elegant lösbar macht, verführt dazu, Abstraktionen zu bauen, die das Team nicht trägt.

Pulumi fördert einen entwicklerzentrierten Ansatz. Aber mit großer Flexibilität kommt die Verantwortung, diesen nicht zu missbrauchen.

Richtlinien & State-Handling im Teamkontext

Terraform State

Terraform speichert den Zustand deiner Infrastruktur in einer .tfstate-Datei (JSON-Format) und nutzt dafür konfigurierbare Backends, typischerweise S3, Azure Blob Storage, GCS oder ein HTTP-Backend. Das Setup ist explizit: Man konfiguriert das Backend, richtet Locking ein und definiert, wer Zugriff hat. Das bedeutet mehr initiale Arbeit, gibt aber volle Kontrolle. Teamfähigkeit entsteht über zentralen Remote State mit State Locking.

Daneben gibt es auch die Terraform Cloud (heute unter dem Dach von HCP Terraform), die den State zentral verwaltet und ähnlich wie Pulumi Cloud den operativen Aufwand reduziert. Sie ist allerdings nicht der Default.

Die Risiken sind bekannt: Gleichzeitige Zugriffe ohne sauberes Locking können zu korruptem State führen, manuelle Eingriffe durch terraform state-Kommandos bergen Fehlerrisiken, und insgesamt erfordert es ein durchdachtes State-Management mit klaren Prozessen. In etablierten Teams funktioniert das zuverlässig, bei Neueinsteigenden ist es eine häufige Fehlerquelle.

Pulumi State

Auch Pulumi speichert den State als JSON. Standardmäßig liegt er in der Pulumi Cloud, es werden aber auch self-managed Backends unterstützt (S3, Azure Blob, GCS oder lokal). Im Unterschied zu Terraform bietet Pulumi kein HTTP-Backend an. Die Pulumi Cloud reduziert den operativen Aufwand und bringt Features wie verschlüsselte Secrets und Audit-Logs mit, setzt aber Vertrauen in einen externen Dienst voraus.

In regulierten Umgebungen habe ich öfter gesehen, dass Teams auf selbstgehostete Backends wechseln. Technisch möglich, aber ein Aspekt, den man früh klären sollte. Wichtig: Pulumi zwingt niemanden zur externen Speicherung.

Fazit: Entscheidungsmatrix für dein Team

• Wähle Terraform, wenn dein Team stark operativ geprägt ist, ihr klare Standards und Governance wollt, viele unterschiedliche Rollen damit arbeiten sollen und Stabilität wichtiger ist als maximale Flexibilität.
• Wähle Pulumi, wenn Entwickler:innen eng in Infrastruktur eingebunden sind, ihr viel Automatisierung und Wiederverwendung wollt, ihr ohnehin in TypeScript, Python oder Go arbeitet und ihr Infrastruktur wie Software behandeln wollt. 

Eine persönliche Schlussbemerkung

Terraform schützt vor Chaos. Die eingeschränkte Sprache begrenzt, was Teams anrichten können. Das ist in vielen Kontexten genau richtig.

Pulumi schützt vor Stagnation. Die volle Ausdruckskraft einer Programmiersprache beseitigt Workarounds und ermöglicht Muster, die in HCL nicht abbildbar sind. Das ist in vielen Kontexten genau richtig.

Am Ende ist die wichtige Frage nicht „Terraform oder Pulumi?”, sondern: „Wie wollen wir als Team arbeiten, und welche Fehler wollen wir vermeiden?”

Entdecken Sie unser Seminarangebot