Terraform @Scale - Teil 2: Die Kunst der optimalen State-Größe

Infrastructure-as-Code ist längst nicht mehr optional. Unternehmen, die ihre Cloud-Infrastruktur ernsthaft betreiben und skalieren wollen, setzen auf Terraform. Doch mit wachsendem Erfolg und steigender Komplexität stellt sich eine entscheidende Frage: Wie groß oder klein darf ein Terraform State eigentlich sein?

Ein zu großer State blockiert Teams, verlangsamt Prozesse und erzeugt unnötiges Risiko. Ein zu kleiner hingegen führt zu unnötigem Overhead und brüchiger Konsistenz. Es geht also darum, das richtige Maß zu finden – nicht zu viel, nicht zu wenig, sondern genau richtig. Willkommen beim Goldilocks-Prinzip für Terraform.

 

Das Goldilocks-Prinzip in der IaC-Welt

Das sogenannte Goldlöckchen-Prinzip stammt ursprünglich aus einem englischen Märchen. Die Hauptfigur, Goldlöckchen, probiert verschiedene Optionen – etwa zu heiß, zu kalt und dann genau richtig – und entscheidet sich am Ende für die mittlere Lösung. Genau dieses Bild lässt sich wunderbar auf die Welt von Terraform übertragen.

Auch hier suchen wir nach dem idealen Gleichgewicht. Ziel ist ein Setup, das weder zu granular noch zu monolithisch ist. Drei zentrale Ziele stehen dabei im Fokus:

1. Maximale Effizienz bei der Bereitstellung und Verwaltung von Infrastruktur
2. Vermeidung überflüssiger Redundanz, wie sie in zu großen States oft vorkommt
3. Vermeidung unvollständiger Zustände, wie sie durch übermäßige Fragmentierung entstehen

In der Praxis bedeutet das: Wir brauchen eine Struktur, die sowohl Teams die nötige Unabhängigkeit gewährt als auch einen konsistenten Überblick über das Gesamtsystem ermöglicht.

 

Die Herausforderung der richtigen State-Dimensionierung

Die Frage nach der "richtigen" Größe eines Terraform States stellt sich früher oder später in jeder größeren Umgebung. Dabei gibt es kein allgemeingültiges Rezept – was funktioniert, hängt stark vom konkreten Use Case ab, und dieser ist stets individuell für jedes Kundenbedürfnis.

Dennoch lassen sich nach mehreren Projekten für diverse Kunden typische Herausforderungen klar erkennen.

Was passiert, wenn States zu groß werden?

Große Terraform States wirken auf den ersten Blick attraktiv: Alles ist an einem Ort, leicht zu versionieren, übersichtlich.... das Rechenzentrum auf Knopfdruck, Traum vieler Manager und Entscheider,  scheint durch Terraform realisierbar.  Ich spreche hier aus Erfahrung, denn als ich persönlich vor einem knappen Jahrzehnt mit Terraform begonnen habe, bin ich selbst auch in diese Falle getappt. Ja, es sieht toll aus und hinterlässt Eindruck, viele Problemen erscheinen als gelöst. Aber dieser Eindruck trügt. Denn die Realität zeigt schnell ein anderes Bild.

Schnell treten auf:

• Performance-Probleme: terraform plan oder apply dauern ewig, weil große States viel Rechenzeit und Netzwerkbandbreite verschlingen. Das Größte, was mir hier bisher begenet ist, war ein terraform apply, der neben Netzwerken und VMs auch noch einen kompletten Oracle-Datenbankencluster mitinstallieren wollte und im Bestfall nach 75 Minuten fertig war. Das war der Inbegriff eines Anfängerfehlers. 
• Blockierende Locks: Wenn mehrere Teams oder Mitarbeiter am gleichen State arbeiten, kommt es zu Konflikten und Wartezeiten. Die Folge sind meistens Frust, laute Unmutsäußerungen und Produktivitätsverlust.
• Komplexes Risikomanagement: Fehler in einem Modul können Auswirkungen auf weite Teile der Infrastruktur haben. Das ist besonders kritisch in produktiven Umgebungen. Je mehr Ressourcen ein Terraform-Modul zu implementieren versucht, desto größer wird der Blast Radius, wenn etwas schiefgeht. Auch bei Terraform gilt die alte Faustregel aus dem Betrieb: Je komplexer etwas ist, desto schneller und lauter knallt es.
• Verlangsamte Entwicklungszyklen: Änderungen brauchen länger, Time-to-Market steigt und Continuous Delivery wird zur Herausforderung. Die Feedback-Lopps sollen mögliset kurz sein. 60 Minuten für einen Versuch, eine Infrastruktur auszurollen, sind nicht kurz.

Und wenn States zu klein sind?

Das andere Extrem ist ebenso problematisch. Wer die Infrastruktur in zu viele kleine States zerlegt, bekommt schnell ein andere Kiste voller Scherben:

• Verwaltungsaufwand: Dutzende oder hunderte von States müssen gepflegt, versioniert und koordiniert werden. Das frisst Zeit und erzeugt Komplexität. Im schlimmsten Fall wird aus Komplexität sogar Kompliziertheit und dann steigt niemand mehr durch. Das Letzte, was sie mit Infrastructure-as-Code erreichen wollen, ist die Widergeburt eines alten Problems aus der handgebauten IT-Welt: Etwas, das so alt und historisch gewachsen ist, dass es niemand mehr freiwillig anfassen möchte und immer mehr zur kritischen Zeitbombe wird. 
• Konsistenzprobleme: Abhängigkeiten zwischen States – zum Beispiel VPCs, Subnets oder Security Groups – werden schwer nachvollziehbar. Fehlerquellen häufen sich. Sie machen eine Änderung an einer Ecke der Infrastruktur, und unerwartet knallt es dann wo ganz anders. Hat man nicht so gerne, wenn man aus manueller Stateflickerei bestehende Nachtschichten vermeiden möchte.
• Code-Duplikation: Wiederverwendbare Logik wird nicht mehr zentral gepflegt, sondern in vielen Modulen neu geschrieben. Das widerspricht dem DRY-Prinzip und sorgt dafür, dass der Zustand einer Infrastruktur vom wohldefinierten Zustand zunehmend in einen zwar noch definierten, aber undurchsichtigen Zustand abdriftet. Reverse-Engineering von Infrastruktur wollte man ja eigentlich nicht mehr machen müssen, aber wenn jeder ein Rad neu erfindet, provoziert man dies auf längere Sicht. 
• Zersplitterte Ressourcenverwaltung: Ohne ein zentrales Bild der Infrastruktur wird das Gesamtverständnis erschwert. Wer hat wann wo was geändert? Wen kann man fragen? Die Antwort ist oft nur ein Schulterzucken.

 

Architekturbeispiele für optimierte Terraform States

Die Theorie des "richtigen Maßes" ist nur so gut wie ihre Umsetzung in der Praxis. Deshalb lohnt sich ein Blick auf bewährte Architekturmuster, die sich in skalierbaren Terraform-Setups durchgesetzt haben. Zwei Ansätze haben sich besonders hervorgetan: der Layer-Ansatz für Multi-Account-Strategien und eine domänenbasierte Struktur für Microservice-Umgebungen.

Beispiel 1: Multi-Account-Cloud-Strategie mit Layer-Ansatz

Ein vielfach erprobtes Modell ist die Unterteilung der States in funktionale Layer. Dieses Prinzip orientiert sich am Lebenszyklus und der Änderungsfrequenz von Infrastrukturelementen. Das Ergebnis ist eine klar gegliederte State-Struktur:

├── Foundation Layer
│ ├── network-state.tf # VPCs, Subnets, Transit Gateways
│ ├── security-baseline-state.tf # Security Groups, NACLs, IAM Baseline
│ └── monitoring-state.tf # CloudWatch, Logging, Alarming
│
├── Platform Layer
│ ├── data-services-state.tf # Databases, Queues, Storage
│ ├── kubernetes-state.tf # EKS/OKE Cluster, Node Groups
│ └── ci-cd-state.tf # CI/CD Infrastructure
│
└── Application Layer
 ├── app-team-a-state.tf # Team A's Applications
 ├── app-team-b-state.tf # Team B's Applications
 └── shared-services-state.tf # Shared Application Services

Was macht diesen Ansatz so attraktiv? 

Dieser Ansatz entspricht dem Denken von Engineers. Es gibt drei Schichten:

• Foundation-Layer: Enthält stabile Ressourcen mit geringer Änderungsfrequenz. Netzwerke, Security-Baselines und Observability-Komponenten sind langlebig und unterliegen eher infrastrukturellen als geschäftlichen Anforderungen. Die Change-Rate ist gering, denn niemand benennt regelmäßig die CIDR-Ranges von Netzen um oder ändert Sicherheitsrichtlinien.
• Platform-Layer: Komponenten wie Datenbanken oder Kubernetes-Cluster ändern sich moderat häufig. Sie sind geschäftsrelevant, aber nicht täglich Gegenstand von Anpassungen. Oft sieht man hier noch klassisches Change-Management mit Releasezyklen von 3, 6 oder 12 Monaten, je nach Business und Compliance-Anforderungen.
• Application-Layer: Dieser Teil ist sehr dynamisch. Feature-Entwicklung und andere Innovationen des Produkts resultieren ständig in neuen Deployments und Testing, was wiederum häufige Änderungen an der Infrastruktur nach sich zieht. Auf dieser Schicht ist "On Demand" das Zauberwort - Ressourcen werden nur noch dann ausgerollt, wenn sie auch wirklich benötigt werden, und danach zwecks Kostenersparnis wieder abgerissen. Deshalb sind die States hier klein und teamweise isoliert gehalten. Macht Team A hier etwas kaputt, ist Team B davon nicht betroffen.  

Diese Struktur unterstützt sowohl eine saubere Trennung von Verantwortlichkeiten als auch eine effiziente Parallelisierung der Arbeit zwischen Teams. Gleichzeitig reduziert sie das Risiko von ungewollten Seiteneffekten bei Änderungen.

Beispiel 2: Domain-Driven Terraform für Microservice-Umgebungen

Ein ganz anderer, aber ebenso leistungsfähiger Ansatz findet sich in Microservice-orientierten Organisationen: Die domänengetriebene State-Aufteilung. Hier wird Infrastructure-as-Code entlang der Geschäftsdomänen organisiert – ähnlich wie es in Domain-Driven Design der Fall ist.

├── Infrastructure Domain
│ ├── networking-state.tf # Shared Networking
│ └── security-state.tf # Security Controls
│
├── Service Domains
│ ├── user-service-domain.tf # User Management Services + Infrastructure
│ ├── payment-domain.tf # Payment Processing + Infrastructure
│ └── content-domain.tf # Content Management + Infrastructure
│
└── Cross-cutting Concerns
 ├── monitoring-state.tf # Observability Infrastructure
 ├── backup-state.tf # Backup and Recovery Systems
 └── compliance-state.tf # Compliance Controls

Warum funktioniert das gut?

Dieser Ansatz entspricht dem Denken von IT-Managern.

• Alignment mit Geschäftslogik: Die technische Infrastruktur spiegelt die Organisation der Business-Domänen wider. Das erleichtert die Kommunikation zwischen Dev, Ops und Management.
• Teamautonomie: Jedes Team verwaltet seine Domäne inklusive zugehöriger Infrastruktur. Die Abhängigkeit von zentralen Teams wird minimiert. Arbeiten mehrere verschiedene Verantwortungsbereiche aus verschiedenen Silos (Netzwerk, Datenbanken, Storage, usw.) am gleichen Service beteiligt, sind diese dann pro Service gebündelt. Das steigert die Agilität und Time-to-Market, beides sind in Managementkreisen beliebte Buzzwords.
• Weniger Abstimmungsbedarf: Infrastrukturänderungen innerhalb einer Domäne betreffen selten andere Teams, wodurch Koordinationsaufwände zwischen Teams stark reduziert werden. Auch dies ist bei Managern beliebt, denn es betont die Eigenverantwortung von Value Streams und Scrum-Teams. 

Ein besonders großer Vorteil dieser Herangehensweise ist die Flexibilität in der Teamorganisation. Neue Services oder Domänen lassen sich unkompliziert hinzufügen, ohne bestehende Strukturen zu gefährden oder neu aufzusetzen. Mitarbeiter können in Basisinfrastruktur-Teams und Service-Teams gleichermaßen eingesetzt werden (virtuelle Teams). Diese Flexibilität fördert aber auch wiederum die Code-Duplikation, weshalb die Schichten der Infrastructure Domain und Cross-Cutting Concerns sehr wichtig sind, um Konflikte im Code zu vermeiden und klare Richtlinien zu definieren und Basismodule zu erstellen, die von den Service Teams benutzt werden müssen. Hierfür ist dann die Einführung von Policy-as-Code unerlässlich, denn Richtlinien müssen nicht nur definiert, sondern ihre Einhaltung auch auf Ebene von Terraform erzwungen werden können. 

 

Value Streams und Terraform State-Management

Die Strukturierung von Terraform States sollte sich nicht ausschließlich an technischen Schichten oder Modulen orientieren. Vielmehr lohnt sich der Blick auf die Wertströme einer Organisation. Wer States entlang der Value Streams aufbaut, orientiert sich konsequent an dem, was tatsächlich Mehrwert bringt. Das gilt bei der Bereitstellung von Infrastruktur ebenso wie beim Ausrollen neuer Features.

Zwei zentrale Wertströme haben sich in der Praxis als besonders relevant erwiesen: Infrastructure Provisioning und Application Deployment.

Value Stream 1: Infrastructure Provisioning

Beim Bereitstellen einer vollständigen Umgebung – zum Beispiel für ein neues Projekt oder eine neue Region – ist es entscheidend, dass Terraform-States logisch aufeinander aufbauen, aber möglichst geringe gegenseitige Abhängigkeiten aufweisen. Ziel ist es, große Teile der Infrastruktur unabhängig voneinander provisionieren zu können.

Ein bewährtes Modell sieht so aus:

Was steckt dahinter?

• Remote State Layer: Globale Konfigurationen wie IAM-Policies, zentrale Secrets-Verwaltung oder State-Backends bilden die Grundlage.
• Network Layer: Regionale Ressourcen wie VPCs, Subnetze oder Transit Gateways werden danach aufgebaut.
• Platform Layer: Cloud-native Services wie Kubernetes-Cluster, Datenbanken oder Messaging-Systeme folgen im Anschluss.
• Application Layer: Hier finden sich Workloads, CI/CD-Konfigurationen und Anwendungslogik. Dieser Layer sollte möglichst unabhängig deploybar sein.

Die Modularität dieses Aufbaus ermöglicht es Teams, schnell und kontrolliert ganze Umgebungen zu bootstrappen. Das ist etwa bei neuen Kunden, Regionen oder Geschäftsbereichen interessant.

Value Stream 2: Application Deployment

Ein zweiter, ebenso kritischer Wertstrom ist das Feature-Deployment. Hier liegt der Fokus auf Geschwindigkeit, Stabilität und möglichst geringen Auswirkungen auf andere Komponenten. Idealerweise lassen sich Änderungen an der Anwendung isoliert und ohne seiteneffekte auf andere States ausrollen.

Das Zielbild sieht dann so aus:

Worauf kommt es hier an?

• Trennung nach Umgebung: Entwicklungs-, Test- und Produktionsumgebungen haben jeweils ihre eigenen States. So lassen sich neue Features in isolierten Testumgebungen validieren, bevor sie produktiv gehen. Wenn man mit solchen Umgebungen arbeitet, ist zwar durchaus gewünscht, dass die Umgebungen zueinander identisch und repräsentativ sind. Aber eine Trennung der States ist hier dann obligatorisch, damit eine Änderung in der Testumgebung dann nicht versehentlich auch Auswirkungen auf die Produktion haben kann.
• Minimale Abhängigkeiten: States sind bewusst schlank gehalten, um Änderungen mit möglichst wenig Risiko durchzuführen. Ressourcen wie Datenbanken oder Netzwerke werden über Outputs referenziert, aber nicht direkt verändert.
• Hohe Parallelisierbarkeit: Feature-Branches in Git führen zu isolierten Änderungen an wenigen States. So kann das Deploymentteam schnell reagieren, ohne mit anderen Teams in Konflikt zu geraten.

Die Kombination aus Value-Stream-Denken und bewusst gestalteter State-Struktur schafft einen stabilen Rahmen für effiziente, sichere und skalierbare Deployments. Vom Infrastruktur-Fundament bis hin zum Go-Live eines neuen Features kann man durch diese Kombination einerseits ein hohes Maß and Flexibilität erreichen, aber man hält die Infrastruktur selbst und den Blast Radius im Fehlerfall unter Kontrolle. Der wohldefinierte Zustand des gesamten Rechenzentrums ist damit erreichbar.

Die praktische Anwendung des Goldilocks-Prinzips

Das Goldilocks-Prinzip ist mehr als eine nette Metapher.  es ist ein praktisches Werkzeug zur Gestaltung robuster, wartbarer Terraform-Module. Die Kunst liegt darin, die richtige Anzahl an Variablen, Konfigurationen und Outputs zu wählen. Nicht zu viel, nicht zu wenig, sondern genau richtig.

Dieses Diagramm visualisiert dieses Spannungsfeld: Auf der linken Seite steht die Unterdimensionierung, auf der rechten die Überoptimierung. In der Mitte liegt die sogenannte Goldilocks-Zone – der Bereich, in dem Module sowohl flexibel als auch stabil und gut wartbar sind.

Wenn es zu wenig ist...

Ein unterdimensioniertes Modul wirkt oft zunächst charmant, weil es einfach ist. Doch das täuscht. Typischerweise erkennt man diese Situation an:

• Monolithen: Eine einzelnen, zentralen State-Datei, die alles enthält – von Netzwerk über Security bis zu Workloads
• Unvollständigkeit: Wenige oder fehlenden Parametern, was zu einer Abhängigkeit von der Qualität des Providers und harter Kodierung von Werten führt
• Statischem Code: Eingeschränkter Wiederverwendbarkeit, weil alles auf einen konkreten Anwendungsfall zugeschnitten und das Modul nicht vollständig dynamisch ist
• Mangelhaften Rückgabewerten: Starren Output-Strukturen, die nicht gut in andere Module eingebunden werden können
• Fehlenden Guardrails: Unvollständige Prüfung von Eingabewerten (sogenantnen Variable Validations), Lifecycle Conditions und Runtime Checks zur Prüfung von errechneten bzw. der API zurückgegebenen Werten sind wichtig, um das korrekte Zusammenspiel von und mit den bereitgestellten Ressourcen sicherzustellen 

Solche Module sind kaum anpassbar und neigen dazu, bei der ersten Anforderung nach Flexibilität auseinanderzufallen.

Wenn es zu viel wird...

Auf der anderen Seite des Spektrums lauert die Gefahr der Überstrukturierung. Man erkennt sie an:

• Mikromanagement: Eine Vielzahl von kleinen Modulen und States, die schwer überblickbar sind
• Übermäßiger Parametrisierung: Jedes Detail wird extern gesteuert, selbst triviale Konfigurationen. Defaultwerte sind nicht sinnvoll oder überhaupt nicht gesetzt
• Komplexen Abhängigkeiten: Outputs referenzieren sich kreuz und quer, was zu einer wahren „Output-Orgie“ führen kann
• Datenflut: Redundanten oder unnötig generischen Outputs, die kaum noch Nutzen bringen, anstelle von wenigen klaren Outputs mit referenzierbaren Maps (Key/Value-Paaren) als Inhalt

Hier entsteht unnötiger Overhead, sowohl im Code als auch im Kopf. Die Einstiegshürde für neue Teammitglieder steigt, und das Risiko von Fehlern nimmt zu.

Die Goldilocks-Zone: Genau richtig

In der Mitte liegt das Zielbild: Terraform-Module, die modular, verständlich und teamfähig sind. Typische Merkmale:

• Modularisierte States mit klaren Grenzen:  Die States und die Module sind getrennt nach Layern, Domänen oder Umgebungen
• Ausreichend, aber nicht überbordende Parameter: Module arbeiten mit sinnvollen Defaults, die 80 % der Anwendungsfälle abdecken
• Wiederverwendbare Module: Erst durch vollständige Dynamisierung hat man Bausteine, die durch durchdachte Struktur teamübergreifend einsetzbar sind
• Konsistente Output-Strukturen: Die Outputs sind logisch benannt und leicht referenzierbar

Wer diesen Mittelweg findet, schafft die Grundlage für stabile IaC-Architekturen, die mit dem Unternehmen skalieren, anstelle dagegen zu arbeiten.

 

Best Practices für skalierbare Terraform-Implementierungen

Terraform ist ein mächtiges Werkzeug – doch seine Stärke entfaltet sich erst, wenn es systematisch und strategisch eingesetzt wird. Besonders bei skalierenden Umgebungen sind gewisse Grundprinzipien entscheidend, um langfristig wartbare, robuste und effiziente Setups zu schaffen. Im Folgenden stellen wir vier bewährte Best Practices vor, die sich in komplexen Cloud-Landschaften bewährt haben.

1. State-Segmentierung nach Änderungsgeschwindigkeit (Change Velocity)

Nicht alle Infrastrukturelemente ändern sich gleich häufig – und genau das sollte sich in der Terraform-Struktur widerspiegeln. Eine Segmentierung nach Änderungsfrequenz hilft dabei, Konflikte zu vermeiden und Entwicklungszyklen zu beschleunigen.

Ein Beispiel für eine solche Struktur in einer AWS-Umgebung:

└── AWS Infrastructure
    ├── low-velocity/        # Selten geändert (z. B. Netzwerke, IAM)
    │   ├── network/
    │   ├── security/
    │   └── dns/
    │
    ├── medium-velocity/     # Gelegentliche Änderungen (z. B. Datenbanken)
    │   ├── rds/
    │   ├── elasticache/
    │   └── sqs/
    │
    └── high-velocity/       # Häufige Änderungen (z. B. Compute, Workloads)
        ├── app-cluster-a/
        ├── app-cluster-b/
        └── batch-processing/

Warum das funktioniert: Teams können unabhängig arbeiten, ohne sich gegenseitig zu blockieren. Infrastruktur-Elemente, die selten angepasst werden, sind von schnellen Deployments entkoppelt – was sowohl Stabilität als auch Agilität erhöht.

2. Dynamische Terraform-Module mit validierten Variablen

Ein sauber strukturiertes Modul ist mehr als nur ein Container für Ressourcen. Es sollte so gestaltet sein, dass es sich flexibel an verschiedene Kontexte anpassen lässt – ohne dabei unkontrollierbar zu werden.

Was gehört dazu:

• Variable Validation: Jede Variable sollte – wenn möglich – über validation-Blöcke geprüft werden. So lassen sich ungültige Werte frühzeitig erkennen.
• Type-Sicherheit: Nutzen Sie präzise Typdefinitionen (string, number, bool, list(object) etc.), um Missverständnisse zu vermeiden.
• Optionale Variablen mit null-Support: Viele Variablen sind optional – aber sie müssen explizit nullable sein, damit sie sauber in Conditional Expressions verwendet werden können.

Ein Beispiel:

variable "mounts" {
  type = map(object({
    audit_non_hmac_request_keys  = optional(list(string))
    audit_non_hmac_response_keys = optional(list(string))
    allowed_managed_keys         = optional(set(string))
    default_lease_ttl_seconds    = optional(number)
    description                  = optional(string)
    external_entropy_access      = optional(bool)
    identity_token_key           = optional(string)
    listing_visibility           = optional(string)
    local                        = optional(bool)
    max_lease_ttl_seconds        = optional(number)
    namespace                    = optional(string)
    options                      = optional(map(any))
    passthrough_request_headers  = optional(list(string))
    plugin_version               = optional(string)
    seal_wrap                    = optional(bool)
    allowed_response_headers     = optional(list(string))
    delegated_auth_accessors     = optional(list(string))
    path                         = string
    type                         = string
  }))
  default = null

  description = <<-EOT
Defines the configurations for Vault mounts. Each mount configuration should specify the following keys:<br>
[...]
EOT

  validation {
    condition = (
      var.mounts == null ? true : alltrue([
        for mount in var.mounts : (
          mount.listing_visibility == null ||
          mount.listing_visibility == "unauth" ||
          mount.listing_visibility == "hidden"
        )
      ])
    )
    error_message = "The 'listing_visibility' value must be either 'unauth' or 'hidden' if specified."
  }

  validation {
    condition = (
      var.mounts == null ? true : alltrue([
        for mount in var.mounts : (
          mount.path == null || (
            !startswith(mount.path, "/") &&
            !endswith(mount.path, "/")
          )
        )
      ])
    )
    error_message = "The 'path' value must not start or end with a '/'."
  }
[... etc. ...]
}

Solche Module lassen sich teamübergreifend einsetzen und reduzieren Supportaufwand erheblich.

3. State-übergreifende Abhängigkeiten via Remote State

In komplexen Umgebungen lassen sich Abhängigkeiten zwischen Ressourcen selten vollständig vermeiden. Doch statt diese direkt zu modellieren, empfiehlt sich die Nutzung von Remote State Outputs. Das zentrale Prinzip ist simpel: Ein State produziert relevante Outputs, ein anderer konsumiert sie über die Data Source terraform_remote_state.

Konsultieren Sie für einen Deep Dive hierzu den ersten Teil unserer "Terraform @ Scale" Artikelserie, denn dort haben wir dies ausgiebig und über mehrere Unterkapitel verteilt durchgekaut.

4. Der HashiCorp-Toolstack als Enabler für State-Strategien

Skalierbare Terraform-Implementierungen leben nicht allein von gutem Code. Sie basieren auf einem Ökosystem, das Sicherheit, Orchestrierung und Wiederverwendbarkeit unterstützt. Bei ICT.technology setzen wir konsequent auf den HashiCorp-Stack, um diese Anforderungen zu erfüllen. Die hier wichtigsten Komponenten sind:

• Terraform / Terraform Enterprise
  Zentralisierte State-Verwaltung, Policy-as-Code (z. B. mit Sentinel) und Workspace-Isolation für Teams
• Vault / Vault Enterprise
  Sichere Secret-Verwaltung, dynamische Credentials für Cloud-Zugänge, Rotation, Audit-Trails
• Consul / Consul Enterprise
  Service Discovery, Health Checks, dynamische Konfiguration und Integrationen mit Plattformdiensten
• Nomad / Nomad Enterprise
  Orchestrierung für Container, VMs und Bare Metal – mit geringerem Footprint als Kubernetes
• Packer
  Erstellung standardisierter Images (Golden Images) mit Versionierung, Idempotenz und CI/CD-Integration
• Boundary / Boundary Enterprise (nur, falls Sie bereits PostgreSQL-Cluster auf Enterprise-Niveau mit entsprechenden SLAs und OLAs in Betrieb haben)
  Sichere, identitätsbasierte Zugriffe auf Infrastrukturkomponenten – besonders relevant bei produktiven Datenbanken oder regulierten Workloads

Diese Werkzeuge ermöglichen eine konsistente, nachvollziehbare und sichere Terraform-Praxis – selbst in heterogenen, hochgradig dynamischen Enterprise-Umgebungen.

Praktischer Leitfaden zur State-Dimensionierung

Die optimale Größe eines Terraform States ergibt sich nicht aus einer Vorlage, sondern aus einem strukturierten Prozess, der technische Realität und organisatorische Anforderungen in Einklang bringt. Im Folgenden skizzieren wir einen praxisbewährten Leitfaden, der bei der Planung und Umsetzung hilft.

1. Analyse der Organisationsstruktur

Der erste Schritt ist, die eigene Organisation genau zu verstehen:

• Wer verwaltet welche Ressourcen? Gibt es zentrale Infrastruktur-Teams oder arbeiten Applikationsteams unabhängig?
• Wo ist Autonomie erforderlich? Teams mit hoher Deployment-Frequenz sollten eigene States besitzen, um sich nicht gegenseitig zu blockieren.
• Wie sehen die Lebenszyklen aus? Ressourcen, die sich gemeinsam entwickeln oder gemeinsam entfernt werden, gehören idealerweise in denselben State.

2. Abhängigkeitsanalyse

Im zweiten Schritt geht es um die technischen Verbindungen zwischen Ressourcen:

• Welche Ressourcen sind eng gekoppelt? Beispiel: Security Groups und EC2-Instanzen oder Subnets und Load Balancer.
• Was lässt sich entkoppeln? Monitoring, IAM-Rollen oder Backup-Systeme können oft separat verwaltet werden – das senkt Komplexität.

3. Testlauf und Iteration

Bevor eine großflächige Reorganisation stattfindet, lohnt sich ein gezielter Test:

• Pilotprojekte mit variabler State-Struktur: Zum Beispiel ein Team, das zwischen einem monolithischen und einem segmentierten Ansatz wechselt.
• Messbare Kriterien: Performance (Plan/Apply), Fehlerhäufigkeit, Team-Zufriedenheit, Geschwindigkeit von Releases.

Fallstudie: Cloud-Migration eines Enterprise-Kunden

Ein eindrucksvolles Beispiel liefert ein Finanzdienstleister, den ICT.technology beim Wechsel von einer On-Premise-Infrastruktur zur Oracle Cloud Infrastructure (OCI) unterstützte.

Ausgangssituation:
Die Terraform-Umgebung bestand aus einem einzigen, großen State. Das Ergebnis:

• Fast 45 Minuten Laufzeit pro terraform apply
• Häufige Konflikte beim State Locking
• Langsame Entwicklungs- und Release-Zyklen

Lösungsansatz:
Wir wandten das Goldilocks-Prinzip an und segmentierten die Infrastruktur wie folgt (wobei unterhalb der jeweiligen Punkte hier dann über die Mandantenfähigkeit von Terraform Enterprise die jeweiligen Teams bzw. Services aufgehängt wurden, je nach individuellem Bedarf):

├── Foundation
│   ├── network/
│   │   ├── transit/
│   │   ├── network/
│   │   └── interconnect/
│   └── security/
│       ├── iam/
│       ├── security-groups/
│       └── baseline/
├── Data Services
│   ├── databases/
│   ├── storage/
│   └── analytics/
└── Applications
    ├── frontend/
    ├── backend/
    ├── batch/
    └── monitoring/

Ergebnisse:

• Apply-Zeit unter 5 Minuten, denn Infrastrukturänderungen wurden deutlich schneller bereitgestellt
• Parallele Teamarbeit wurde möglich, denn Teams konnten unabhängig voneinander deployen, ohne sich gegenseitig zu blockieren
• 70 % schnellere Releases durch kürzere Feedbackzyklen und weniger Reibung
• Höhere Stabilität durch kleinere, klar abgegrenzte Changes und hierdurch minimiertem Blast Radius im Fall von Fehlkonfigurationen oder menschlichen Fehlern im Betrieb
• Massive Kosteneinsparungen durch die dynamische und bedarfsgesteuerte Provisionierung von Bare Metal Servern und VMs, d.h. Deployment nur bei tatsächlichem Bedarf und danach w3ieder automatischer Abbau

Fazit: Der Weg zur optimalen Terraform-Skalierung

Die Dimensionierung von Terraform States ist kein einmaliges Architekturproblem. Sie ist vielmehr ein kontinuierlicher Reifeprozess. Das Goldilocks-Prinzip hilft dabei, extreme Strukturen zu vermeiden: die Codebasis sollte weder zu monolithisch, noch zu fragmentiert sein.

Entscheidend ist, die eigene Organisation zu verstehen, Verantwortlichkeiten sauber zu trennen und die technische Umsetzung konsequent entlang realer Workflows zu gestalten.

ICT.technology begleitet Unternehmen genau auf diesem Weg – von der ersten Cloud-Adoption bis zur vollständigen Transition hin zu Infrastructure-as-Code Exzellenz. Mit tiefem Know-how in Terraform, dem HashiCorp-Ökosystem und Cloud-Architekturen schaffen wir Lösungen, die technisch belastbar und organisatorisch nachhaltig sind.

Denn richtig strukturierte Terraform States sind kein Selbstzweck. Sie sind ein zentraler Hebel für Skalierbarkeit, Geschwindigkeit und operative Stabilität – und damit ein entscheidender Erfolgsfaktor jeder modernen IT-Organisation.