AWS CDK vs. Terraform - Vergleich aus der Praxis

Wer sich für Infrastructure as Code auf AWS entscheidet, landet früher oder später bei dieser Frage: AWS CDK oder Terraform? In Foren, auf Konferenzen, in jedem zweiten Architektur-Review - die Diskussion ist ein Dauerbrenner. Und die Antworten klingen meistens gleich: "Kommt drauf an."

Das stimmt natürlich. Aber es hilft nicht weiter, wenn man gerade eine Entscheidung treffen muss.

Wir haben beides im Einsatz gehabt. Angefangen mit dem Serverless Framework, dann Terraform evaluiert und eingeführt, und am Ende bei AWS CDK gelandet. Terraform ist ein großartiges Tool - wir haben gerne damit gearbeitet und es hat seinen Job gut gemacht. Aber CDK hat für das, was wir bauen, am Ende besser funktioniert. Dieser Artikel ist kein neutraler Feature-Vergleich, sondern eine ehrliche Einordnung aus der Praxis - mit klarer Perspektive und Respekt für die Stärken beider Tools.

Zwei verschiedene Denkweisen

Der Unterschied zwischen CDK und Terraform ist nicht "Feature A vs. Feature B". Es sind zwei grundlegend verschiedene Ansätze, Infrastructure as Code zu denken.

Terraform ist deklarativ. Du beschreibst in HCL - HashiCorps eigener Konfigurationssprache - den Zustand, den deine Infrastruktur haben soll. Terraform vergleicht diesen Soll-Zustand mit dem Ist-Zustand und leitet daraus ab, was es tun muss. Dabei ruft Terraform die AWS-APIs direkt auf - kein CloudFormation, kein Zwischenschritt. Das funktioniert cloud-übergreifend: AWS, Azure, GCP, sogar GitHub oder Datadog lassen sich über Provider einbinden.

CDK ist etwas anderes: Infrastructure as real Code. Kein YAML, kein JSON, kein HCL - sondern TypeScript, Python, Java oder Go. Eine echte Programmiersprache mit Variablen, Funktionen, Klassen, Typen und einem ganzen Ökosystem an Tooling. Daraus generiert CDK CloudFormation-Templates und deployt sie über den CloudFormation-Service von AWS.

Bei Terraform ist dein Infrastruktur-Code Konfiguration. Bei CDK ist er Software. Was das konkret bedeutet, haben wir in Infrastructure as Code mit AWS CDK im Detail beleuchtet.

Code und Abstraktion

Schauen wir uns dasselbe Serverless-Setup in beiden Tools an: eine Lambda-Funktion, die auf Events aus einer SQS-Queue reagiert und Ergebnisse in DynamoDB schreibt - einmal in Terraform, einmal in CDK:

Terraform (HCL)

# SQS Queue
resource "aws_sqs_queue" "event_queue" {
  name = "EventQueue"
}

# DynamoDB Table
resource "aws_dynamodb_table" "results" {
  name         = "Results"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"
  attribute { name = "id"; type = "S" }
}

# IAM Role fuer Lambda
resource "aws_iam_role" "lambda_role" {
  name = "processor-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

# CloudWatch Logs
resource "aws_iam_role_policy_attachment" "logs" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

# SQS-Rechte
resource "aws_iam_role_policy" "sqs_policy" {
  role   = aws_iam_role.lambda_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:ChangeMessageVisibility",
        "sqs:GetQueueAttributes"
      ]
      Resource = aws_sqs_queue.event_queue.arn
    }]
  })
}

# DynamoDB-Rechte
resource "aws_iam_role_policy" "dynamodb_policy" {
  role   = aws_iam_role.lambda_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = [
        "dynamodb:PutItem",
        "dynamodb:UpdateItem"
      ]
      Resource = aws_dynamodb_table.results.arn
    }]
  })
}

# Lambda Funktion
resource "aws_lambda_function" "processor" {
  function_name = "Processor"
  runtime       = "nodejs20.x"
  handler       = "index.handler"
  filename      = "lambda.zip"
  role          = aws_iam_role.lambda_role.arn
}

# SQS -> Lambda Trigger
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn        = aws_sqs_queue.event_queue.arn
  function_name           = aws_lambda_function.processor.arn
  function_response_types = ["ReportBatchItemFailures"]
}

AWS CDK (TypeScript)

// SQS Queue
const queue = new sqs.Queue(this, "EventQueue");

// DynamoDB Table
const table = new dynamodb.Table(this, "Results", {
  partitionKey: { name: "id", type: dynamodb.AttributeType.STRING },
});

// Lambda Funktion
const fn = new lambda.Function(this, "Processor", {
  runtime: lambda.Runtime.NODEJS_20_X,
  handler: "index.handler",
  code: lambda.Code.fromAsset("lambda"),
});

// SQS -> Lambda Trigger + IAM + DynamoDB-Rechte
fn.addEventSource(
  new SqsEventSource(queue, {
    reportBatchItemFailures: true,
  }),
);
table.grantWriteData(fn);

# SQS Queue
resource "aws_sqs_queue" "event_queue" {
  name = "EventQueue"
}

# DynamoDB Table
resource "aws_dynamodb_table" "results" {
  name         = "Results"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"
  attribute { name = "id"; type = "S" }
}

# IAM Role fuer Lambda
resource "aws_iam_role" "lambda_role" {
  name = "processor-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

# CloudWatch Logs
resource "aws_iam_role_policy_attachment" "logs" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

# SQS-Rechte
resource "aws_iam_role_policy" "sqs_policy" {
  role   = aws_iam_role.lambda_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:ChangeMessageVisibility",
        "sqs:GetQueueAttributes"
      ]
      Resource = aws_sqs_queue.event_queue.arn
    }]
  })
}

# DynamoDB-Rechte
resource "aws_iam_role_policy" "dynamodb_policy" {
  role   = aws_iam_role.lambda_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = [
        "dynamodb:PutItem",
        "dynamodb:UpdateItem"
      ]
      Resource = aws_dynamodb_table.results.arn
    }]
  })
}

# Lambda Funktion
resource "aws_lambda_function" "processor" {
  function_name = "Processor"
  runtime       = "nodejs20.x"
  handler       = "index.handler"
  filename      = "lambda.zip"
  role          = aws_iam_role.lambda_role.arn
}

# SQS -> Lambda Trigger
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn        = aws_sqs_queue.event_queue.arn
  function_name           = aws_lambda_function.processor.arn
  function_response_types = ["ReportBatchItemFailures"]
}

Was spricht dich mehr an? In Terraform deklarierst du jede Ressource, jede Berechtigung und jede Verknüpfung einzeln - du musst wissen, welche IAM-Actions ein SQS-Event-Source-Mapping braucht und wie die Policy dafür aussieht. In CDK sagt addEventSource() dem Framework, was du willst, und CDK erledigt den Rest: Rolle, Policies, Trigger, alles mit den richtigen Berechtigungen.

Und CDK geht noch weiter: mit NodejsFunction kannst du den Build-Schritt direkt in deine Infrastruktur-Definition einbauen. TypeScript kompilieren, Dependencies bundlen, Artefakt erstellen - alles passiert automatisch beim cdk deploy. Kein separater Build-Schritt, kein manuell gepflegtes ZIP. Das vereinfacht den Einstieg und summiert sich, sobald die Infrastruktur wächst.

Aber der eigentliche Unterschied liegt tiefer. CDK nutzt eine echte Programmiersprache - und damit bekommst du alles, was Software-Projekte ausmacht: Abstraktion über Klassen und Funktionen. Gemeinsame Patterns in eigene Constructs auslagern. Bibliotheken bauen, die dein Team wiederverwendet. Unit Tests schreiben, die prüfen, ob deine Infrastruktur korrekt ist - bevor du deployst. Und über Custom Resources lassen sich auch Dinge einbinden, die CloudFormation nicht nativ abdeckt - einzelne externe Ressourcen oder Sonderfälle ja, aber als Brücke zu einem kompletten Nicht-AWS-Stack eignet es sich nicht.

Die Kehrseite: unter der Haube erzeugt CDK CloudFormation-Templates - du arbeitest also immer mit zwei Schichten. Das hat Konsequenzen bei Deployment-Geschwindigkeit, State Management und Refactoring, auf die wir gleich eingehen.

Deployment und Fehlerhandling

Terraform deployt schneller. Es ruft die AWS-APIs direkt auf - kein Zwischenschritt über CloudFormation. CloudFormation ist langsamer, auch wenn es unabhängige Ressourcen parallel erstellt. Dafür bekommst du automatische Rollbacks: geht ein Deployment schief, wird auf den letzten stabilen Zustand zurückgesetzt. Der Rollback ist im Grunde ein nachgelagertes Deployment - wenn etwas schiefgeht, kostet das also doppelt Zeit. Und in seltenen Fällen bleibt CloudFormation im gefürchteten UPDATE_ROLLBACK_FAILED-Zustand stecken, aus dem man teils nur schwer wieder herauskommt.

Terraform hat kein automatisches Rollback. Wenn ein Apply mittendrin abbricht - etwa weil der CI/CD-Runner stirbt - hast du halb erstellte Infrastruktur. Der State spiegelt nicht unbedingt die Realität wider, und du musst selbst aufräumen.

Zwei verschiedene Risikoprofile: CloudFormation kümmert sich automatisch, kann aber langsam werden oder steckenbleiben. Terraform gibt dir die Kontrolle, aber ohne aktives Handeln passiert nichts.

Was sich 2025 deutlich verbessert hat: CloudFormation validiert Templates jetzt vor dem Deployment noch besser und meldet Fehler früher. Nervige Rollback-Gründe wie ungültige Properties und Constraint-Verletzungen werden dadurch erkannt, bevor Ressourcen angefasst werden. Der alte Kreislauf aus deploy, warten, Facepalm, Rollback, von vorn ist damit deutlich seltener.

Vor dem Deployment willst du natürlich sehen, was sich ändert. Das ist gerade beim Entwickeln super hilfreich. terraform plan zeigt das sehr klar und detailliert - inklusive Ressourcen, die gelöscht und neu erstellt werden. Auf CDK-Seite gibt es cdk diff, das ähnliche Informationen liefert. Manchmal braucht man für die volle Übersicht aber zusätzlich die Change Sets in der CloudFormation-Console. Aus meiner Sicht sind die Tools hier aber einigermaßen gleichauf.

State, Drift und Refactoring

Beide Tools verwalten State - aber unterschiedlich, und das prägt die gesamte Nutzung.

Terraform verwaltet seinen State selbst in einer JSON-Datei. Auf AWS liegt die typischerweise in S3, damit das ganze Team darauf Zugriff hat. Damit es keine Kollisionen gibt, wird das Ganze mit Locking in DynamoDB abgesichert. Das heißt: bevor du überhaupt anfangen kannst, brauchst du eigene Infrastruktur für den State. Und ein korruptes State-File oder vergessenes Locking kann Deployments blockieren oder manuelles Wiederherstellen erforderlich machen. Bucket Versioning ist dabei Pflicht.

CDK hat auch einen S3-Bucket für Artefakte, der wird aber automatisch über das sogenannte Bootstrapping erstellt. Den CloudFormation-State verwaltet AWS selbst - Korruption ist dort kein Thema.

Drift - also wenn jemand manuell in der Console etwas ändert - erkennt Terraform automatisch beim nächsten plan. Bei CloudFormation musst du Drift Detection aktiv anstoßen, und das wirkt sich erst mal nicht auf dein CDK-Deployment aus. AWS hat hier mit drift-aware Change Sets nachgelegt, aber Terraforms automatische Erkennung bleibt der sauberere Ansatz.

Auch beim Refactoring hat Terraform leicht die Nase vorn. Der moved Block macht Umbenennungen und Verschiebungen im PR reviewbar und versioniert in Git. In CDK kann eine Code-Umstrukturierung dazu führen, dass CloudFormation Ressourcen ersetzen statt aktualisieren will. Das kann zu einigem an manueller Arbeit führen, vor allem bei Ressourcen, die stateful sind und damit nicht so einfach ersetzt werden können - wie Datenbanken. AWS hat 2025 mit cdk refactor einen großen Schritt gemacht, aber das Feature ist noch frisch - und der klassische Weg über Retain, Remove und Import bleibt für manche Szenarien weiterhin nötig.

Multi-Cloud

Das wohl häufigste Argument für Terraform. Und gleichzeitig vielleicht auch das am meisten überschätzte.

Wenn dein Unternehmen in mehreren Clouds zu Hause ist oder seine Cloud-Infrastruktur mit einigen zusätzlichen Diensten garniert, bietet Terraform einen echten Vorteil: ein Tool, eine Sprache, ein Workflow für alles. Ressourcen über Cloud-Grenzen hinweg verwalten und zusammen aktualisieren. Dazu ein riesiges Provider-Ökosystem, das auch Anbieter wie GitHub, PagerDuty oder Datadog abdeckt. Mit CDK geht das nicht in dem Umfang. Custom Resources können helfen, aber haben ihre Tücken und eignen sich nicht für größere externe Infrastruktur.

Wie relevant das ist, lässt sich pauschal nicht beantworten - es hängt stark von der eigenen Landschaft ab. Gerade im Mittelstand, wo typischerweise der Großteil auf einer Cloud aufbaut, ist Multi-Cloud selten ein echtes Thema. Hier hat man eher den Mix aus Cloud und On-Premise, und da hilft Terraform in der Regel auch nicht weiter. Aber wenn Multi-Cloud für dich relevant ist, ist die Entscheidung einfach - dann ist Terraform eine sehr gute Wahl.

Wann was

Es gibt keine universelle Antwort, aber es gibt klare Indikatoren.

Terraform ergibt Sinn, wenn du mehrere Cloud-Provider und externe Anbieter verwaltest und ein einheitliches Tooling dafür willst. Wenn du große Mengen bestehender Infrastruktur unter IaC bringen musst - hier ist Terraform mit dem import Block und Tools wie Terraformer klar im Vorteil. Oder wenn dir transparentes State Management und ausgereiftes Refactoring-Tooling besonders wichtig sind.

CDK ergibt Sinn, wenn du auf AWS baust und die Tiefe der AWS-Integration nutzen willst. Wenn dein Team TypeScript oder Python schreibt und die Infrastruktur kein Fremdkörper im Entwicklungsprozess sein soll. Wenn du Infrastruktur und Applikation im selben Projekt halten willst - mit geteilten Interfaces, gemeinsamem Deployment und echten Tests. Und wenn du die Abstraktion und Wiederverwendbarkeit einer echten Programmiersprache bevorzugst.

Wir sind mit CDK am Ende produktiver als mit Terraform. Nicht weil Terraform schlechter ist - in manchen Dimensionen ist es klar besser. Sondern weil CDK näher an dem ist, wie wir ohnehin arbeiten: TypeScript, Serverless, AWS-native. Die Infrastruktur fühlt sich nicht an wie ein separater Prozess, sondern wie ein Teil des Produkts. Die Stärken von Terraform wiegen für uns weniger schwer, weil wir sehr wenig außerhalb von AWS nutzen und sich CDK nahtlos in unseren Entwicklungsprozess integriert. Das ist für uns ein entscheidender Vorteil.

Wenn du dich gerade grundsätzlich für Infrastructure as Code interessierst, findest du in unserem Artikel Infrastructure as Code mit AWS CDK einen guten Startpunkt. Und wenn du vor der Toolentscheidung stehst, nimm gerne Kontakt mit uns auf - wir teilen gerne unsere Erfahrungen mit dir 😉

Das könnte dich auch interessieren

Infrastructure as Code mit AWS CDK

Manuelles Erstellen von AWS-Infrastruktur funktioniert, solange bis es nicht mehr funktioniert. In diesem Artikel schauen wir uns an, warum klassische IaC-Tools das Problem nur verlagern und wie AWS CDK Infrastruktur zu einem echten Software-Projekt macht.

5 min Lesezeit

AWS CDK vs. Terraform - Ein ehrlicher Vergleich aus der Praxis