Claude Code + Terraform: AI Infrastructure as Code schreiben 2026

Warum IaC + KI: Das Ende des Provider-Syntax-Auswendiglernens

Wer regelmäßig mit Terraform arbeitet, kennt das Ritual: Tab auf, registry.terraform.io im Browser, provider-spezifisches Resource-Schema nachschlagen, Argumente rauskopieren, anpassen, terraform validate hoffen. Und das für jeden neuen Provider, jede neue Resource, jedes neue Team-Mitglied.

Das ändert sich mit Claude Code fundamental. Nicht weil die KI fehlerfrei ist — sondern weil sie alle ga¨ngigen Provider-Schemas kennt, HCL-Syntax korrekt generiert, Best Practices einbaut und gleichzeitig Security-Probleme erkennt, die im Alltag routinemäßig durchrutschen. Das Ergebnis: Du beschreibst Infra auf Deutsch oder Englisch, bekommst vier sauber aufgeteilte .tf-Dateien zurück — und kannst dich auf Architektur-Entscheidungen konzentrieren statt auf HCL-Klammern.

In diesem Artikel zeigen wir vier konkrete Use Cases mit echten Prompts und Code-Beispielen: Infra generieren, Terraform reviewen, Fehler debuggen und State-Management. Am Ende ein vollständiges Hetzner-Cloud-Beispiel mit allen vier Standard-Dateien.

Use Case 1: Neue Infrastruktur beschreiben → Terraform generieren

Der intuitivste Einstieg: Du beschreibst, was du brauchst — Claude Code generiert den vollständigen HCL-Code, aufgeteilt in provider.tf, main.tf, variables.tf und outputs.tf. Keine Provider-Doku, kein Schema-Lookup, kein manuelles Formatieren.

Erstelle Terraform-Code für einen Hetzner Cloud Server: Ubuntu 24.04, Typ CX22, Standort nbg1. Dazu eine Firewall, die nur Port 22 von meiner IP 203.0.113.42/32, Port 80 und 443 für alle erlaubt. SSH-Key per Variable einbindbar. Ausgabe: Server-IP und Server-ID. Bitte in vier separate Dateien aufteilen: provider.tf, main.tf, variables.tf, outputs.tf.

Was Claude Code daraus macht, ist direkt produktionsreif einsetzbar. Kein Boilerplate suchen, kein Tipp-Fehler beim Resource-Namen — die KI kennt den Unterschied zwischen hcloud_server und hcloud_firewall und weiss, welche Argumente Pflicht sind.

Profi-Tipp: Wenn du ein bestehendes Projekt hast, lade alle .tf-Dateien mit /add in den Kontext. Claude Code berücksichtigt dann naming conventions, Modul-Struktur und Variable-Muster, die du bereits verwendest.

Vollständiges Hetzner-Beispiel: Vier Dateien aus einer Beschreibung

Das folgende Setup zeigt den Output des obigen Prompts — bereinigt und kommentiert für Produktionseinsatz.

    provider.tf# Hetzner Cloud Provider
terraform {
  required_version = ">= 1.6.0"
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.47"
    }
  }
}

provider "hcloud" {
  token = var.hcloud_token
}

    main.tf# SSH Key
resource "hcloud_ssh_key" "default" {
  name       = "${var.project_name}-key"
  public_key = var.ssh_public_key
}

# Firewall
resource "hcloud_firewall" "main" {
  name = "${var.project_name}-fw"

  rule {
    direction  = "in"
    protocol   = "tcp"
    port       = "22"
    source_ips = var.ssh_allowed_ips
  }

  rule {
    direction  = "in"
    protocol   = "tcp"
    port       = "80"
    source_ips = ["0.0.0.0/0", "::/0"]
  }

  rule {
    direction  = "in"
    protocol   = "tcp"
    port       = "443"
    source_ips = ["0.0.0.0/0", "::/0"]
  }
}

# Server
resource "hcloud_server" "main" {
  name        = var.project_name
  image       = "ubuntu-24.04"
  server_type = var.server_type
  location    = var.location
  ssh_keys    = [hcloud_ssh_key.default.id]

  firewall_ids = [hcloud_firewall.main.id]

  labels = {
    managed-by = "terraform"
    project    = var.project_name
  }
}

    variables.tfvariable "hcloud_token" {
  description = "Hetzner Cloud API Token"
  type        = string
  sensitive   = true
}

variable "project_name" {
  description = "Projektname (wird als Prefix für alle Ressourcen genutzt)"
  type        = string
  default     = "myapp-prod"
}

variable "ssh_public_key" {
  description = "SSH Public Key (ssh-ed25519 ...)"
  type        = string
}

variable "ssh_allowed_ips" {
  description = "IPs mit SSH-Zugriff (CIDR)"
  type        = list(string)
  default     = ["203.0.113.42/32"]
}

variable "server_type" {
  description = "Hetzner Server-Typ"
  type        = string
  default     = "cx22"
}

variable "location" {
  description = "Hetzner Standort (nbg1, fsn1, hel1)"
  type        = string
  default     = "nbg1"
}

    outputs.tfoutput "server_ip" {
  description = "Öffentliche IPv4-Adresse des Servers"
  value       = hcloud_server.main.ipv4_address
}

output "server_id" {
  description = "Hetzner Server-ID"
  value       = hcloud_server.main.id
}

output "firewall_id" {
  description = "Firewall-ID"
  value       = hcloud_firewall.main.id
}

output "ssh_command" {
  description = "SSH-Befehl für direkten Zugriff"
  value       = "ssh root@${hcloud_server.main.ipv4_address}"
}

Vier saubere Dateien, Sensitive-Flag auf dem API-Token, Labels für Cost-Tracking, source_ips mit IPv4 und IPv6 — alles, was in einem echten Produktions-Setup erwartet wird. Das ist der Qualitätsunterschied zu einem schnellen Stack-Overflow-Copy-Paste.

Use Case 2: Existierendes Terraform reviewen

Noch wertvoller als Generieren ist das Review. Bestehende Terraform-Configs wachsen oft über Jahre — mit Präzedenzällen, Workarounds und Best-Practices, die zum Entstehungszeitpunkt noch nicht existierten. Claude Code liest das gesamte Verzeichnis und gibt strukturiertes Feedback.

Reviewe die Terraform-Dateien in diesem Verzeichnis auf: 1) Sicherheitsprobleme (offene Ports, fehlende Verschlüsselung, breite IAM-Permissions), 2) Best-Practices-Verstöße (hardcodierte Werte, fehlende Descriptions, keine sensitive-Flags), 3) State-Backend-Konfiguration. Priorisiere Findings nach Kritikalität.

Das Ergebnis ist ein priorisiertes Finding-Dokument — Critical, High, Medium, Low — mit konkreten Code-Diffs für jedes Problem. Kein allgemeines "du solltest Secrets verschlüsseln", sondern direkt: "Zeile 14, var.db_password ohne sensitive = true — hier ist der Fix".

Use Case 3: Terraform-Fehler debuggen

Der dritte, im Alltag häufigste Use Case: terraform plan oder terraform apply schlägt fehl, und der Error-Output ist kryptisch. Claude Code analysiert den vollständigen Output und erklärt nicht nur was schiefging, sondern warum — und liefert den Fix.

Hier ist der Output von `terraform apply`. Analysiere den Fehler, erkläre die Ursache und zeige den Fix für die betreffende .tf-Datei: [paste apply output]

Typische Fehlerkategorien, bei denen das besonders stark ist:

Provider-Versionskonflikt: required_providers constraint matcht nicht mit Lock-File
Circular Dependencies: Resource A hängt von B ab, B von A — Claude Code erkennt den Zyklus und schlägt Refactoring vor
API-Limits: Rate-Limit-Fehler bei parallelen Ressourcen — depends_on oder -parallelism=5 als Lösung
State-Drift: Manuell geänderte Ressourcen ausserhalb Terraform — Import-Strategie

Use Case 4: State-Management — Ressourcen importieren

Eine der komplexesten Terraform-Aufgaben: Eine Infrastruktur existiert bereits — manuell angelegt oder mit einem anderen Tool erstellt — und soll jetzt unter Terraform-Kontrolle gebracht werden. terraform import war traditionell eine manuelle, fehleranfällige Übung.

Ich habe einen bestehenden Hetzner Server mit ID 12345678 und eine Firewall mit ID 87654321, die ich unter Terraform-State bringen möchte. Generiere: 1) Die Resource-Blöcke für main.tf, 2) die korrekten `terraform import` Befehle, 3) einen Checklist für den Prozess, damit kein ungewolltes `destroy` passiert.

Claude Code generiert nicht nur den Import-Befehl, sondern warnt aktiv vor dem häufigsten Fehler: nach dem Import ein terraform plan zu machen, ohne die Resource-Definition mit dem tatsächlichen State abzugleichen — was zu einem ungewollten in-place update oder schlimmer einem destroy & recreate führen kann.

Wichtig beim Import: Immer zuerst terraform plan prüfen, bevor apply ausgeführt wird. Claude Code kann eine Checkliste generieren, die jeden Step absichert — inklusive State-Backup vor dem Import.

Sicherheits-Review mit Claude Code

Security-Audits von IaC sind ein Bereich, wo KI-gestütztes Review menschliche Reviewer übertrifft — nicht weil Menschen schlechter sind, sondern weil Review-Fatigue bei 800 Zeilen HCL real ist. Claude Code wird nicht müde.

Die häufigsten IaC-Sicherheitsprobleme

1 Port 22 offen für alle

source_ips = ["0.0.0.0/0"] auf SSH ist der Klassiker. Prompt: "Prüfe alle Firewall-Rules auf Port 22 — ist der Zugang auf spezifische IPs oder Ranges beschränkt?" Claude Code scannt alle hcloud_firewall-Ressourcen und gibt ein direktes Ja/Nein mit Fundstellen.

2 Unverschlüsselte Volumes

Bei AWS EBS, GCP Persistent Disk oder Azure Managed Disks: Fehlendes encrypted = true bzw. fehlendes KMS-Key-Attribut. Claude Code erkennt Provider-spezifisch, welche Felder für Encryption zuständig sind — und ob ein KMS Key-ARN angegeben ist oder nur der Default-Key genutzt wird.

3 Public IP ohne Load Balancer oder WAF

Server mit direkter Public IP ohne zwischengeschalteten Load Balancer, Cloudflare oder WAF. Claude Code prüft, ob hcloud_server-Ressourcen eine direkte IPv4 haben, während kein Load Balancer in der Config definiert ist.

4 Hardcodierte Secrets im Code

API-Tokens, Passwörter oder Access Keys direkt in .tf-Dateien statt über Variables mit sensitive = true. Prompt: "Scanne alle .tf-Dateien auf hardcodierte Credentials — gib mir Datei, Zeile und empfohlene Variable." Ergebnis: ein vollständiger Findings-Report innerhalb von Sekunden.

Für einen umfassenden Audit kombiniere Claude Code mit automatisierten Security-Scans im CI/CD-Pipeline — tfsec oder Checkov im GitHub Actions Workflow, Claude Code für das manuelle Review von komplexen Policy-Entscheidungen.

Terraform vs. Pulumi vs. Ansible: Wann welches Tool

Tool	Stärken	Schwachpunkte	Ideal für
Terraform	Best Declarative State Management Riesiges Provider-Ökosystem HCL lesbar für Nicht-Entwickler	Kein Loop-Programmierstil State-Management-Komplexitat Provider-Updates können brechen	Cloud-Infra-Provisioning, Multi-Cloud, Teams mit gemischtem Hintergrund
Pulumi	Best Echte Programmiersprache (TS, Python, Go) Tests mit Standard-Frameworks Conditional Logic nativ	Höhere Lernkurve Kleineres Ökosystem als Terraform Pulumi Cloud State Backend kostenpflichtig	Komplexe Infra mit Loops, Conditionals; Dev-Teams die ohnehin TypeScript schreiben
Ansible	Best Server-Konfiguration Agentless via SSH YAML intuitiv für Ops	Schwach bei State-Tracking Kein Drift-Detection Langsam bei vielen Hosts	Post-Provisioning Config (Pakete, Services, Files); Hybrid-Umgebungen; kein Terraform-State gewünscht

In der Praxis sind Terraform und Ansible komplementär, nicht konkurrierend: Terraform provisioniert die Infrastruktur (Server, Netzwerke, DNS), Ansible konfiguriert sie (Pakete, Dienste, Applikations-Config). Claude Code versteht beide Toolchains und kann dir helfen, den Schnitt zwischen beiden sauber zu definieren.

Workflow-Empfehlung: Claude Code in den IaC-Alltag integrieren

Die effektivste Integration ist nicht "Claude Code statt Terraform-Doku", sondern Claude Code als permanenter Pair-Programmer im IaC-Prozess:

Initiale Generierung: Neue Infrastruktur als Prompt beschreiben, vier Dateien generieren lassen, dann manuell reviewen
Pre-Commit Review: Vor jedem Commit alle geänderten .tf-Dateien auf Security-Issues prüfen lassen
Plan-Analyse: terraform plan -out=plan.out && terraform show -json plan.out → JSON an Claude Code übergeben, nach unerwarteten Destroy-Actions fragen
Fehler-Debugging: Apply-Fehler direkt in den Chat kopieren, ohne erst Provider-Changelog zu lesen
Modul-Refactoring: Größere Config in wiederverwendbare Module aufteilen lassen

Kontext ist alles: Claude Code ist umso besser, je mehr Kontext du gibst. Lade nicht nur eine einzelne main.tf, sondern das gesamte Terraform-Verzeichnis (/add .). Die KI versteht dann die Abhängigkeiten zwischen Ressourcen, bestehende Variable-Konventionen und welche Module bereits verwendet werden.

Fazit: IaC-Qualität steigt, Kognitive Last sinkt

Der zentrale Mehrwert von Claude Code für Terraform ist nicht Geschwindigkeit — obwohl die Zeitersparnis real ist. Der Hauptgewinn ist konsistente Qualität: Security-Checks, die nicht vergessen werden. Sensitive-Flags, die immer gesetzt sind. Outputs, die immer eine Description haben. Best Practices, die nicht vom Stresslevel des Reviewers abhängen.

Terraform-Syntax auswendig kennen war gestern. Was bleibt, ist das, was KI nicht übernehmen kann: die Architektur-Entscheidung, ob du ein Single-Server-Setup brauchst oder ein Multi-Region-Cluster. Ob du Hetzner nimmst oder AWS. Ob du Terraform-Module baust oder zuerst iterierst. Das ist die Arbeit, die Zählt — und genau dahin verschiebt sich deine Zeit, wenn Claude Code den Rest übernimmt.

IaC mit KI — direkt ausprobieren

Starte kostenlos und sieh, wie Claude Code dein Terraform-Workflow beschleunigt — von der ersten Resource bis zum Security-Audit.

Kostenlos starten →

Kein Kreditkarte erforderlich • Setup in unter 2 Minuten

Claude Code + Terraform: IaC mit KI schreiben, reviewen & debuggen