Terraform · OpenTofu · S3 Backend

Terraform Remote State im S3 Backend — RZ Frankfurt

Ihr terraform.tfstate gehört nicht in die US-Cloud. Nutzen Sie den deutschen S3-kompatiblen Endpoint https://de-fra.i3storage.com (Region de-fra) als Backend — mit nativem State-Locking über use_lockfile, ganz ohne DynamoDB. DSGVO/AVV, SigV4, ab 2,49 €/TB.

Kostenlos testen Kontaktieren Sie uns direkt

hcl — backend.tf

terraform {
  backend "s3" {
    bucket       = "tf-state"
    key          = "prod/terraform.tfstate"
    region       = "de-fra"
    endpoints    = { s3 = "https://de-fra.i3storage.com" }
    use_lockfile = true   # natives S3-State-Locking, kein DynamoDB
    skip_credentials_validation = true
    skip_requesting_account_id  = true
    skip_region_validation      = true
  }
}

S3 Backend

SigV4

Natives Locking

ohne DynamoDB

DSGVO / AVV

RZ Frankfurt

Für DevOps & Platform-Engineers

Remote State mit Locking — ohne Ihren State in die US-Cloud zu legen

Ein lokales terraform.tfstate auf dem Laptop skaliert nicht: Sobald zwei Kolleginnen dieselbe Infrastruktur anfassen, driftet der State auseinander, ein paralleles terraform apply zerschießt die Datei, und niemand hat die aktuelle Quelle der Wahrheit. Remote State löst das — eine geteilte, zentrale Statedatei plus Locking, das einen zweiten Lauf blockiert, statt den State zu korrumpieren. Das Problem: In den meisten Anleitungen landet genau dieser sensible State in einem AWS-S3-Bucket in den USA. intercolo i3 ist das S3-kompatible Backend in Deutschland: strong read-after-write, angesprochen über den Endpoint https://de-fra.i3storage.com in der Region de-fra, mit nativem Locking über use_lockfile (Terraform 1.10+ / OpenTofu 1.8+) — ohne DynamoDB, DSGVO/AVV, 99,999999% Durability und Daten, die das RZ Frankfurt nie verlassen.

backend.tf — der S3-Backend-Block

hcl

terraform {
  backend "s3" {
    bucket       = "tf-state"
    key          = "prod/terraform.tfstate"
    region       = "de-fra"
    endpoints    = { s3 = "https://de-fra.i3storage.com" }
    use_lockfile = true   # natives S3-State-Locking, kein DynamoDB
    skip_credentials_validation = true
    skip_requesting_account_id  = true
    skip_region_validation      = true
  }
}

endpoints = { s3 = ... } richtet das Backend auf de-fra.i3storage.com statt AWS. Die drei skip_-Flags sind bei einem Nicht-AWS-Endpoint Pflicht: skip_credentials_validation überspringt den AWS-STS-Check, skip_requesting_account_id die IAM-Account-Abfrage, skip_region_validation die Prüfung gegen die AWS-Regionsliste (de-fra ist keine AWS-Region). use_lockfile = true aktiviert das native Locking. Zugangsdaten kommen aus den Umgebungsvariablen AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (Ihr SigV4-Schlüsselpaar).

Locking ohne Zusatzdienst

Natives S3-State-Locking statt DynamoDB-Tabelle

Klassisch brauchte das AWS-S3-Backend eine separate DynamoDB-Tabelle (dynamodb_table) als Lock — ohne sie konnten zwei gleichzeitige Läufe den State zerstören. Seit Terraform 1.10 und OpenTofu 1.8 gibt es use_lockfile = true: Das Backend legt vor jedem schreibenden Lauf ein .tflock-Objekt direkt neben der Statedatei an — über bedingte S3-Schreibvorgänge (If-None-Match), die genau einen Schreiber gewinnen lassen. Kein zweiter Dienst, keine zusätzliche Rechnung, keine extra IAM-Policy für DynamoDB. intercolo i3 unterstützt diese Conditional Writes, also greift das Lock sauber für Ihr ganzes Team. Ein Backend-Block, fertig — der zweite apply wartet oder bricht mit Lock-Fehler ab, statt den State zu überschreiben.

In 4 Schritten zum Remote State in Frankfurt

Bucket & API-Key anlegen

Legen Sie einen Bucket an (z. B. tf-state) — per Web-Konsole, aws-cli oder rclone gegen https://de-fra.i3storage.com. Erzeugen Sie ein SigV4-API-Schlüsselpaar (Access/Secret). Für saubere Trennung nehmen Sie pro Umgebung (dev/stage/prod) ein eigenes Schlüsselpaar und idealerweise einen eigenen Bucket.

backend.tf schreiben

Fügen Sie den terraform { backend "s3" { ... } }-Block aus dem Beispiel ein: bucket, key, region = de-fra, endpoints = { s3 = "https://de-fra.i3storage.com" }, use_lockfile = true und die drei skip_-Flags. Exportieren Sie AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY mit Ihren SigV4-Schlüsseln (nicht in den Code committen).

terraform init -migrate-state

Führen Sie terraform init -migrate-state aus (bei neuen Projekten genügt terraform init). Terraform kopiert Ihr vorhandenes lokales terraform.tfstate in den Bucket und bestätigt die Migration. Danach die lokale Statedatei löschen oder sicher archivieren — sie ist ab jetzt nur noch remote maßgeblich.

terraform plan mit Lockfile

Ab jetzt zieht jeder terraform plan / apply vor dem Schreiben das .tflock-Lock und gibt es danach wieder frei. Ein zweiter, gleichzeitig laufender apply blockiert mit einem Lock-Fehler, statt den State zu beschädigen. Prüfen Sie mit terraform plan, dass keine Änderungen anstehen — dann liegt Ihr State sauber in Frankfurt.

State kann Secrets enthalten — halten Sie ihn sauber

Ehrlich und wichtig: Ein terraform.tfstate kann Klartext-Werte enthalten — DB-Passwörter, API-Tokens, generierte Schlüssel. Es gibt KEINE storage-seitige Verschlüsselung at-Rest, nur TLS auf dem Transport. Halten Sie Secrets deshalb möglichst aus dem State heraus: Referenzieren Sie sie über einen Secret-Manager oder HashiCorp Vault (data-Sources statt Klartext-Ressourcen), statt sie in Ressourcen zu schreiben, die im State landen. Wo ein Provider Werte zwingend persistiert, verschlüsseln Sie den State clientseitig, bevor er das Backend erreicht — OpenTofu 1.7+ kann State und Plan nativ clientseitig verschlüsseln, mit Terraform bietet sich ein SOPS/age-Workflow in der Pipeline an. Der Zugriff läuft ausschließlich über SigV4-API-Keys per TLS — kein öffentlicher Bucket. Nutzen Sie getrennte Schlüssel und Buckets pro Umgebung, damit ein geleakter Schlüssel einen kleinen Wirkungsradius hat.

Als Terraform-Backend: AWS S3 vs. Wasabi vs. intercolo i3

	AWS S3 + DynamoDB	Wasabi	intercolo i3
Standort / Datenhoheit	US-Cloud, CLOUD Act	EU-Region wählbar, US-Konzern	RZ Frankfurt, 100% DE, DSGVO/AVV
Endpoint	s3.<region>.amazonaws.com	s3.<region>.wasabisys.com	https://de-fra.i3storage.com (de-fra)
State-Locking	DynamoDB (klassisch) oder use_lockfile	abhängig vom Conditional-Write-Support	natives use_lockfile (Conditional Writes)
Zusätzlicher Dienst nötig	DynamoDB-Tabelle (klassisch)	keiner	keiner
Egress-Modell	pro GB, plus Anfragekosten	'kostenlos' bis Speichermenge, dann gedrosselt	1 TB inkl./TB, dann +3,99 €/TB
Verschlüsselung at-Rest	SSE-S3 / KMS verfügbar	SSE verfügbar	Nein — clientseitig (OpenTofu/SOPS), TLS-Transport
Support / Ansprechpartner	Ticket, EN	Ticket, EN	Direkt, deutsch, RZ-Team

Umzug aus der US-Cloud

Von AWS S3 migrieren: nur endpoints und region tauschen

Wer bereits das AWS-S3-Backend nutzt, migriert mit minimalem Diff: Im bestehenden backend "s3"-Block setzen Sie region = "de-fra", ergänzen endpoints = { s3 = "https://de-fra.i3storage.com" } sowie die drei skip_-Flags und use_lockfile = true — und entfernen die alte Zeile dynamodb_table. AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY zeigen Sie auf Ihre intercolo-SigV4-Schlüssel. Ein terraform init -migrate-state kopiert den State aus AWS in den Frankfurter Bucket. Ihre Ressourcen, Module und Provider bleiben unangetastet — es zieht nur der State um. Zur Kontrolle zeigt terraform plan danach keine Änderungen an.

Passt in Ihren bestehenden Workflow

Terraform & OpenTofu

Funktioniert mit HashiCorp Terraform 1.10+ (use_lockfile) und OpenTofu 1.8+ — derselbe Backend-Block für beide. OpenTofu bringt zusätzlich native, clientseitige State- und Plan-Verschlüsselung (ab 1.7) mit, falls Sie den State verschlüsselt ablegen wollen.

CI/CD-Pipelines

In GitLab CI, GitHub Actions, Atlantis oder Jenkins hinterlegen Sie AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (SigV4) und region = de-fra als geschützte Variablen. Das native Lock serialisiert parallele Pipeline-Läufe — zwei Merge Requests können nicht gleichzeitig applyen.

Workspaces & Umgebungen

Trennen Sie dev/stage/prod über Terraform-Workspaces oder eigene key-Prefixe (env:/prod/...) — in einem oder mehreren Buckets. Kombiniert mit je eigenem SigV4-Schlüsselpaar pro Umgebung bleibt jeder State organisatorisch und schlüsseltechnisch isoliert.

Strong Read-after-Write

Nach dem apply liefert der nächste Lesezugriff sofort den aktuellen State — strong read-after-write-Konsistenz. Keine veralteten Statedateien, keine Races zwischen unmittelbar aufeinanderfolgenden Läufen, wie sie eventually-consistente Speicher provozieren.

Storage Migration Service

Wir migrieren Ihre Daten für Sie

Unsere Erfahrung spricht für sich: Wir haben bereits erfolgreich Migrationen mit mehreren Petabyte an Daten und über 500 Millionen Dateien durchgeführt.

500 Mio.+

migrierte Dateien

Petabyte

Datenvolumen migriert

seit 2006

am Markt

Kontaktieren Sie uns

FAQ

Noch Fragen?

Kontaktieren Sie uns direkt

Brauche ich noch eine DynamoDB-Tabelle für das Locking?

Nein. Mit use_lockfile = true übernimmt das S3-Backend das Locking selbst über ein .tflock-Objekt und bedingte S3-Schreibvorgänge. Die alte dynamodb_table-Zeile entfällt komplett — kein zweiter Dienst, keine zusätzliche Rechnung. intercolo i3 unterstützt die dafür nötigen Conditional Writes.

Welche Terraform- oder OpenTofu-Version brauche ich?

Das native use_lockfile-Locking gibt es ab HashiCorp Terraform 1.10 und ab OpenTofu 1.8. Ältere Versionen brauchen weiterhin die DynamoDB-basierte Sperre. Der endpoints = { s3 = ... }-Block ist die moderne Schreibweise und ersetzt das frühere, veraltete endpoint-Feld.

Wozu die drei skip_-Flags?

Weil de-fra.i3storage.com ein Nicht-AWS-Endpoint ist. skip_credentials_validation überspringt den AWS-STS-Check, skip_requesting_account_id die IAM-Account-Abfrage und skip_region_validation die Prüfung gegen die AWS-Regionsliste (de-fra ist keine AWS-Region). Ohne diese Flags würde der init-Lauf gegen AWS-spezifische Prüfungen fehlschlagen.

Ist mein State im Object Storage verschlüsselt?

Storage-seitig gibt es keine Verschlüsselung at-Rest; der Transport läuft per TLS. Da ein State Klartext-Secrets enthalten kann, halten Sie Secrets über einen Secret-Manager/Vault möglichst aus dem State heraus. Für Verschlüsselung des States selbst nutzen Sie die clientseitige State-Verschlüsselung von OpenTofu 1.7+ oder einen SOPS/age-Workflow in der Pipeline.

Wie migriere ich vom AWS-S3-Backend?

Im bestehenden backend "s3"-Block region auf de-fra setzen, endpoints = { s3 = "https://de-fra.i3storage.com" }, die skip_-Flags und use_lockfile = true ergänzen, dynamodb_table entfernen und die Schlüssel auf Ihr SigV4-Paar zeigen. Dann kopiert terraform init -migrate-state den State nach Frankfurt. Ressourcen und Module bleiben unverändert.

Path-Style oder Virtual-Hosted — was nutzt das Backend?

Beides ist möglich: Path-Style https://de-fra.i3storage.com/<bucket> und Virtual-Hosted https://<bucket>.de-fra.i3storage.com. Für den terraform s3-Backend genügt endpoints = { s3 = "https://de-fra.i3storage.com" } mit region = de-fra; bei Bedarf lässt sich das Adressierungsverhalten über use_path_style steuern.

Wie trenne ich mehrere Umgebungen oder Teams sauber?

Über getrennte key-Prefixe oder Terraform-Workspaces plus je ein eigenes SigV4-Schlüsselpaar und idealerweise einen eigenen Bucket pro Umgebung (dev/stage/prod). So bleibt jeder State isoliert, das native Lock verhindert parallele Läufe je State, und der Wirkungsradius eines kompromittierten Schlüssels bleibt klein.

Wir verwenden Cookies

Notwendig Immer aktiv

Präferenzen

Analytik

Marketing

Notwendig