DevOps 7 Min Lesezeit

Ansible vs. Terraform 2026 – Wann welches Tool?

Ansible vs. Terraform – der Dauerbrenner im DevOps-Alltag

Kaum eine Frage taucht in DevOps-Teams so zuverlässig auf wie diese: „Nehmen wir jetzt Ansible oder Terraform?" Die ehrliche Antwort lautet in den meisten Fällen: beides – aber nicht für dieselbe Aufgabe. Terraform ist ein Provisioning-Tool, Ansible ein Configuration-Management-Tool. Wer das verwechselt, baut sich entweder einen unwartbaren Terraform-State oder Playbooks, die verzweifelt versuchen, Cloud-Ressourcen zu erfinden.

2026 ist die Lage klarer als noch vor drei Jahren. Terraform hat mit OpenTofu einen ernstzunehmenden Fork unter dem Dach der Linux Foundation, HashiCorp hat die BUSL-Lizenz beibehalten, und Ansible ist mit ansible-core 2.20 sowie Event-Driven Ansible erwachsen geworden. Gleichzeitig sind Managed-Service-Preise deutlich gestiegen, was Self-Hosting und damit beide Tools wieder attraktiver macht.

Dieser Guide zeigt dir mit konkreten Befehlen, Preisen und Codebeispielen, wann welches Tool die richtige Wahl ist – und wie du sie sauber kombinierst. Zielgruppe sind Server-Admins, DevOps-Engineers und alle, die 2026 Infrastruktur reproduzierbar betreiben wollen.

Die Kernfrage: Provisioning vs. Configuration Management

Terraform beschreibt den gewünschten Endzustand von Infrastruktur: fünf VMs, ein Load Balancer, ein Managed-Postgres, drei Subnetze. Es kennt den State, vergleicht ihn mit der Realität und leitet daraus einen Plan ab. Terraform weiß, dass eine VM existiert, und löscht sie wieder, wenn du sie aus dem Code entfernst.

Ansible beschreibt dagegen den gewünschten Zustand eines Systems: nginx installiert, UFW aktiv, SSH-Port 2222, ein Deploy-User vorhanden. Ansible ist zustandslos – es gibt keinen State-File, der die Welt abbildet. Stattdessen fragt jedes Modul beim Ausführen nach, ob der Zielzustand bereits erreicht ist (Idempotenz).

Daraus folgt die Faustregel, die 2026 unverändert gilt: Terraform für Dinge, die eine API mit Lebenszyklus haben. Ansible für Dinge, die man per SSH konfiguriert. Ein AWS-S3-Bucket hat einen Lebenszyklus, eine /etc/ssh/sshd_config nicht.

Es gibt Grauzonen: Kubernetes-Manifeste, DNS-Einträge, Cloudflare-Regeln. Hier entscheidet nicht die Technik, sondern die Frage, ob du einen Plan-Diff und eine Löschsemantik brauchst. Wenn ja, ist Terraform fast immer die bessere Wahl.

Terraform 2026: Versionen, OpenTofu und der Lizenzstreit

HashiCorp Terraform steht seit August 2023 unter der Business Source License 1.1. Für die meisten Unternehmen ist das unproblematisch, weil die Lizenz nur konkurrierende Commercial-Angebote einschränkt. Wer Terraform jedoch in ein eigenes SaaS-Produkt einbettet, braucht eine kommerzielle Vereinbarung.

Die aktuelle Terraform-Linie liegt 2026 bei 1.12.x. Wichtige Features der letzten Releases: Ephemeral Resources (seit 1.10), mit denen Passwörter und Tokens nie im State landen, Write-only Arguments (1.11) für Secrets in AWS- und Azure-Providern sowie ein deutlich ausgebautes terraform test-Framework mit nativen Testdateien (.tftest.hcl).

OpenTofu hat als Fork unter der MPL-2.0-Lizenz stark aufgeholt und liegt bei Version 1.10.x. Der entscheidende Vorteil: native State-Locking-Unterstützung in S3 ohne DynamoDB-Tabelle über use_lockfile = true, plus Provider-Verschlüsselung des States auf Client-Seite. Wer aus Compliance-Gründen keine BUSL-Software einsetzen darf, fährt mit OpenTofu inzwischen ohne nennenswerte Abstriche.

terraform {
  required_version = ">= 1.10"

  backend "s3" {
    bucket       = "hostazar-tfstate"
    key          = "prod/network/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

Migration zwischen Terraform und OpenTofu ist in beide Richtungen möglich, weil das State-Format kompatibel bleibt. Ein tofu init -upgrade beziehungsweise terraform init -upgrade genügt in der Regel.

Ansible 2026: ansible-core 2.20 und Event-Driven Automation

Ansible hat sich organisatorisch in zwei Teile gespalten: ansible-core (Engine, Module, CLI) und die Ansible Community Package mit über 120 Collections. ansible-core 2.20 benötigt Python 3.11 oder neuer auf dem Controller und unterstützt Zielsysteme ab Python 3.8 – inklusive Windows über WinRM und Netzwerkgeräte über network_cli.

Der größte Wandel der letzten Jahre ist Event-Driven Ansible (EDA). Statt Playbooks manuell oder per Cron zu starten, reagiert Ansible auf Events: ein Webhook aus Prometheus Alertmanager, eine Kafka-Message, ein Syslog-Eintrag. Rulebooks definieren Bedingungen und Aktionen in YAML.

- name: Auto-Remediate hohe Last
  hosts: all
  sources:
    - ansible.eda.alertmanager:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: nginx neu starten
      condition: event.alert.labels.alertname == "NginxDown"
      action:
        run_playbook:
          name: playbooks/restart-nginx.yml

Für die tägliche Arbeit relevanter: ansible-lint ist 2026 Pflicht in der CI, Molecule testet Rollen in Containern, und Collections haben die alten Galaxy-Rollen fast vollständig abgelöst. Das Inventory kommt dynamisch aus Plugins – etwa hetzner.hcloud.hcloud, amazon.aws.aws_ec2 oder community.general.proxmox.

Entscheidungsmatrix: Wann Terraform, wann Ansible?

Die folgende Matrix hat sich in der Praxis bewährt. Sie ersetzt keine Architekturentscheidung, aber sie beantwortet 90 Prozent aller Fälle in unter einer Minute.

Aufgabe	Terraform	Ansible
VMs, Netzwerke, Subnetze anlegen	Ja	Nein
Managed DB, S3, IAM, DNS	Ja	Nein
Pakete installieren, Dienste konfigurieren	Nein	Ja
OS-Patching, Härtung, CIS-Benchmarks	Nein	Ja
App-Deployment auf bestehende Server	Nein	Ja
Kubernetes-Cluster-Infrastruktur	Ja	Bedingt
Kubernetes-Workloads	Nein	Nein (Helm/Argo)
Löschsemantik / Drift-Erkennung	Ja	Nein
Netzwerkgeräte (Cisco, Juniper)	Nein	Ja

Ein häufiger Denkfehler: „Wir haben schon Ansible, also machen wir alles mit Ansible." Das führt zu Playbooks mit amazon.aws.ec2_instance, die nicht idempotent sind, keinen Plan kennen und beim Löschen scheitern. Umgekehrt gilt: Terraform-remote-exec-Provisioner für Paketinstallation sind ein Anti-Pattern, weil sie nur beim Erstellen laufen und bei Änderungen nicht erneut feuern.

Direktvergleich in Zahlen

Beide Tools sind in Go beziehungsweise Python geschrieben und laufen auf Linux, macOS und Windows (WSL). Die Unterschiede liegen im Ausführungsmodell.

Kriterium	Terraform 1.12	Ansible Core 2.20
Paradigma	deklarativ, State-basiert	prozedural, zustandslos
Sprache	HCL	YAML
Agent	keiner (API-Calls)	keiner (SSH/WinRM)
Reihenfolge	Graph, parallel	linear, `serial` steuerbar
Drift-Erkennung	`terraform plan`	`--check` (partiell)
Rollback	State-Rollback möglich	kein Rollback
Lizenz	BUSL 1.1 (OpenTofu: MPL-2.0)	GPL-3.0
Einstiegshürde	mittel	niedrig
Typische Ausführungszeit	Sekunden bis Minuten	Sekunden bis Stunden

Wichtig für die Praxis: Terraform arbeitet parallel über den Dependency-Graph und schafft 200 Ressourcen in unter zwei Minuten. Ansible arbeitet pro Host linear durch Tasks; bei 500 Hosts und 40 Tasks dauert ein Full-Run schnell 25 bis 45 Minuten. Mit strategy: free und forks = 50 in der ansible.cfg lässt sich das deutlich verkürzen.

Praxis: Infrastruktur mit Terraform provisionieren

Ein realistisches Setup bei Hetzner Cloud: drei Webserver, ein Load Balancer, ein privates Netz. Der Code ist überschaubar und in 15 Minuten geschrieben.

resource "hcloud_network" "main" {
  name     = "prod-net"
  ip_range = "10.0.0.0/16"
}

resource "hcloud_server" "web" {
  count       = 3
  name        = "web-${count.index + 1}"
  image       = "ubuntu-24.04"
  server_type = "ccx13"        # 2 vCPU dediziert, 8 GB RAM, 12,49 €/Monat
  location    = "fsn1"
  ssh_keys    = [hcloud_ssh_key.default.id]
  network_id  = hcloud_network.main.id

  labels = { role = "web", env = "prod" }
}

Der Workflow ist immer derselbe: terraform init lädt Provider, terraform plan -out=tfplan zeigt den Diff, terraform apply tfplan führt aus. Der Plan ist das eigentliche Killer-Feature – du siehst vorher, dass drei Server ersetzt und zwei nur neu getaggt werden.

Für Secrets nutzt du 2026 ephemeral-Blöcke oder einen Vault-Provider. Alles, was im State landet, ist im Klartext lesbar, sofern du die Backend-Verschlüsselung nicht aktiviert hast. Bei OpenTofu kannst du den State zusätzlich client-seitig mit PBKDF2 und AES-GCM verschlüsseln.

terraform init
terraform plan -out=tfplan -var-file=prod.tfvars
terraform apply tfplan
terraform output -json server_ips > inventory.json

Praxis: Server konfigurieren mit Ansible

Nach dem Provisioning übernimmt Ansible. Das Inventory kommt dynamisch aus dem Hetzner-Plugin, gruppiert nach Label.

# inventory/hcloud.yml
plugin: hetzner.hcloud.hcloud
token: "{{ lookup('env', 'HCLOUD_TOKEN') }}"
groups:
  web: "'web' in labels.role"
  prod: "'prod' in labels.env"

Eine Rolle für nginx plus Härtung sieht dann so aus:

- hosts: web
  become: true
  serial: 1
  roles:
    - role: common
    - role: nginx
    - role: hardening

# roles/hardening/tasks/main.yml
- name: SSH-Port ändern
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^#?Port'
    line: 'Port 2222'
  notify: sshd neu starten

- name: UFW aktivieren
  community.general.ufw:
    state: enabled
    policy: deny
    direction: incoming

Aufruf mit ansible-playbook -i inventory/hcloud.yml site.yml --limit prod. Der serial: 1-Parameter sorgt für Rolling Updates: ein Server nach dem anderen, dazwischen kann ein Health-Check im Load Balancer greifen.

Für Idempotenz-Checks in der CI läuft ansible-playbook --check --diff gegen eine Staging-Umgebung. Ergänzend prüft ansible-lint --profile production auf Anti-Patterns wie shell statt command oder fehlende changed_when-Angaben.

Terraform + Ansible kombinieren – drei bewährte Muster

Muster 1: Terraform provisioniert, Ansible konfiguriert. Terraform legt die VMs an und schreibt die IPs via terraform output -json in ein Inventory. Ein CI-Job ruft danach ansible-playbook auf. Das ist der Standard und für 80 Prozent aller Setups ausreichend.

Muster 2: cloud-init als Brücke. Terraform übergibt ein user_data-Skript, das den Server bootstrappt: Nutzer anlegen, SSH-Key hinterlegen, Python installieren. Danach übernimmt Ansible. Vorteil: Der Server ist in 30 Sekunden erreichbar, nicht erst nach einem manuellen Ansible-Lauf.

resource "hcloud_server" "web" {
  # ...
  user_data = templatefile("cloud-init.yaml", {
    ansible_user = "deploy"
    ssh_key      = tls_private_key.deploy.public_key_openssh
  })
}

Muster 3: Ansible ruft Terraform auf. Ein Playbook mit community.general.terraform steuert Terraform-Workspaces. Davon ist abzuraten, außer für Demo-Umgebungen: Du verlierst die Plan-Review im Pull Request und verschachtelst zwei Fehlerquellen ineinander.

Ebenfalls sinnvoll: Ansible für Day-2-Operationen auf Clustern, die Terraform gebaut hat – etwa Zertifikate erneuern, Logrotate anpassen, Kernel-Parameter setzen. Terraform bleibt der Single Source of Truth für die Existenz der Ressource, Ansible für ihren Inhalt.

Kosten und Lizenzen 2026

Die CLI beider Tools ist kostenlos. Teuer wird es bei den Managed-Plattformen.

Produkt	Preis (Listenpreis)	Enthalten
HCP Terraform Free	0 €	500 Ressourcen, 1 Concurrent Run
HCP Terraform Standard	20 $/User/Monat + 0,00014 $/Ressource/Std.	Remote State, Policy as Code
Terraform Enterprise	ab ca. 70.000 $/Jahr	Self-hosted, SSO, Audit
OpenTofu	0 €	Alles, inkl. State-Verschlüsselung
Ansible Core / Community	0 €	Engine + 120 Collections
Red Hat AAP	ab ca. 100 €/Node/Jahr	Controller, EDA, Automation Hub
AWX (Upstream)	0 €	Web-UI, RBAC, Scheduling

Ein Beispiel: 200 Managed Nodes mit AAP kosten bei 100 € pro Node rund 20.000 € pro Jahr. Wer nur die CLI braucht, fährt mit AWX in einem Container auf einem 12,49-€-Hetzner-CCX13 deutlich günstiger – dafür ohne Support-SLA und mit eigenem Upgrade-Aufwand.

Auf der Terraform-Seite ist der Kostenhebel der State. 400 Ressourcen in HCP Terraform Standard kosten rechnerisch etwa 400 × 0,00014 $ × 730 h ≈ 41 $/Monat plus User-Lizenzen. Ein S3-Bucket mit Versioning kostet dagegen unter 1 $/Monat.

Typische Fehler und Best Practices

Fehler 1: State im Git. Der Terraform-State enthält Klartext-Secrets. Er gehört in ein Remote-Backend mit Versioning und Locking – niemals ins Repository. .gitignore mit *.tfstate* ist Pflicht.

Fehler 2: shell-Modul statt command. shell ist nie idempotent, weil die Shell immer 0 zurückgibt. Nutze command mit creates: oder changed_when: false für Read-only-Aufrufe.

Fehler 3: Monolithische States. Ein State für die gesamte Firma bedeutet, dass ein plan 15 Minuten dauert und jeder Fehler alles blockiert. Teile nach Lebenszyklus auf: Netzwerk, Datenbank, App. Verbinde sie über terraform_remote_state oder besser über Datenquellen.

Fehler 4: Keine Tests. Terraform hat terraform test mit nativen Testdateien, Ansible hat Molecule und --check. Beides gehört in die CI, bevor irgendetwas gegen Produktion läuft.

Best Practices 2026: Module versionieren statt Branches referenzieren, Secrets über Vault oder SOPS statt tfvars, terraform fmt -check und ansible-lint als Pflicht-Gates im Pull Request, und für jede Umgebung ein eigener State mit eigener Backend-Config.

FAQ

Kann ich Terraform komplett durch Ansible ersetzen?

Technisch ja, praktisch nein. Ansible hat Module für AWS, Azure und GCP, aber keinen State und keinen Plan-Diff. Du verlierst Drift-Erkennung, Löschsemantik und die Möglichkeit, vor dem Apply zu sehen, was passiert. Für kleine Setups mit unter 20 Ressourcen kann das reichen, ab etwa 50 Ressourcen wird es unwartbar.

Kann ich Ansible komplett durch Terraform ersetzen?

Nein. Terraform hat keine sinnvolle Möglichkeit, Pakete zu installieren, Dienste zu konfigurieren oder Konfigurationsdateien idempotent zu verwalten. Die remote-exec-Provisioner laufen nur beim Erstellen und sind für laufende Konfiguration ungeeignet. Für OS-Konfiguration bleibt Ansible (oder ein anderes Config-Management-Tool) die richtige Wahl.

Sollte ich 2026 Terraform oder OpenTofu nehmen?

Wenn du keine BUSL-Software einsetzen darfst oder Wert auf client-seitige State-Verschlüsselung und natives S3-Locking legst: OpenTofu. Wenn du HCP Terraform, Terraform Enterprise oder die breitere Provider- und Modul-Ökosystem-Unterstützung brauchst: Terraform. Die State-Dateien sind kompatibel, ein Wechsel ist jederzeit möglich.

Wie viele Ressourcen schafft ein Terraform-Apply pro Minute?

Bei API-limitierten Providern wie AWS sind 10 bis 30 Ressourcen pro Minute realistisch, weil der Provider parallele Calls auf 10 begrenzt (-parallelism). Bei Hetzner Cloud oder Proxmox sind 50 bis 100 Ressourcen pro Minute üblich. Netzwerk-Ressourcen sind schneller als Compute-Ressourcen.

Was kostet der Betrieb beider Tools im Self-Hosting?

Ein Hetzner CCX13 mit 2 dedizierten vCPU und 8 GB RAM kostet 12,49 €/Monat und reicht für AWX plus einen OpenTofu-Runner. Rechne mit 2 bis 4 Stunden Setup und etwa einer Stunde Wartung pro Monat. Gegenüber AAP mit rund 100 €/Node/Jahr amortisiert sich das ab etwa 20 Managed Nodes.