8 Min. Lesezeit

AWS CloudFormation und Terraform sind im April 2026 keine Alternative mehr, sondern eine Reihenfolge-Entscheidung. Wer Multi-Cloud ernst meint, fährt Terraform für die Plattform und CloudFormation für die AWS-Tiefen. Wer das umdreht, baut sich genau die Migrations-Schulden ein, die er eigentlich vermeiden wollte.

VerwandtAWS Savings Plans vs. Reserved Instances 2026  /  Cloud Brokerage Services und der FinOps-Report April 2026

Was Terraform und CloudFormation 2026 wirklich unterscheidet

Beide Tools machen das gleiche Versprechen: Infrastruktur als Code, deklarativ, idempotent, versionierbar. Bevor wir vergleichen, kurz die Basis.

Was ist Infrastructure as Code? Ein Modell, in dem Server, Netzwerke, Datenbanken und IAM-Rollen nicht mehr per Klick in einer Web-Konsole entstehen, sondern in Text-Dateien beschrieben werden. Diese Dateien laufen durch denselben Review-Prozess wie Anwendungs-Code, gehen durch CI-Pipelines und produzieren reproduzierbare Umgebungen. Ohne IaC kann niemand sicher sagen, warum eine Staging-Umgebung anders aussieht als Produktion.

Im DACH-Mittelstand höre ich seit zwei Jahren die gleiche Frage: „Welches sollen wir nehmen?“ Die Frage ist falsch gestellt. Die richtige Frage lautet: Welche Cloud-Strategie haben wir tatsächlich? Welches Tool passt auf welche Schicht? Wer das vor der Tool-Wahl klärt, spart sich die Diskussion in den nächsten zwei Jahren.

CloudFormation ist nativer AWS-Bestandteil. Neue AWS-Services tauchen am Tag der Veröffentlichung im CloudFormation-Resource-Katalog auf. Der Terraform-AWS-Provider zieht meist sechs bis zehn Tage später nach, gelegentlich Wochen. Wer Bedrock-Agent-Resources oder die im April 2026 GA-gegangenen EC2-C8in-Instanzen am Launchtag in Code haben muss, hat mit CloudFormation einen messbaren Geschwindigkeitsvorteil. Im Tagesgeschäft eines DAX-Konzerns ist das relevant. Im Mittelstand selten.

Terraform spielt seine Stärke in der Breite aus. Ein Provider-Katalog mit über 4.500 Anbietern deckt nicht nur Azure und GCP ab, sondern auch Cloudflare, Datadog, GitHub, Okta, Snowflake. Wer Identity, Monitoring oder Edge-Konfigurationen mitcoden will, ohne pro Stack eine eigene Sprache zu lernen, hat keine echte Alternative. Die Lizenz-Umstellung auf BSL im August 2023 hat zur OpenTofu-Abspaltung geführt. Beide Forks sind im April 2026 produktionsreif und API-kompatibel. OpenTofu wird von der Linux Foundation gehostet, Terraform bleibt unter dem Dach von HashiCorp und mittlerweile IBM.

Die Tabelle erklärt warum es Lager gibt, aber nicht warum die Diskussion meist schief läuft. Sie verschweigt zwei Punkte, die in Architektur-Reviews entscheidend sind. Wer trägt das State-Management-Risiko? Wer übernimmt das Onboarding neuer Team-Mitglieder? Beides ist bei CloudFormation günstiger, weil es weniger zu wissen gibt. Bei Terraform ist es teurer, weil man mehr falsch machen kann.

Wo CloudFormation gewinnt, wo Terraform sticht

Im Praxischeck mit drei DACH-Cloud-Teams aus dem letzten Quartal sind dieselben Argumente immer wieder aufgetaucht. Sie waren weniger ideologisch als das Internet glauben macht. Ein Maschinenbau-Konzern mit 4.500 Mitarbeitern, ein Versicherer in Süddeutschland und ein SaaS-Anbieter mit 80 Engineers. Drei sehr verschiedene Reife-Stufen, drei sehr ähnliche Schmerzpunkte.

Eine Beobachtung aus den Reviews: CloudFormation-Teams unterschätzen regelmäßig wie schnell ein „vielleicht später Azure“ zur harten Anforderung wird. Sobald Sales eine Multi-Cloud-Klausel in einen Großkunden-Vertrag aufnimmt, ist die IaC-Strategie das letzte Domino, das fällt. Wer dann noch CloudFormation-only ist, schreibt parallele Skripte für Azure ohne saubere Abstraktion. Das ist genau der Mischbetrieb, den niemand will.

Umgekehrt unterschätzen Terraform-Teams die Wartungslast des State-Backends. Ein S3-Bucket mit DynamoDB-Lock-Tabelle, regional repliziert, mit Versionierung und KMS-Verschlüsselung, klingt einfach. Bis ein State-File zwischen zwei parallelen CI-Runs eine Race-Condition produziert und niemand mehr weiß, welcher Plan-Output wirklich angewendet wurde. Das habe ich einmal zu oft als Default gelassen. Heute ist die Empfehlung klar: pro Workspace ein Lock, pro CI-Job ein Workspace, automatischer Snapshot des State-Files vor jedem Apply.

Beim Maschinenbau-Konzern ist genau das passiert. Ein Pipeline-Run mit zwei parallelen Branches, beide auf dieselbe State-Datei. Der zweite Run hat den State des ersten überschrieben, eine RDS-Instanz war anschließend in Terraform unbekannt, in AWS aber existent. Drei Tage Drift-Bereinigung, zwei Tickets, ein peinlicher Status-Report im Steering-Komitee. Hätte der zweite Run einen eigenen Workspace gehabt, wäre es eine zehnminütige Sache gewesen.

Die SaaS-Anbieter aus der Stichprobe haben den umgekehrten Fall erlebt. Sie sind mit CloudFormation gestartet und haben den Stack über drei Jahre hochgezogen. Dann kam die Anforderung, Snowflake-Konten programmatisch zu provisionieren. Ohne Terraform-Provider gab es keine saubere Lösung. Die Brücke war eine Lambda, die Snowflake-API-Calls macht und vom CloudFormation-Stack getriggert wird. Funktioniert, ist aber kein IaC mehr. Es ist Glue-Code mit Stack-Aufkleber. Wer in dieser Lage ist, hat die Tool-Wahl zu spät gemacht.

Multi-Cloud-Realität in der DACH-Praxis

In den drei Praxis-Setups, die ich für diesen Check näher betrachtet habe, ist eine Konstante aufgefallen: Niemand fährt rein eines von beidem. Die produktiv laufenden Multi-Cloud-Architekturen kombinieren Terraform für die Plattform-Schicht und CloudFormation für AWS-spezifische Tiefen. Die Layer-Definition ist der ganze Trick. Wer sie schriftlich hat, schläft besser.

Konkret sieht das so aus: Terraform definiert VPCs, Subnets, IAM-Rollen, Cross-Account-Trust, EKS-Cluster, Cloudflare-DNS, Datadog-Monitor-Konfigurationen. CloudFormation übernimmt was AWS-eigene Service-Macros braucht: Service Catalog Provisioning, AWS Backup Plans mit komplexen Lifecycle-Regeln, AppConfig-Deployment-Strategien. Die Übergabe läuft über Terraform-Outputs, die in einen CloudFormation-Stack als SSM-Parameter gefüttert werden. Das Pattern hat sich 2026 in der Praxis durchgesetzt, weil es beide Welten ohne Reibung verbindet.

Der gemeinsame Nenner: State-Management bleibt pro Schicht klar getrennt. Terraform-State liegt im S3-Bucket pro Account und Region. CloudFormation-Stacks haben ihre eigene Service-side-State-Verwaltung. Beide Welten werden über CI-Pipelines orchestriert, die wissen welche Reihenfolge gilt: erst Plattform, dann Workload, dann Macros. Wer das umdreht, baut Stacks die auf nicht-existente Resourcen verweisen.

Eine zweite Praxis-Lehre: Drift-Management ist die unsichtbare Kostenstelle. CloudFormation-Drift-Detection ist eingebaut und meldet konfigurations-Abweichungen pro Resource. Bei Terraform übernimmt das in den meisten Setups ein wiederkehrender Plan-Job in der CI, der bei Drift Tickets erzeugt. Beide Wege funktionieren. Aber nur einer ist konsequent dokumentiert. Wer einmal eine Console-Änderung gesucht hat, die ein State-File invalidiert, kennt den Wert eines Drift-Reports.

Beim Versicherer aus dem Praxischeck war Drift-Management der Hebel, der die Compliance-Abnahme überhaupt möglich gemacht hat. Der externe Auditor wollte für jede produktive Resource einen verifizierten Stack-Bezug sehen. Mit nativem CloudFormation-Drift-Report war das in zwei Stunden geliefert. Auf der Terraform-Seite hat es eine Woche gedauert, bis driftctl die unmanaged Resources sauber kategorisiert hatte. Beide Welten haben funktioniert, aber der Aufwand war ungleich.

Eine dritte Praxis-Beobachtung betrifft das Thema Modul-Wiederverwendung. Beim Maschinenbau-Konzern haben sieben Geschäftseinheiten parallel an EKS-Clustern gearbeitet. Ohne gemeinsames Terraform-Modul hatte jede Einheit ihren eigenen Cluster-Code mit minimalen Abweichungen. Das Plattform-Team hat ein Monat investiert, ein zentrales EKS-Modul zu bauen, mit klaren Input-Variablen und sinnvollen Defaults. Nach drei Monaten waren alle Einheiten migriert, der Wartungsaufwand ist auf ein Drittel gesunken. Mit CloudFormation hätte das gleiche Pattern funktioniert, aber das Modul-Ökosystem ist enger und der gemeinsame Pool an wiederverwendbaren Bausteinen kleiner.

„AWS CloudFormation und Terraform sind im April 2026 keine Alternative mehr, sondern eine Reihenfolge-Entscheidung.“

Was Architekten bis Q3 2026 entscheiden müssen

Drei Markt-Bewegungen machen die Layer-Frage 2026 dringender, nicht weniger. HashiCorp wurde im Februar 2024 von IBM übernommen. Der Übergang läuft bis 2027 und betrifft die HCP-Pricing-Roadmap. OpenTofu hat sich als Linux-Foundation-Projekt etabliert und gilt 2026 als drop-in-Ersatz mit eigenem Modul-Registry. AWS hat im April 2026 die CloudFormation Hooks GA-released, die Drift- und Compliance-Checks in jeden Stack-Lebenszyklus einhängen. Drei Bewegungen, die in jedem Architektur-Review der nächsten zwei Quartale auftauchen werden.

Wer 2026 noch keine schriftliche Layer-Definition hat, sollte sie jetzt schreiben. Nicht als Architektur-Verordnung, sondern als Entscheidungs-Hilfe für jedes neue Modul: Welche Schicht, welches Tool, welche State-Verwaltung. Das spart die wiederkehrende Diskussion ob ein neuer Service in CloudFormation oder Terraform landet. Es macht Onboarding neuer Plattform-Engineers in Tagen statt Wochen möglich.

Drei konkrete Schritte, die sich aus den Praxis-Setups als Reihenfolge bewährt haben. Erstens: ein einseitiges Layer-Mapping schreiben, das pro Resource-Typ klärt welches Tool zuständig ist. Zweitens: das State-Backend pro Konto und Region vereinheitlichen, mit klarer Workspace-Konvention. Drittens: einen Drift-Report-Job in die CI hängen, der bei Abweichungen automatisch Tickets erzeugt. Diese drei Schritte sind in zwei Wochen umsetzbar und sparen das nächste Architektur-Review-Meeting komplett.

Was nicht in diese Reihenfolge gehört: eine Tool-Migration ohne Trigger. Wer aus reiner Code-Hygiene von CloudFormation auf Terraform wechseln will, ohne Multi-Cloud-Anforderung im Hintergrund, verbrennt drei Quartale Engineering-Zeit für ein Refactoring das niemand misst. Die ehrlichste Diskussion in jedem Architektur-Review der nächsten zwei Quartale ist daher die Frage nach dem konkreten Anlass, nicht die Frage nach dem konkreten Tool.

Häufige Fragen

Lohnt 2026 noch ein Wechsel von CloudFormation auf Terraform?

Nur mit klarem Multi-Cloud- oder Plattform-Engineering-Trigger. Reine AWS-Stacks ohne SaaS-Anbindung profitieren wenig vom Wechsel und tragen die Lernkurve und State-Management-Last neu ein. Wer einen Multi-Cloud-Vertrag mit Großkunden im Pipeline hat, sollte parallel anfangen.

OpenTofu oder Terraform mit BSL-Lizenz?

OpenTofu ist 2026 produktionsreif, API-kompatibel und unter Linux Foundation gehostet. Wer Lizenz-Klarheit für Compliance braucht oder Module ohne Vendor-Risiko teilen will, ist mit OpenTofu sauberer aufgestellt. Die HashiCorp BSL-Lizenz ist für interne Nutzung weiterhin unkritisch.

Wie löst man die State-Race-Condition zwischen parallelen CI-Runs?

Terraform State Locking via DynamoDB ist der Standard, OpenTofu nutzt das gleiche Backend-Schema. Pro Workspace ein Lock, pro CI-Job ein Workspace. Wer Pipeline-Parallelität ohne Locking-Strategie fährt, baut sich State-Korruption ein.

Reicht der CloudFormation-Drift-Report oder braucht man driftctl?

Für reine CloudFormation-Stacks reicht der native Report. Sobald Terraform und CloudFormation parallel laufen, lohnt driftctl als zweite Sicht: er sieht auch unmanaged Resources die kein Stack kennt. Beide ergänzen sich, ersetzen sich nicht.

Was bedeutet die IBM-Übernahme von HashiCorp für die Tool-Wahl?

Bis 2027 läuft der Integrations-Plan, danach werden Pricing- und Support-Modelle voraussichtlich neu sortiert. Open-Source-Terraform und HCP bleiben bis dahin verfügbar. Wer reine Vendor-Unabhängigkeit als Architektur-Prinzip führt, sollte OpenTofu evaluieren.

Quelle Titelbild: Pexels / Kampus Production (px:8353774)