IaC: Terraform vs. Pulumi vs. AWS CDK

Warum Infrastructure as Code?

Infrastruktur manuell über die Cloud-Konsole zu verwalten funktioniert für ein Projekt. Bei zehn Projekten, drei Umgebungen und einem Team von fünf Ingenieuren wird es zum Chaos: niemand weiß genau, was deployed ist, Änderungen sind nicht nachvollziehbar, und die Staging-Umgebung weicht schleichend von der Produktion ab.

Infrastructure as Code (IaC) löst dieses Problem: Infrastruktur wird in Code definiert, versioniert, reviewed und automatisch deployed — wie Anwendungscode.

Terraform (HashiCorp)

Ansatz

Deklarativ: Sie beschreiben den Zielzustand in HCL (HashiCorp Configuration Language). Terraform berechnet die nötigen Änderungen und führt sie aus.

Stärken

• Multi-Cloud: Ein Tool für AWS, Azure, GCP, Kubernetes und hunderte weitere Provider
• Riesiges Ökosystem: Tausende Module im Terraform Registry
• State Management: Klare Trennung von gewünschtem und aktuellem Zustand
• Reife: Seit 2014 am Markt, bewährt in Unternehmen jeder Größe
• Plan-Funktion: terraform plan zeigt Änderungen vor der Ausführung

Schwächen

• HCL-Lernkurve: Eigene Sprache, die Entwickler erst lernen müssen
• Limitierte Logik: Schleifen und Bedingungen in HCL sind umständlich
• State-Komplexität: State-File muss sicher gespeichert und gelockt werden
• Lizenzänderung: BSL seit 2023 — OpenTofu als Open-Source-Fork

Typisches Team

Platform Engineering, DevOps-Teams mit Multi-Cloud-Anforderungen.

Pulumi

Ansatz

Imperativ mit deklarativem Ergebnis: Sie schreiben Infrastruktur in echten Programmiersprachen (TypeScript, Python, Go, C#). Pulumi berechnet den Diff und führt Änderungen aus.

Stärken

• Echte Programmiersprachen: Keine DSL-Lernkurve, volle IDE-Unterstützung
• Abstraktion: Klassen, Funktionen, Loops — alles, was die Sprache bietet
• Testing: Unit-Tests für Infrastruktur mit Standard-Frameworks (Jest, pytest)
• Multi-Cloud: Unterstützt alle großen Clouds und Kubernetes
• Typensicherheit: TypeScript fängt Fehler vor dem Deployment ab

Schwächen

• Kleineres Ökosystem: Weniger Community-Module als Terraform
• Komplexität: Mehr Freiheit bedeutet mehr Möglichkeiten, es falsch zu machen
• State Service: Pulumi Cloud oder selbst gehostetes Backend nötig
• Debugging: Stack Traces von Infrastrukturfehlern sind schwerer zu lesen

Typisches Team

Entwicklungsteams, die Infrastruktur als Teil des Anwendungscodes verwalten wollen.

AWS CDK

Ansatz

Imperativ, aber AWS-exklusiv: Sie definieren Infrastruktur in TypeScript, Python oder Java. CDK generiert daraus CloudFormation-Templates.

Stärken

• AWS-native: Tiefe Integration mit allen AWS-Services
• Constructs: Hochwertige Abstraktionen (ein L3-Construct kann eine komplette Anwendung abbilden)
• CloudFormation-Basis: Bewährtes Deployment-Backend mit Rollback-Support
• Patterns Library: AWS Solutions Constructs für häufige Architekturen
• Echte Sprachen: TypeScript, Python, Java, C#, Go

Schwächen

• AWS-only: Kein Support für Azure, GCP oder andere Clouds
• CloudFormation-Limits: 500 Ressourcen pro Stack, langsame Deployments bei großen Stacks
• Abstractions leaken: Bei Problemen muss man CloudFormation-Templates debuggen
• CDK-Versionen: Breaking Changes zwischen Major Versions (v1 → v2)

Typisches Team

AWS-only-Shops mit starkem Entwicklerteam.

Entscheidungsmatrix

Die richtige Wahl treffen

Drei Fragen, die die Entscheidung eingrenzen:

1. Nutzen Sie mehr als einen Cloud-Provider? → CDK fällt raus
2. Gibt es ein dediziertes Platform/DevOps-Team? → Terraform ist der sichere Standard
3. Soll das Entwicklungsteam Infrastruktur direkt verwalten? → Pulumi reduziert die Hürde

Fazit

Es gibt kein „bestes” IaC-Tool — nur das passende für Ihr Team, Ihre Cloud-Strategie und Ihre Organisationsstruktur. Wichtiger als die Toolwahl ist der Einstieg: Jede in Code definierte Ressource ist besser als eine manuell erstellte. Starten Sie mit dem Tool, das Ihr Team am schnellsten produktiv macht, und optimieren Sie später.