Claude Code Terraform: Infrastructure as Code schneller schreiben und sicher verwalten

Terraform ist mächtig — und gleichzeitig eines der Werkzeuge, bei dem man am meisten Zeit damit verbringt, Dokumentation zu lesen statt Infrastruktur zu bauen. Welche Provider-Version ist aktuell? Wie heißt das Argument für das S3-Backend nochmal? Welche Ressource braucht welche Abhängigkeit?

Claude Code Terraform verändert diesen Workflow grundlegend: HCL generieren, bestehende Konfigurationen erklären, Drift zwischen State und Realität erkennen, Module refactoren — all das passiert direkt im Kontext deines Projekts, ohne ständig zwischen Terminal, Browser und Dokumentation zu wechseln.

1. Was ist Terraform — und warum Infrastructure as Code?

Terraform ist ein Open-Source-Werkzeug von HashiCorp (seit 2023 unter der BSL-Lizenz, mit OpenTofu als Community-Fork unter MPL). Die Kernidee: Infrastruktur wird als Code beschrieben, nicht manuell in Web-Konsolen zusammengeklickt. AWS-Instanzen, GCP-Netzwerke, DNS-Einträge, Kubernetes-Cluster — alles in Textdateien, die in Git versioniert werden.

Das klingt abstrakt, aber der praktische Vorteil ist konkret: Wer manuell in der AWS-Konsole klickt, weiß sechs Monate später nicht mehr, warum welche Security Group welche Regel hat. Wer Terraform verwendet, hat den Grund im Code-Kommentar — und kann die gesamte Umgebung mit einem Befehl in einer neuen Region reproduzieren.

Das Herzstück von Terraform ist der State: eine JSON-Datei (terraform.tfstate), die festhält, welche realen Ressourcen welchen Terraform-Definitionen entsprechen. Ohne State wüsste Terraform nicht, was es bereits erstellt hat.

2. Grundstruktur: Provider, Resources, Variables, Outputs

Jedes Terraform-Projekt besteht aus denselben Bausteinen. Claude Code versteht diese Struktur und kann sowohl einzelne Blöcke generieren als auch vollständige Projektgerüste aufbauen.

Provider

Der Provider teilt Terraform mit, mit welcher Plattform es arbeitet und wie es sich dort authentifiziert:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

Resources

Ressourcen sind die eigentlichen Infrastruktur-Objekte. Jede Ressource hat einen Typ (z.B. aws_instance) und einen lokalen Namen:

resource "aws_instance" "web" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = var.instance_type

  tags = {
    Name        = "web-${var.environment}"
    Environment = var.environment
  }
}

Variables und Outputs

Variables parametrisieren Konfigurationen, Outputs geben Werte nach außen weiter — z.B. an andere Terraform-Module oder als Information nach einem apply:

variable "environment" {
  type        = string
  description = "Deployment environment (dev/staging/prod)"
  default     = "dev"
}

output "instance_public_ip" {
  value       = aws_instance.web.public_ip
  description = "Public IP of the web instance"
}

Claude Code kann diese Blöcke nicht nur generieren, sondern auch erklären: "Was macht dieser lifecycle-Block?" oder "Warum gibt es hier einen depends_on?" — direkt im Kontext deiner Dateien, ohne Dokumentation-Tab.

3. Die wichtigsten Befehle: init, plan, apply, destroy, import

Der Terraform-Workflow folgt einem klar definierten Ablauf. Claude Code kann nicht nur die Befehle erklären, sondern auch Ausgaben interpretieren und Probleme diagnostizieren.

• terraform init — Initialisiert das Projekt: lädt Provider-Plugins, konfiguriert das Backend für den State.
• terraform plan — Berechnet, was sich ändern würde, ohne etwas zu tun. Immer vor apply ausführen.
• terraform apply — Setzt den Plan um und aktualisiert den State.
• terraform destroy — Löscht alle verwalteten Ressourcen. Braucht explizite Bestätigung.
• terraform import — Nimmt eine bereits existierende Ressource in den State auf, ohne sie neu zu erstellen.

Besonders terraform import ist ein häufiger Stolperstein: Die Ressource muss erst im HCL-Code definiert werden, dann importiert werden. Claude Code hilft dabei, die korrekte Import-ID aus der AWS-Konsole zu finden und die passende HCL-Definition zu schreiben — das spart die übliche Runde durch die Terraform-Dokumentation.

claude "Ich habe eine existierende S3-Bucket 'mein-bucket-prod'. Schreib
die Terraform-Resource-Definition und den import-Befehl."

4. Remote State: S3-Backend und State Locking mit DynamoDB

Die lokale terraform.tfstate ist für Teams ein Problem: Wenn zwei Personen gleichzeitig terraform apply ausführen, überschreiben sie sich gegenseitig den State. Die Lösung ist ein Remote Backend mit State Locking.

Das klassische Setup für AWS-Teams: S3 für den State, DynamoDB für Locking.

terraform {
  backend "s3" {
    bucket         = "meine-firma-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "eu-central-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

Die DynamoDB-Tabelle braucht einen Primary Key namens LockID (String). Claude Code kann das gesamte Setup generieren — inklusive der Terraform-Konfiguration, die den S3-Bucket und die DynamoDB-Tabelle selbst erstellt (Bootstrap-Problem: diese Ressourcen müssen vor dem ersten terraform init existieren, also entweder manuell oder per separatem Terraform-Aufruf).

5. Module: Wiederverwendbare Infrastruktur-Bausteine

Module sind Terraform's Antwort auf das DRY-Prinzip. Statt dieselbe VPC-Konfiguration in jedem Projekt neu zu schreiben, kapselt man sie in einem Modul und ruft es mit unterschiedlichen Variablen auf.

Eigene Module schreiben

Ein Modul ist schlicht ein Verzeichnis mit .tf-Dateien. Die Konvention: main.tf, variables.tf, outputs.tf.

# modules/vpc/main.tf
resource "aws_vpc" "this" {
  cidr_block           = var.cidr_block
  enable_dns_hostnames = true
  tags = { Name = var.name }
}

# Aufruf im Root-Modul
module "vpc" {
  source     = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
  name       = "prod-vpc"
}

Terraform Registry nutzen

Die Terraform Registry enthält tausende fertige Module für alle gängigen Provider. AWS-VPC, EKS-Cluster, RDS-Instanzen — oft besser als selbst schreiben:

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "mein-cluster"
  cluster_version = "1.30"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnets
}

Claude Code kann Registry-Module erklären, passende Versionen empfehlen und die Variable-Belegung für deinen konkreten Use-Case generieren.

6. Workspaces: dev, staging, prod aus einem Codebase

Terraform Workspaces erlauben es, denselben Code mit unterschiedlichen States zu betreiben. Das ist praktisch für Environments — aber mit Einschränkungen.

terraform workspace new staging
terraform workspace select prod
terraform workspace list

Die aktuelle Workspace ist in terraform.workspace verfügbar und kann in Ressourcen-Namen verwendet werden:

resource "aws_s3_bucket" "data" {
  bucket = "meine-firma-data-${terraform.workspace}"
}

7. Claude Code Terraform: Konkrete Tipps aus dem Einsatz

Nach einem Jahr mit Claude Code in Terraform-Projekten haben sich einige Patterns als besonders wertvoll herauskristallisiert.

HCL generieren statt tippen

Der einfachste Gewinn: Statt eine AWS-Ressource von Grund auf zu tippen oder die Dokumentation zu durchsuchen, beschreibe das Ziel auf Deutsch.

claude "Erstelle Terraform-HCL für eine RDS PostgreSQL-Instanz in der
eu-central-1 Region, Multi-AZ, mit Backup-Retention 7 Tage,
im VPC 'prod-vpc', nur aus dem privaten Subnetz erreichbar."

Claude Code liest deine bestehenden .tf-Dateien, kennt den VPC-Namen und die Subnetz-IDs aus deinem State oder deinen Ressource-Definitionen, und generiert eine vollständige, kontextuell passende Ressource — kein Platzhalter, den du noch anpassen musst.

Drift erkennen und erklären

Wenn jemand manuell in der AWS-Konsole etwas geändert hat (passiert immer), zeigt terraform plan eine Diskrepanz. Claude Code kann die Plan-Ausgabe interpretieren und erklären, was sich in der Realität verändert hat:

terraform plan 2>&1 | claude "Was hat sich an der Infrastruktur
verändert und was passiert beim nächsten apply?"

Refactoring mit moved-Blöcken

Terraform 1.1 führte moved-Blöcke ein — damit kann man Ressourcen im State umbenennen, ohne sie neu zu erstellen. Claude Code generiert die korrekten Blöcke und erklärt, in welcher Reihenfolge Refactoring sicher ist:

moved {
  from = aws_instance.server
  to   = aws_instance.web_server
}

claude "Ich möchte mein Terraform-Modul 'database' in 'rds' umbenennen.
Was muss ich tun damit der State erhalten bleibt?"

Sicherheits-Review vor dem Apply

Bevor eine größere Änderung in Produktion geht, lohnt sich ein schnelles Review der Plan-Ausgabe:

terraform plan -out=tfplan
terraform show -json tfplan | claude "Gibt es in diesem Plan
Security-Risiken, offene Ports oder zu weit gefasste IAM-Policies?"

"Die Security Group 'web-sg' öffnet Port 22 für 0.0.0.0/0. In Produktion sollte SSH nur aus dem VPN-CIDR oder gar nicht erreichbar sein."

Diese Art Review kostet 30 Sekunden und findet Probleme, die in der Hektik des Deployments leicht übersehen werden.

Zwei verwandte Artikel, die auf diesem Thema aufbauen:

• Claude Code & GitHub Actions — CI/CD-Pipelines mit Claude Code aufbauen und debuggen
• Claude Code Debugging — Fehler systematisch finden, Root-Cause statt Symptom beheben