AWS-Multi-Account-Architekturen mit Terraform entwerfen

Warum ein Account nie genug ist

Am Anfang ist es verlockend, alles in einem einzigen AWS-Account laufen zu lassen und IAM-Policies sowie Tags die Trennung übernehmen zu lassen. Von diesem Modell bin ich jedes Mal wieder abgerückt, denn eine Account-Grenze ist eine grundlegend stärkere Isolationsebene als eine Policy. Eine falsch konfigurierte IAM-Policy oder ein kompromittiertes Credential in einem Single-Account-Setup hat einen Blast-Radius, der die gesamte Umgebung umfasst: Produktion, Staging und geteiltes Tooling liegen alle hinter demselben Perimeter. Trennt man diese Workloads auf verschiedene Accounts, kann ein Fehler in einer Umgebung eine andere schlicht nicht erreichen. Es gibt keine Policy, mit der man sich an einer harten Account-Grenze vorbeikonfigurieren könnte. Es macht Least Privilege auch leichter nachvollziehbar (Berechtigungen sind auf das begrenzt, was ein Account enthält, statt Ressource für Ressource aufgezählt zu werden), und es macht Kostenzuordnung trivial, denn jeder Euro in einem Account gehört einem bekannten Team oder Workload zu, ohne dass Tagging-Disziplin die Hauptarbeit leisten muss.

Eine pragmatische Account-Struktur

Die Struktur, auf die ich standardmäßig setze, hat einen Management-Account an der Wurzel rein für Billing und organisationsweite Policies, einen dedizierten Security- und Log-Archiv-Account, der Read-only-Kopien der Logs aller anderen Accounts erhält und selbst keine Workloads hält, einen Shared-Services-Account für Dinge wie eine Container-Registry oder CI-Runner, die jede Umgebung braucht, aber nicht selbst besitzen sollte, sowie Workload-Accounts pro Umgebung (Dev, Staging, Produktion), jeweils voneinander isoliert. Das ist nicht exotisch. Es spiegelt, was AWS Organizations und AWS Control Tower ohnehin erwarten, und es hält das mentale Modell einfach: Wenn man den Account benennen kann, weiß man, was in ihm erlaubt ist.

Terraform, das mit Ihnen skaliert

Von Hand ist das alles nicht mehr handhabbar, sobald man mehr als zwei oder drei Accounts hat. Deshalb bilde ich die gesamte Struktur in Terraform ab: wiederverwendbare Module für die Teile, die sich über Accounts hinweg wiederholen (Networking, IAM-Baselines, Logging), sowie account- und umgebungsspezifischen State, der getrennt gehalten wird, damit eine Änderung in Staging niemals den State von Produktion berühren kann. Rollouts sind end-to-end automatisiert. Es gibt kein manuelles terraform apply von jemandes Laptop gegen einen produktiven Account. Muss sich etwas ändern, geschieht das jedes Mal über dieselbe geprüfte Pipeline, und genau das macht die Account-Struktur überhaupt erst vertrauenswürdig: Die Isolation ist nur so gut wie der Prozess, der sie pflegt.

IAM- und Logging-Grundlagen

Innerhalb dieser Struktur halte ich IAM-Rollen standardmäßig nach Least Privilege (Service-Rollen bekommen exakt die Berechtigungen, die ihr Workload braucht, nichts wird "vorsichtshalber" angenommen), und jeder Account schickt seine CloudTrail- und CloudWatch-Logs an den zentralen Log-Archiv-Account, wo sie aus Sicht der erzeugenden Accounts unveränderlich sind. Diese Kombination bedeutet, dass ein kompromittierter Workload-Account seine eigenen Spuren nicht löschen kann, und eine Analyse von "was ist passiert" hängt nie davon ab, dem untersuchten Account zu vertrauen.

Kernaussagen

• Account-Grenzen isolieren den Blast-Radius auf eine Weise, die keine IAM-Policy allein leisten kann.
• Ein kleines, zweckgebundenes Set an Accounts (Management, Security, Shared Services, Workload-Accounts pro Umgebung) deckt die meisten realen Bedürfnisse ab.
• Terraform-Module mit getrenntem State pro Account halten die Struktur wartbar, während sie wächst.
• Zentralisiertes, unveränderliches Logging in einem dedizierten Account lohnt sich, bevor man es braucht.