DevOps 10 Min Lesezeit

Terraform Infrastructure as Code – Einführung & Beispiele 2026

Was ist Terraform und warum ist es 2026 so wichtig?

Terraform ist ein Open-Source-Tool von HashiCorp, das die Idee der Infrastructure as Code (IaC) konsequent umsetzt. Statt Server per Hand über Weboberflächen oder SSH zu konfigurieren, beschreibt man die gewünschte Infrastruktur in deklarativen Konfigurationsdateien. Terraform liest diese Dateien, plant die Änderungen und wendet sie auf einen beliebigen Cloud-Provider an.

Im Jahr 2026 ist Terraform aus der modernen IT nicht mehr wegzudenken. Unternehmen jeder Größe setzen es ein, um Cloud-Ressourcen reproduzierbar, auditierbar und versionierbar zu machen. Egal ob AWS, Azure, Google Cloud, Hetzner oder ein lokales Proxmox – Terraform spricht mit Hunderten Providern über ein einheitliches Interface.

Der größte Vorteil: Was einmal in einer .tf-Datei beschrieben wurde, lässt sich beliebig oft, in beliebigen Umgebungen und von beliebigen Teams ausführen. Das eliminiert manuelle Fehler, beschleunigt Deployments und schafft Transparenz.

Grundkonzepte: Provider, Resources, State

Ein Provider ist die Brücke zu einem Cloud- oder SaaS-Anbieter. Er kennt die API, spricht mit ihr und stellt Terraform die Ressourcen als deklarative Blöcke zur Verfügung. Beispiele sind der AWS-Provider, der AzureRM-Provider oder der Hetzner-Provider.

Resources sind die eigentlichen Bausteine: Virtuelle Maschinen, Netzwerke, Datenbanken, Load Balancer, DNS-Records. Jede Resource hat einen Typ, einen Namen und Parameter. Terraform erzeugt, ändert oder zerstört sie entsprechend der Konfiguration.

Der State speichert den Ist-Zustand der verwalteten Infrastruktur. Er wird meist in einer Datei (terraform.tfstate) oder in einem Remote-Backend wie S3, Azure Blob oder Terraform Cloud abgelegt. Ohne State weiß Terraform nicht, was bereits existiert.

Die Terraform-Sprache HCL im Überblick

Terraform nutzt die HashiCorp Configuration Language (HCL). Sie ähnelt JSON, ist aber deutlich lesbarer und unterstützt Kommentare, Variablen, Funktionen und Blöcke. Eine typische Konfiguration besteht aus Provider-, Resource- und Variablen-Blöcken.

Ein einfaches Beispiel für eine AWS EC2-Instanz:

provider "aws" {
  region = "eu-central-1"
}

resource "aws_instance" "web" {
  ami           = "ami-0c7217cdde317cfec"
  instance_type = "t3.micro"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

Diese wenigen Zeilen erzeugen eine echte EC2-Instanz in Frankfurt, vollständig dokumentiert und reproduzierbar.

Der Workflow: init, plan, apply

Der klassische Terraform-Workflow besteht aus drei Phasen:

Das plan-Kommando ist besonders wertvoll: Es erzeugt einen Diff zwischen Soll- und Ist-Zustand. Vor jedem Apply sollte man den Plan prüfen, um ungewollte Änderungen zu vermeiden. Mit terraform destroy wird die gesamte Infrastruktur sauber abgebaut.

Variablen, Outputs und Module

Variablen machen Konfigurationen wiederverwendbar. Statt Region oder Instanz-Typ fest einzubauen, werden sie als Variablen deklariert und beim Aufruf übergeben. Outputs hingegen exportieren Werte, die in anderen Modulen oder im CI/CD-Prozess benötigt werden.

Module sind das Herzstück der Wiederverwendung. Ein Modul bündelt mehrere Resources zu einer logischen Einheit – etwa ein standardisiertes VPC-Modul, ein Datenbank-Modul oder ein komplettes Web-App-Setup.

Beispiel für die Verwendung von Modulen:

module "network" {
  source      = "./modules/network"
  environment = "prod"
  cidr_block  = "10.0.0.0/16"
}

output "vpc_id" {
  value = module.network.vpc_id
}

State-Management und Backends

Der State ist die wichtigste Datenstruktur in Terraform. Wird er verloren oder beschädigt, verliert Terraform den Überblick über die Infrastruktur. Daher gehört der State nicht in Git, sondern in ein Remote-Backend.

Gängige Backends:

Backend Einsatz Vorteil
S3 + DynamoDB AWS Locking out-of-the-box
Azure Blob Azure Native Integration
GCS Google Cloud Hohe Verfügbarkeit
Terraform Cloud Provider-unabhängig Zentrales Management
PostgreSQL Self-Hosted Volle Kontrolle

Mit State Locking (über DynamoDB oder Terraform Cloud) wird verhindert, dass zwei Personen gleichzeitig Änderungen ausführen.

Terraform im Vergleich: OpenTofu, Pulumi, Ansible

2026 gibt es ernsthafte Alternativen zu Terraform. OpenTofu ist ein Fork, der unter dem Dach der Linux Foundation weiterentwickelt wird und die letzte MIT-lizenzierte Version als Basis nimmt. Pulumi verfolgt einen anderen Ansatz: Infrastruktur wird in echten Programmiersprachen wie TypeScript, Python oder Go beschrieben.

Ansible ist hingegen ein Konfigurations-Management-Tool und kein IaC-Tool im engeren Sinne. Es eignet sich besonders, um Software auf bestehenden Servern zu installieren, eignet sich aber weniger für Cloud-Ressourcen.

Tool Sprache Stärke
Terraform HCL Reife, riesiges Ökosystem
OpenTofu HCL Kompatibel zu Terraform, offen
Pulumi TS/Python/Go Programmierlogik, Testing
Ansible YAML Konfigurationsmanagement

Best Practices für produktive Terraform-Projekte

Ein produktives Terraform-Setup folgt einigen grundlegenden Regeln. Erstens: Eine klare Ordnerstruktur mit getrennten Modulen für Netzwerk, Compute, Storage und Datenbanken. Zweitens: Variablen mit Validation und sinnvollen Defaults. Drittens: Outputs klar dokumentieren.

Außerdem wichtig:

Wer diese Regeln befolgt, hat eine stabile, auditierbare und teamfähige Infrastruktur.

CI/CD-Integration mit GitHub Actions und GitLab

Terraform gehört in eine CI/CD-Pipeline. Bei jedem Pull Request sollte terraform plan ausgeführt und das Ergebnis als Kommentar hinterlassen werden. Der Apply erfolgt erst nach Merge in den main-Branch und manueller Freigabe.

Beispiel für eine GitHub-Actions-Pipeline:

name: Terraform

on:
  pull_request:
    branches: [main]

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform validate
      - run: terraform plan -no-color
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Diese Pipeline stellt sicher, dass jeder Vorschlag geprüft wird, bevor er in Produktion landet.

Sicherheit: Secrets, IAM und Compliance

Credentials gehören niemals in den Code. Stattdessen nutzt man Umgebungsvariablen, OIDC (z. B. von GitHub Actions direkt zu AWS), HashiCorp Vault oder die nativen Secret-Manager der Cloud-Provider.

Mit IAM-Rollen lässt sich der Zugriff granulär steuern. Terraform sollte nur die minimal benötigten Rechte erhalten. Tools wie Infracost oder KICS prüfen zusätzlich auf Kostenfallen und Sicherheitslücken in der Konfiguration.

Ein einfaches Beispiel für die sichere Nutzung mit OIDC:

provider "aws" {
  region = "eu-central-1"
  assume_role_with_web_identity {
    role_arn = "arn:aws:iam::123456789012:role/terraform-ci"
    web_identity_token_file = "/var/run/secrets/eks.amazonaws.com/serviceaccount/token"
  }
}

Migration nach Terraform: Schritt-für-Schritt

Wer bestehende Infrastruktur in Terraform überführen will, sollte schrittweise vorgehen. Zuerst werden Ist-Daten gesammelt, dann werden die wichtigsten Ressourcen (z. B. Netzwerk, Security Groups) importiert. Terraform bietet dafür den Befehl terraform import.

Alternativ nutzt man Tools wie Terraformer oder das Cloud-Provider-eigene Importer-Skript, um große Bestände automatisch zu konvertieren. Wichtig ist, jeden Schritt in einer getrennten Branch zu halten und sauber zu testen.

Am Ende steht eine versionierte, reproduzierbare Infrastruktur, die mit dem Unternehmen mitwächst.

Fazit: Terraform bleibt der Standard für IaC

Auch 2026 ist Terraform die erste Wahl für Infrastructure as Code. Die riesige Community, die ausgereiften Provider und die unzähligen Module machen den Einstieg leicht und den Betrieb skalierbar. Mit OpenTofu existiert zudem eine offene Alternative, falls Lizenzfragen relevant werden.

Wer heute in die Cloud-Automatisierung einsteigt, kommt an Terraform kaum vorbei – und das aus gutem Grund.

Was ist Terraform und warum ist Infrastructure as Code 2026 unverzichtbar?

Terraform hat sich im Jahr 2026 als De-facto-Standard für Infrastructure as Code (IaC) etabliert und wird von Unternehmen jeder Größe eingesetzt, um Cloud- und On-Premises-Ressourcen reproduzierbar zu verwalten. Die von HashiCorp entwickelte Open-Source-Software ermöglicht es, komplexe Infrastrukturen in deklarativen Konfigurationsdateien zu beschreiben, die anschließend automatisch bereitgestellt werden. Dies reduziert manuelle Fehler, beschleunigt Deployments und schafft eine einheitliche Grundlage für Entwicklung, Test und Produktion.

Im Kern arbeitet Terraform mit einer zustandsbehafteten Architektur: Der gewünschte Zielzustand der Infrastruktur wird in HCL (HashiCorp Configuration Language) definiert, und die Engine gleicht diesen Soll-Zustand mit dem Ist-Zustand ab. Dadurch können Änderungen nachvollziehbar geplant und sicher angewendet werden, ohne dass bestehende Ressourcen unbeabsichtigt verändert oder gelöscht werden.

Die Stärke von Terraform liegt in der Anbieterunabhängigkeit. Über mehr als 3.000 offizielle und Community-Provider lassen sich nahezu alle gängigen Cloud-Plattformen, SaaS-Dienste und On-Premises-Systeme anbinden. Dies macht Terraform zur idealen Wahl für Multi-Cloud-Setups, hybride Umgebungen und komplexe Unternehmensarchitekturen, in denen Flexibilität und Portabilität entscheidend sind.

Die Grundlagen der HCL-Syntax

Die HashiCorp Configuration Language wurde speziell für die Beschreibung von Infrastruktur entwickelt und ist bewusst einfach gehalten. Sie unterstützt Variablen, Ausdrücke, Funktionen, Module und Blöcke, mit denen sich selbst umfangreiche Setups sauber strukturieren lassen. Durch die deklarative Natur müssen Anwender nicht den genauen Ablauf der Bereitstellung definieren, sondern lediglich das gewünschte Ergebnis.

Ein typ

Was ist Terraform und warum ist es 2026 unverzichtbar?

Terraform ist ein Open-Source-Tool von HashiCorp zur Definition und Bereitstellung von Infrastruktur durch deklarative Konfigurationsdateien. Mit der HashiCorp Configuration Language (HCL) beschreiben Administratoren den gewünschten Endzustand ihrer Rechenzentren, Cloud-Umgebungen oder Kubernetes-Cluster. Anstatt manuell Server, Netzwerke und Datenbanken anzulegen, übernimmt Terraform diese Aufgaben reproduzierbar und versionierbar.

Im Jahr 2026 hat sich Terraform als De-facto-Standard für Infrastructure as Code (IaC) etabliert. Die Vorteile gegenüber klassischem Click-Ops sind enorm: Kostenfreie Provisionierung, eine einzige Quelle der Wahrheit und die Möglichkeit, komplette Umgebungen in Sekunden zu klonen. Besonders in Kombination mit GitOps-Workflows entsteht ein durchgängiger Automatisierungs-Stack von der Code-IDE bis zur Produktivumgebung.

Hosting-Anbieter wie AWS, Azure, Google Cloud, Hetzner und DigitalOcean werden durch eigene Provider unterstützt. Auch selbstgehostete Lösungen wie Proxmox, OpenStack oder Kubernetes lassen sich problemlos verwalten. Die stetig wachsende Registry enthält mittlerweile über 3.500 offizielle und Community-Provider, sodass nahezu jede Zielumgebung abgedeckt wird.

Terraform vs. Ansible, Pulumi und CloudFormation

Während Terraform einen deklarativen Ansatz verfolgt, setzt Ansible auf einen prozeduralen Workflow. Ansible eignet sich hervorragend für Konfigurationsmanagement (Software installieren, Dienste starten), während Terraform die Infrastrukturebene adressiert. In der Praxis werden beide Tools häufig kombiniert: Terraform legt VMs an, Ansible konfiguriert sie anschließend.

Pulumi verfolgt einen ähnlichen Ansatz wie Terraform, nutzt jedoch allgemeine Programmiersprachen wie TypeScript, Python oder Go. Dies eröffnet Entwicklern mehr Flexibilität, ist aber für klassische Ops-Teams oft weniger zugänglich. CloudFormation ist auf AWS beschränkt und nutzt JSON oder YAML, was die Wiederverwendbarkeit einschränkt.

Die folgende Tabelle zeigt die wichtigsten Unterschiede auf einen Blick:

KriteriumTerraformAnsiblePulumiCloudFormation
SpracheHCLYAMLTypeScript, Python, GoJSON/YAML
Cloud-agnostischJaJaJaNein (nur AWS)
State-ManagementJaNeinJaJa
LizenzOpen Source (BUSL)Open Source (GPL)Open SourceProprietär
LernkurveMittelNiedrigHochMittel

Installation und erste Schritte mit Terraform

Die Installation von Terraform ist denkbar einfach. Unter Linux genügt es, das offizielle Binary herunterzuladen und in den PATH zu legen. Für produktive Setups empfiehlt sich die Nutzung von tfenv, einem Versionsmanager, der mehrere Terraform-Versionen parallel verwaltet.

Nach der Installation sollten Administratoren die Auto-Vervollständigung für ihre Shell einrichten. Terraform unterstützt Bash, Zsh, Fish und PowerShell. Ein einfacher terraform init im Projektverzeichnis lädt automatisch alle benötigten Provider herunter.

# Terraform via tfenv installieren
brew install tfenv
tfenv install 1.9.5
tfenv use 1.9.5

# Version prüfen
terraform version

# Auto-Completion für Bash
terraform -install-autocomplete

Eine erste Terraform-Konfiguration schreiben

Eine typische Terraform-Konfiguration besteht aus drei grundlegenden Blöcken: terraform (Versionseinstellungen), provider (Cloud-Anbindung) und resource (eigentliche Ressourcen). Im folgenden Beispiel erstellen wir eine einfache VM bei Hetzner Cloud.

Provider werden in der Regel über Environment-Variablen oder eine Provider-spezifische Konfigurationsdatei authentifiziert. Hetzner erwartet den API-Token in der Variable HCLOUD_TOKEN. Niemals sollten Tokens direkt in der Konfiguration stehen – stattdessen nutzt man Variablen oder einen Secret-Manager.

# main.tf
terraform {
  required_version = ">= 1.9.0"
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.45"
    }
  }
}

provider "hcloud" {
  token = var.hcloud_token
}

resource "hcloud_server" "web" {
  name        = "webserver-01"
  image       = "ubuntu-24.04"
  server_type = "cx22"
  location    = "fsn1"
  ssh_keys    = [hcloud_ssh_key.default.id]
}

resource "hcloud_ssh_key" "default" {
  name       = "default-key"
  public_key = file("~/.ssh/id_ed25519.pub")
}

variable "hcloud_token" {
  type      = string
  sensitive = true
}

Workflow: init, plan, apply, destroy

Der Terraform-Workflow folgt vier zentralen Befehlen. Mit terraform init wird das Arbeitsverzeichnis initialisiert und alle Provider geladen. terraform plan erstellt einen Ausführungsplan und zeigt an, welche Ressourcen erstellt, geändert oder gelöscht werden. terraform apply führt diesen Plan aus, und terraform destroy räumt alle verwalteten Ressourcen wieder auf.

Für den produktiven Einsatz empfiehlt es sich, den Plan in eine Datei zu schreiben und ihn durch ein zweites apply explizit anzuwenden. So können Teams den Plan in Pull-Requests reviewen, bevor Änderungen live gehen.

# Standard-Workflow
terraform init
terraform plan -out=tfplan
terraform apply tfplan

# Einzelne Ressource zerstören
terraform destroy -target=hcloud_server.web

# State aufräumen
terraform state list
terraform state show hcloud_server.web
terraform state rm hcloud_server.web

State-Management und Remote Backends

Der Terraform-State speichert den Zusammenhang zwischen Konfiguration und realer Infrastruktur. Wird der State lokal gespeichert, besteht die Gefahr von Inkonsistenzen, wenn mehrere Personen am selben Projekt arbeiten. Remote Backends lösen dieses Problem, indem sie den State zentral in einem Object-Storage (S3, Azure Blob, GCS) oder einem Terraform-Cloud-Workspace ablegen.

Zusätzlich sollte der State immer mit einem Locking-Mechanismus (z. B. DynamoDB, Azure Storage Lease) versehen sein, um parallele Schreibvorgänge zu verhindern. Viele Teams nutzen außerdem Terraform Cloud oder die OSS-Variante Atlantis für kollaborative Workflows.

BackendLockingVerschlüsselungKostenGeeignet für
S3 + DynamoDBJaJa (SSE-S3/KMS)NiedrigAWS-Setups
Azure StorageJa (Lease)JaNiedrigAzure-Setups
GCSJaJaNiedrigGCP-Setups
Terraform CloudJaJaFree Tier / ProMulti-Cloud
ConsulJaOptionalMittelSelf-Hosted

Module, Variablen und Best Practices

Terraform-Module sind wiederverwendbare Bausteine, die aus mehreren Ressourcen bestehen. Sie ermöglichen es, komplexe Setups zu kapseln und konsistent über Projekte hinweg zu nutzen. Die Terraform-Registry enthält tausende vorgefertigte Module – von VPCs bis zu kompletten Kubernetes-Clustern.

Bei der Modulentwicklung sollten folgende Best Practices beachtet werden:

# variables.tf
variable "server_type" {
  description = "Hetzner Server-Typ (z. B. cx22, cax21)"
  type        = string
  default     = "cx22"
}

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

variable "labels" {
  description = "Labels für die Ressourcen"
  type        = map(string)
  default     = {}
}

Sicherheit, Compliance und Kostenkontrolle

Bei der Nutzung von Terraform in produktiven Umgebungen spielen Sicherheit und Compliance eine zentrale Rolle. Tools wie tfsec, checkov oder terrascan analysieren den Code statisch und weisen auf Fehlkonfigurationen hin. Beispiele sind unverschlüsselte Storage-Buckets, öffentlich zugängliche Datenbanken oder fehlende Backup-Konfigurationen.

Für die Kostenkontrolle bieten sich Infracost und Cloud-Cost-Management-Tools an. Sie analysieren den Terraform-Plan und prognostizieren die monatlichen Kosten, bevor Ressourcen überhaupt erstellt werden. So lassen sich teure Fehlentscheidungen frühzeitig erkennen und vermeiden.

Ein weiterer wichtiger Aspekt ist die Secrets-Verwaltung. API-Tokens, Datenbank-Passwörter und private Keys sollten niemals im Klartext im Repository liegen. Stattdessen empfiehlt sich der Einsatz von HashiCorp Vault, AWS Secrets Manager oder Umgebungsvariablen in CI/CD-Pipelines.

Terraform 1.9 und Ausblick auf 2026

Mit Terraform 1.9 wurden zahlreiche Verbesserungen eingeführt, darunter ein überarbeitetes State-Management, verbesserte Performance bei großen Konfigurationen und erweiterte Import-Funktionen. Auch die Terraform Cloud-Plattform hat sich weiterentwickelt und bietet nun native Integrationen für Policy-as-Code (Sentinel, OPA) sowie ein verbessertes Drift-Detection.

Die Lizenzumstellung von MPL auf BUSL im Jahr 2023 hat zwar für Diskussionen gesorgt, doch die Community hat mit OpenTofu schnell eine echte Open-Source-Alternative geschaffen. Viele Provider und Module sind mittlerweile kompatibel zu beiden Tools, sodass Teams frei wählen können.

Wer 2026 in Infrastruktur investiert, kommt an Terraform oder OpenTofu kaum vorbei. Die Kombination aus Versionierung, Reproduzierbarkeit und Multi-Cloud-Fähigkeit macht es zum wichtigsten Werkzeug für DevOps- und Plattform-Teams. Hostazar-Kunden profitieren zusätzlich von Managed-Terraform-Workflows, die das Setup auf Hetzner, AWS und Co. deutlich vereinfachen.

DevOps-Tools 2024 – Die 10 wichtigsten Tools im Überblick
DevOps 12. May 2025 7 Min

DevOps-Tools 2024 – Die 10 wichtigsten Tools im Überblick

Die wichtigsten DevOps-Tools 2024: Docker, Kubernetes, Terraform, Ansible, GitHub Actions und mehr. Mit Hosting-Tipps für deine DevOps-Infrastruktur.

Weiterlesen →

📖 Ähnliche Artikel