AWS CDK erklärt - App, Stack, Constructs und Deployment

Cloud-Infrastruktur wird schnell unübersichtlich, sobald aus einem einzelnen S3-Bucket eine Anwendung mit Netzwerk, Datenbank, Funktionen und Monitoring wird. AWS CDK hilft dabei, solche Ressourcen mit vertrauten Programmiersprachen zu definieren, zu testen und über AWS CloudFormation reproduzierbar bereitzustellen. Ich zeige, wie das Modell aus App, Stack und Constructs funktioniert, wie ein typischer Deployment-Ablauf aussieht und wo die Stärken und Grenzen des Ansatzes liegen.

Was AWS CDK in der Softwareentwicklung leistet

Das AWS Cloud Development Kit, kurz CDK, ist ein Open-Source-Framework für Infrastructure as Code. Statt Ressourcen ausschließlich in YAML oder JSON zu beschreiben, definiere ich sie mit TypeScript, Python, Java, C#/.NET, JavaScript oder Go. CDK übersetzt diesen Code anschließend in Vorlagen für AWS CloudFormation.

Der entscheidende Unterschied zu einem gewöhnlichen Skript liegt darin, dass der Code nicht direkt jeden einzelnen API-Aufruf ausführt. Er beschreibt den gewünschten Zielzustand. CloudFormation übernimmt später die Erstellung, Änderung und Löschung der Ressourcen. Dadurch lassen sich Infrastrukturänderungen genauso versionieren, reviewen und automatisieren wie Anwendungscode.

In der Praxis ist das besonders nützlich, wenn mehrere Umgebungen identisch aufgebaut werden müssen. Eine Test-, Staging- und Produktionsumgebung kann aus denselben wiederverwendbaren Bausteinen entstehen, während sich Region, Account, Größen oder Konfigurationswerte gezielt unterscheiden.

Warum Programmcode oft angenehmer ist als reine Vorlagen

Programmiersprachen bringen Bedingungen, Schleifen, Funktionen, Typprüfung und Module mit. Ich kann beispielsweise je nach Umgebung unterschiedliche Instanzgrößen wählen oder eine komplette Netzwerkstruktur als eigene Klasse kapseln. Das reduziert Wiederholungen und macht komplexe Architekturen leichter erweiterbar.

Der Vorteil ist allerdings kein Freifahrtschein für beliebig komplizierten Code. Infrastruktur bleibt Infrastruktur. Wenn die Abstraktion zu clever wird, versteht ein Team später nur noch schwer, welche AWS-Ressourcen tatsächlich entstehen. Meine Empfehlung lautet deshalb, einfache Konstrukte und klare Namen höher zu bewerten als maximale Wiederverwendung.

App, Stack und Constructs einfach auseinandergehalten

Viele Einstiegsschwierigkeiten entstehen, weil die drei Grundbegriffe zunächst ähnlich wirken. Ich betrachte sie als drei Ebenen derselben Anwendung.

Constructs bilden die eigentliche Architektur ab

Ein sogenannter L1-Construct entspricht sehr nah einer einzelnen CloudFormation-Ressource. L2-Constructs bieten sinnvollere Voreinstellungen und Hilfsmethoden, etwa für Berechtigungen oder Verschlüsselung. L3-Constructs gehen noch weiter und bündeln typische Lösungen, zum Beispiel eine Fargate-Anwendung hinter einem Application Load Balancer.

Für die meisten Teams sind L2-Constructs der beste Ausgangspunkt. Sie sparen viel Konfigurationsarbeit, ohne die Architektur vollständig zu verstecken. Wenn spezielle Anforderungen bestehen, kann ich immer noch auf eine niedrigere Ebene wechseln oder einen eigenen Construct schreiben.

Ein kleines Beispiel mit TypeScript

Der folgende Stack erzeugt einen privaten S3-Bucket mit aktivierter Verschlüsselung und automatischer Löschung nicht mehr benötigter Objekte. Für produktive Datenbanken oder Archive würde ich diese Löschstrategie selbstverständlich nicht verwenden.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class StorageStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'ApplicationBucket', {
      encryption: s3.BucketEncryption.S3_MANAGED,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true
    });
  }
}

Die wenigen Zeilen erzeugen nicht nur einen Bucket, sondern auch die dazugehörige CloudFormation-Definition. Besonders wichtig sind hier die expliziten Sicherheitseinstellungen. Öffentlicher Zugriff wird blockiert, statt sich auf zufällige Standardwerte zu verlassen.

So sieht der CDK-Workflow vom Code bis zur Cloud aus

Ein neues Projekt lässt sich mit dem CDK-CLI anlegen. Für TypeScript beginnt ein einfacher Einstieg beispielsweise mit:

mkdir meine-infrastruktur
cd meine-infrastruktur
cdk init app --language typescript
npm install
cdk bootstrap
cdk synth
cdk diff
cdk deploy

Aktuell benötigen CDK-Entwickler unabhängig von der gewählten Sprache eine passende Node.js-Laufzeit. Für die aktuelle CDK-v2-Toolchain nennt AWS Node.js 22.x oder neuer als Voraussetzung. Zusätzlich müssen AWS CLI und Zugangsdaten korrekt eingerichtet sein.

Was die wichtigsten Befehle bedeuten

• cdk init erstellt die Grundstruktur des Projekts.
• cdk bootstrap bereitet einen AWS-Account und eine Region für CDK-Bereitstellungen vor.
• cdk synth erzeugt aus dem Programmcode eine CloudFormation-Vorlage und ein Cloud Assembly.
• cdk diff zeigt geplante Änderungen gegenüber dem bisherigen Stack.
• cdk deploy übergibt die erzeugten Artefakte an CloudFormation.
• cdk destroy löscht einen Stack, sofern die Ressourcen und Schutzregeln das erlauben.

Ich führe vor jedem produktiven Deployment mindestens cdk synth und cdk diff aus. Das dauert meist nur wenige Sekunden, kann aber sichtbar machen, dass eine scheinbar kleine Codeänderung ein komplettes Netzwerk oder eine Datenbank ersetzt.

Warum Bootstrap mehr ist als ein einmaliger Setup-Befehl

Beim Bootstrapping legt CDK unter anderem einen S3-Bereich für Assets, ein ECR-Repository für Container-Images und Rollen für Bereitstellung und Lookups an. Jeder Ziel-Account und jede Ziel-Region muss vorbereitet sein, bevor der erste Stack dort landet.

Gerade bei mehreren AWS-Accounts wird dieser Schritt häufig unterschätzt. Ich verwalte das Bootstrapping deshalb wie normalen Infrastrukturcode, dokumentiere die verwendeten Rollen und prüfe, ob die Berechtigungen wirklich zum Deployment-Prozess passen.

Welche Sprache passt zu welchem Team

Technisch bieten die unterstützten Sprachen weitgehend dieselben CDK-Funktionen. Die Entscheidung sollte sich daher weniger an vermeintlichen Leistungsunterschieden orientieren, sondern an den Kenntnissen des Teams, den vorhandenen Tests und der bestehenden Build-Pipeline.

Für ein neues Team würde ich meist TypeScript oder Python wählen. TypeScript hilft bei großen Infrastrukturprojekten durch die Typprüfung, während Python oft schneller lesbar ist. Entscheidend ist am Ende, dass eine Sprache konsistent im gesamten Repository verwendet wird und Abhängigkeiten regelmäßig aktualisiert werden.

Was CDK besser macht als CloudFormation und Terraform

CDK ersetzt CloudFormation nicht, sondern erzeugt dessen Vorlagen. Wer bereits stark auf AWS und CloudFormation setzt, erhält deshalb eine höhere Programmiersprache, ohne den AWS-eigenen Deployment-Mechanismus zu verlassen.

Meine Faustregel ist einfach. Für eine überwiegend AWS-basierte Plattform mit Entwicklerteams ist CDK oft sehr produktiv. Muss dieselbe Infrastruktur regelmäßig in AWS, Azure und Google Cloud funktionieren, kann Terraform organisatorisch besser passen. Für ein kleines, statisches AWS-Setup bleibt eine direkte CloudFormation-Vorlage manchmal verständlicher.

Ein weiterer Unterschied wird gern übersehen: CDK-Code kann beliebige Bibliotheken, Netzwerkzugriffe und Berechnungen ausführen. Das ist praktisch, erhöht aber die Verantwortung. Ich behandle deshalb jede externe Abhängigkeit und jeden Lookup wie normalen Produktionscode und lasse den generierten CloudFormation-Output im Review sichtbar werden.

Die häufigsten Fehler bei CDK-Projekten

Infrastruktur nur lokal testen

Ein erfolgreicher Build beweist nicht, dass ein Stack sicher oder deploybar ist. Mit dem Assertions-Modul können konkrete Eigenschaften der generierten Vorlage geprüft werden, beispielsweise Verschlüsselung, private Netzwerke oder eine bestimmte IAM-Berechtigung.

Ich kombiniere feingranulare Assertions für sicherheitsrelevante Eigenschaften mit wenigen Snapshot-Tests. Snapshots sind praktisch, werden aber schnell unübersichtlich, wenn jede harmlose Frameworkänderung den kompletten Output verändert.

Zu breite IAM-Rechte vergeben

CDK erleichtert Berechtigungen mit Methoden wie grantRead oder grantWrite. Das ist meistens sauberer als eine selbst formulierte AdministratorPolicy. Trotzdem sollte ein Team regelmäßig prüfen, welche Rolle tatsächlich entsteht und ob der Zugriff noch benötigt wird.

Für größere Organisationen gehören Least Privilege, Permission Boundaries und Service Control Policies in die Plattformstrategie. Produktivität und Governance schließen sich nicht aus, wenn die Leitplanken vor dem Deployment wirksam werden.

Produktionsressourcen versehentlich löschbar machen

Eine Einstellung wie RemovalPolicy.DESTROY ist für temporäre Testressourcen bequem, für Kundendaten aber gefährlich. Bei S3, RDS, Secrets und Schlüsselmaterial prüfe ich Löschschutz, Backups und Aufbewahrungsanforderungen ausdrücklich.

Lesen Sie auch: npm ci richtig nutzen für reproduzierbare Node.js-Builds

Umgebungen nur über spontane Parameter steuern

CDK unterstützt Context-Werte und Konfigurationsdateien. Sensible Werte gehören jedoch nicht in das Repository. Für Passwörter, Tokens und andere Geheimnisse nutze ich Secrets Manager oder Systems Manager Parameter Store und referenziere nur deren Namen oder ARNs.

Sauberer wird es, wenn Test, Staging und Produktion als klar benannte Stacks modelliert sind. So bleibt im Code sichtbar, welche Unterschiede beabsichtigt sind, statt sie in einer langen Liste von Kommandozeilenparametern zu verstecken.

Wann sich der Einstieg wirklich lohnt

CDK spielt seine Stärken aus, wenn Infrastruktur häufig geändert wird, mehrere Umgebungen existieren oder Ressourcen als wiederverwendbare Plattformbausteine dienen. Ein typischer Kandidat ist eine Webanwendung mit VPC, Load Balancer, ECS oder Lambda, Datenbank, Monitoring und getrennten Accounts.

Weniger überzeugend ist der Ansatz, wenn ein Team nur einen einzelnen Bucket anlegen möchte und keine weitere Automatisierung geplant ist. Auch komplexe CDK-Abstraktionen lohnen sich erst dann, wenn sie mindestens an zwei Stellen wirklich wiederverwendet werden. Sonst entsteht zusätzlicher Code, der den einfachen Cloud-Aufbau eher verdeckt.

Die Kostenfrage ist unkompliziert, aber wichtig. Für CDK selbst fällt keine zusätzliche AWS-Gebühr an. Bezahlt werden die erzeugten Dienste, etwa Speicher, Datenbank, Datenübertragung, Logs oder laufende Compute-Ressourcen. Ein schlecht dimensionierter Stack bleibt also teuer, selbst wenn sein CDK-Code elegant aussieht.

Ein guter nächster Schritt für die eigene Plattform

Ich würde nicht mit einer großen Unternehmensplattform beginnen. Ein kleines Repository mit einem Stack, automatisierten Tests, cdk diff im Pull Request und einem kontrollierten Deployment zeigt schnell, ob Arbeitsweise und Team wirklich zusammenpassen.

Wenn dieses Fundament steht, lohnt sich die nächste Ausbaustufe mit eigenen Constructs, getrennten Accounts, zentralen Sicherheitsregeln und einer CI/CD-Pipeline. Der eigentliche Wert entsteht nicht durch möglichst viele CDK-Zeilen, sondern durch reproduzierbare Änderungen, nachvollziehbare Reviews und weniger manuelle Überraschungen in der Cloud.