Infrastructure as Code auf AWS: Von Snowflake-Maschinen zu reproduzierbaren Stacks – Erkenntnisse aus „Infrastructure as Code“ von Martin Sereinig (Usersnap GmbH)

Warum dieser Talk für Engineering-Teams relevant ist

Auf AWS Infrastruktur wie Software zu behandeln, ist längst mehr als ein Trend. In seinem Vortrag „Infrastructure as Code“ zeigt Martin Sereinig, CTO bei Usersnap GmbH, wie sich die Reise von Einzelservern zu Cloud- und Container-Ökosystemen vollzogen hat – und warum Infrastructure as Code (IaC) heute der Schlüssel ist, um komplexe Setups sicher, reproduzierbar und versionskontrolliert zu betreiben. Usersnap selbst läuft als Self-Service-SaaS vollständig in AWS. Der Talk liefert einen praxisnahen Blick auf Anforderungen, Tools (CloudFormation, AWS CDK, Troposphere) und Stolpersteine – inklusive Lektionen, die Teams unmittelbar übernehmen können.

Kurze Geschichte: Vom Einzelserver zur Cloudplattform

Am Anfang stand der einzelne Server: Webserver, Datenbank, Mail – oft getrennt, aber alles manuell auf Maschinenebene administriert. Für manche Kontexte ist das auch heute noch okay (z. B. ein Uni-Institut mit einem WordPress). Doch die Nachteile sind bekannt:

• Snowflake-Maschinen: Ein Server wird iterativ und ad-hoc angepasst („kannst du noch X hinzufügen?“). Nach Jahren weiß niemand mehr, was genau läuft.
• Horizontale Skalierung ist schwer: Drei identische Server zu bauen, ist aufwendig, wenn Konfigurationen nicht deterministisch dokumentiert sind.
• Implizites Wissen: Wer nicht weiß, dass Apache statt Nginx läuft, findet die relevante Konfiguration nicht.

Zwar lassen sich diese Probleme mit Skripten oder Tools wie Ansible adres­sieren, doch der Wendepunkt kam mit zwei Revolutionen: Cloud Computing und Containerisierung.

Revolution 1: Cloud Computing als Infrastruktur-Baukasten

Cloud Computing wandelte komplexe Infrastruktur in standardisierte, sofort verfügbare Bausteine. Ein Beispiel aus der Vor-Cloud-Ära: Ein Load Balancer erforderte eine Maschine, Nginx-Setup, Reverse-Proxies, Firewall-Regeln – alles manuell. Heute: In AWS klicken, auswählen, bezahlen, fertig. Das öffnet die Tür für Dienste, die zuvor außerhalb der Reichweite einzelner Teams lagen – etwa Content-Delivery-Netzwerke.

Der Effekt: Infrastruktur wird konsumierbar, kombinierbar und planbar. Gleichzeitig verschiebt sich die Komplexität von der Maschine zu den Cloud-Ressourcen und deren Beziehungen.

Revolution 2: Containerisierung und die „dummen Docker-Maschinen“

Containerisierung veränderte die Applikationsseite. Früher bedeutete eine Rails-App, die PNGs generiert, eine Liste aus Paketinstallationen und Build-Steps auf einer Serverinstanz. Heute läuft die Applikation in einem Container, und alle Systemabhängigkeiten stehen im Dockerfile. Betriebsteams müssen die Anwendungsbibliotheken nicht länger auf Servern pflegen – die Entwickler kapseln die Anforderungen in der Image-Build-Pipeline.

• Keine Snowflake-Maschinen mehr: Laufzeitknoten sind „dumme Docker-Maschinen“.
• Explizites Wissen: Der Dockerfile dokumentiert Infrastrukturbedarfe der Anwendung.
• Skalierung: Replizieren von Containern ist trivial – die Herausforderung liegt nicht mehr im Server, sondern im Zusammenspiel der Cloud-Ressourcen.

Neue Ebene, gleiche Probleme: die Snowflake-Infrastruktur

Was vorher der Server war, ist heute die Cloud-Landschaft: Wer „irgendwann mal“ im AWS-UI einen Load Balancer oder Route-53-Einträge klickt, erzeugt womöglich eine Snowflake-Infrastruktur. Drei Jahre später fehlt die Dokumentation; unterschiedliche Regionen in der AWS-Konsole lassen Ressourcen „verschwinden“, wenn man im falschen Kontext sucht. Staging-Umgebungen mit identischer Architektur nachzubauen, wird ohne klare Beschreibung mühsam.

Ergebnis: Wir brauchen dieselben Prinzipien, die Container auf Applikationsseite etablierten – nur jetzt für Infrastruktur.

Anforderungen an modernes Infrastruktur-Tooling

Sereinig formuliert prägnante Kriterien, die Infrastructure-as-Code-Werkzeuge erfüllen sollten:

• Kompatibel mit Cloud-Provider-APIs: Manuelle Bash-Skripte von gestern sind obsolet; IaC muss direkt mit dem Cloud-API sprechen.
• Deklarativ statt imperativ: Nicht „wie“, sondern „was“. Wir beschreiben den Zielzustand („ich will ein CDN“), nicht die Schrittfolge.
• Idempotent: Mehrfaches Anwenden führt reproduzierbar zum gleichen Ergebnis.
• Anpassbar: Variablen/Parameter erlauben z. B. andere Domains für Staging.
• Kein Blackbox-Ergebnis: Das Tool sollte „normale“ Ressourcen im jeweiligen Cloud-Ökosystem erzeugen, die man einsehen und verwalten kann.
• Drift erkennen und behandeln: Differenzen zwischen gewünschtem und aktuellem Zustand dürfen nicht unbemerkt bleiben.
• Versionierbar: Änderungen an der Infrastruktur gehören in Versionskontrolle, inklusive Commit-Historie als Begründung.

Diese Prinzipien übertragen die Tugenden von Dockerfiles auf Infrastruktur – maschinenlesbar, wiederholbar, auditierbar.

Die Tool-Landschaft im Talk: Multi-Cloud bis AWS-nativ

Sereinig skizziert drei Kategorien von Ansätzen:

• Multi-Provider-Tools: „Terraform, NCP Chef“ – eine gute Wahl für Agenturen oder Consultancies, die viele Provider abdecken müssen, ohne jedes Mal neu zu lernen.
• AWS CloudFormation: Das, was Usersnap einsetzt – große YAML-Templates, die die komplette Infrastruktur definieren.
• AWS Cloud Development Kit (CDK): Eine DSL in TypeScript, die CloudFormation-Templates generiert. „Im Grunde ein Frontend für CloudFormation.“

Warum Usersnap CloudFormation nutzt

• Produktfirma-Setup: Usersnap kann „all-in auf AWS“ gehen; ein Providerwechsel ist nicht geplant. Daher spricht alles für den nativen Weg.
• Timing: Die bestehende Plattform entstand vor dem AWS CDK. Heute würde Sereinig das CDK wählen.

Das minimale CloudFormation-Template – als Denkmodell

Das kleinste sinnvolle Template gliedert sich in drei Teile:

1. Beschreibung (Description): Metadaten, z. B. „Hello world“ – für Menschen.
2. Parameter (Parameters): Werte, die bei der Anwendung des Templates in der AWS-Konsole gesetzt werden können – der Schlüssel zur Anpassbarkeit (z. B. Domains für Staging).
3. Ressourcen (Resources): Deklarative Definitionen wie eine VPC mit gewünschten Eigenschaften.

Wichtig: In Ressourcen können Parameter per Referenz („Ref“) verwendet werden. Zudem lassen sich stack-eigene Informationen nutzen. Das Ganze ist deklarativ – die Engine kümmert sich um das „Wie“.

Realität bei Usersnap: mehrere Stacks, viele Ressourcen

Ein Blick in die Praxiszahlen aus dem Talk:

• Mehrere Stacks (z. B. für unterschiedliche Umgebungen)
• 69 Parameter
• 85 Ressourcen
• Rund 2.000 Zeilen YAML

Diese Größenordnung ist „hart zu warten“, so Sereinig – insbesondere ohne unterstützendes Tooling. Aber sie zeigt auch: CloudFormation skaliert zu vollwertigen Produktionslandschaften.

Arbeitsablauf in CloudFormation: vom Template zum ChangeSet

In der AWS-Konsole lässt sich ein Template auf einen existierenden Stack anwenden:

• Man kann das aktuelle Template weiterverwenden (nur Parameter aktualisieren) oder es ersetzen (z. B. bei neuen Ressourcen).
• Danach folgt die Parametrisierung – in Usersnaps Produktions-Stack eine lange Liste von Eingaben.
• CloudFormation zeigt vorab eine Vorschau der Änderungen. Dieser ChangeSet-Preview ist zentral für das Sicherheitsgefühl beim Ausrollen.

Ein starkes Feature ist die automatische Ermittlung von Abhängigkeiten zwischen Ressourcen. Sereinig beschreibt den Kaskadeneffekt: Wird eine Elasticsearch-Domain aktualisiert, aktualisiert CloudFormation daraufhin die Beanstalk-Umgebung, die wiederum Route-53-Records anpasst – ohne dass das Team diese Reihenfolge manuell orchestrieren muss.

Am Ende steht der „große, gruselige Knopf“ – die Ausführung. In der Regel funktioniert es reibungslos, aber das Team soll verstehen, was genau passieren wird.

Die Vorteile im täglichen Betrieb

Sereinig fasst zusammen, was CloudFormation im Team bewirkt hat:

• Snowflakes adé: Weder Maschinen noch Infrastruktur sind einzigartig und undokumentiert – alles Wesentliche steht im CloudFormation-Template, im Dockerfile oder in Parametern.
• Replizierbarkeit: Eine neue Staging-Umgebung aufzusetzen, ist deutlich einfacher, wenn alle Teile deklarativ beschrieben sind.
• Kosten: CloudFormation selbst ist kostenlos – bezahlt werden nur die zugrunde liegenden AWS-Ressourcen.

Lessons Learned: Was wir als Redaktion mitnehmen

Die folgenden Punkte sind die konkretesten, praxisrelevanten Empfehlungen aus „Infrastructure as Code“ von Martin Sereinig:

1) Nutzt Tooling zur Template-Erzeugung

Ein 2.000-Zeilen-YAML per Hand zu pflegen, ist fehleranfällig. Usersnap setzt auf Troposphere (weil das CDK damals noch nicht existierte). Heute würde Sereinig das AWS CDK wählen. Die Quintessenz: Generiert Templates mit strukturierten Werkzeugen, nicht im reinen Texteditor.

2) Führt eine echte Staging-Umgebung

„Wirklich“ eine Staging-Umgebung zu haben, ist essenziell – besonders bei Infrastrukturänderungen. So lassen sich Updates testen, bevor Kundensysteme betroffen sind. CloudFormation ermöglicht es, Staging und Produktion ähnlich zu strukturieren und per Parametern zu differenzieren (z. B. Domainnamen).

3) Manuell ist manchmal okay – mit Drift Detection im Rücken

Nicht alles muss automatisiert durch IaC fließen. Einzelne Änderungen – etwa ein Datenbank-Versionsupdate – können manuell erfolgen. Wichtig ist, dass das später im Template nachgezogen wird. Die Drift Detection von CloudFormation erkennt, dass der Ist-Zustand bereits dem Soll entspricht, und würde bei der nächsten Template-Anwendung nicht „korrigierend“ eingreifen.

4) Achtung „Replacement“ – Datenverlust droht

Ein unscheinbarer Flag kann harte Konsequenzen haben: Steht bei einer Ressource „Replacement conditional“, kann ein Update zur vollständigen Neu-Erzeugung führen – inklusive Löschen der alten Instanz und ihrer Daten. CloudFormation „räumt auf“ und löscht dabei auch automatisierte Backups. Wer hier nicht aufpasst, erlebt den sprichwörtlich „wirklich, wirklich schlechten Tag“.

5) Schutz durch Stack Policies

Gegen versehentliches Ersetzen oder Löschen helfen Stack Policies. Kritische Ressourcen lassen sich damit vor gefährlichen Operationen schützen. Sereinig empfiehlt, diese Schutzschicht zu nutzen.

Praktische Orientierungspunkte für Teams

Aus Sicht unserer Redaktion ergeben sich unmittelbar umsetzbare Leitlinien, die direkt aus dem Talk ableitbar sind:

• Parameterisieren statt kopieren: Domains, Regionen, Umgebungsnamen – all das gehört als Parameter ins Template, nicht als hartkodierte Werte.
• Ressourcenbeziehungen nutzen: Verlasst euch auf CloudFormation, um Abhängigkeiten korrekt zu sequenzieren. Der Preview zeigt die Kaskaden.
• Regionen bewusst wählen: In der AWS-Konsole im falschen Region-Context zu sein, führt zu „unsichtbaren“ Ressourcen. Das ist kein Bug, sondern Kontext – und ein häufiger Stolperstein.
• Multi-Stack-Architektur: Mehrere Stacks (z. B. für Staging und Produktion) halten Änderungen kleiner, verständlicher und sicherer ausrollbar.
• Versionierung ernst nehmen: Infrastrukturänderungen gehören ins Git – inklusive nachvollziehbarer Commit-Messages.

Diese Punkte sind keine abstrakten Best Practices, sondern stehen in direktem Zusammenhang mit dem, was Sereinig im Betrieb beobachtet.

Wie wir den Werkzeugvergleich aus dem Talk einordnen

• Multi-Provider-Tooling („Terraform, NCP Chef“): Sinnvoll, wenn viele Clouds im Spiel sind oder wenn Kundenumgebungen heterogen sind.
• CloudFormation: Passend für Teams, die – wie Usersnap – „all-in“ bei AWS sind und nahe an den nativen Primitive bleiben wollen.
• AWS CDK: Eine ergonomische, heute bevorzugte Art, CloudFormation-Templates zu beschreiben. Im Talk der klare Favorit „wenn wir es jetzt neu machen würden“.

Wesentlich ist weniger die Wahl des Werkzeugs, sondern das Einhalten der genannten Eigenschaften (Deklarativität, Idempotenz, Drift-Erkennung, Versionierung und Schutzmechanismen).

Ein mentales Modell: Vom Dockerfile zur Stack-Definition

Die Parallele, die Sereinig zieht, ist eingängig:

• Das Dockerfile hält alles fest, was die Anwendung an Systemumgebung braucht – explizit und reproduzierbar.
• Das CloudFormation-Template hält fest, was die Infrastruktur bereitstellen und wie sie parametrisiert sein soll – explizit und reproduzierbar.

Liest man beide zusammen, entsteht ein vollständiges Bild: Applikationsbedarfe (Container) plus Infrastrukturbausteine (Stacks). Fehlende, implizite Wissensinseln werden so minimiert.

Fazit: Infrastructure as Code als Betriebssystem für die Cloud

„Infrastructure as Code“ von Martin Sereinig (Usersnap GmbH) ist eine klare Einladung, Infrastruktur mit den gleichen Disziplinen zu behandeln wie Software. Die Kernbotschaften:

• Cloud und Container haben die Spielregeln verändert – und die Probleme von der Maschine zur Plattform verlagert.
• IaC bringt Ordnung und Nachvollziehbarkeit zurück: deklarativ, idempotent, parametrisiert, drift-sensitiv und versioniert.
• CloudFormation (bzw. CDK) funktioniert im Alltag – auch in Produktionen mit zig Parametern und Dutzenden Ressourcen – wenn man Tooling, Staging und Schutzmechanismen ernst nimmt.

Wer diese Prinzipien anwendet, macht aus „Klick-Historien“ wieder prüfbare, reproduzierbare Zustände. Genau das braucht moderne Softwareentwicklung in einer AWS-Welt, in der ein „großer, gruseliger Knopf“ viele Ressourcen gleichzeitig verändert – und in der gute Vorarbeit den Unterschied zwischen ruhigem Deployment und einem sehr schlechten Tag ausmacht.

• 

  

  Martin Sereinig, CTO von usersnap

  Der CTO von Usersnap Martin Sereinig spricht im Interview darüber, wie die Devs im Unternehmen die Teamorganisation und das Recruiting gestalten – und was man mit zwei Pizzas machen kann.

  Jetzt ansehen