Multi-Account-Strategie auf AWS - warum ein Account nicht reicht

Ein AWS-Account, alles drin, läuft. Am Anfang ist das auch völlig okay. Schnell loslegen, erste Workloads deployen, Ergebnisse zeigen. Niemand braucht am Tag eins eine Multi-Account-Strategie.

Aber Tag eins geht vorbei. Bald fragt jemand, was die Produktion eigentlich kostet. Irgendwann gibt ein Entwickler sich selbst Admin-Rechte, weil die IAM-Policies zu restriktiv waren - oder zu unklar. Und vielleicht fährt jemand eines Tages einen Lasttest in der Staging-Umgebung und die Produktions-Lambdas laufen ins Concurrency-Limit, weil alle im selben Account liegen.

Spätestens dann ist klar: Ein Account reicht nicht. Die gute Nachricht: Mit der richtigen Strategie ist der Weg zu einer sauberen Multi-Account-Struktur kein Hexenwerk - auch wenn man nicht von Null anfängt.

Warum ein einzelner Account nicht reicht

Ein AWS-Account ist mehr als nur ein Login. Er ist eine Sicherheitsgrenze, eine Abrechnungseinheit und ein Rahmen für Service Quotas. Wenn alles in einem Account läuft, teilen sich sämtliche Workloads all diese Dimensionen - und das ist nicht ideal.

Schauen wir zuerst auf Security. Ein kompromittierter IAM-User oder eine falsch konfigurierte Rolle - der Blast-Radius ist groß. Gleichzeitig müssen Entwickler handlungsfähig bleiben, ohne dass die produktive Umgebung gefährdet wird. Dieser Spagat wird mit wachsender Applikation und wachsendem Team immer schwieriger. Separate Accounts lösen das elegant: Entwickler bekommen die Freiheit, die sie brauchen, und die Produktion bleibt geschützt - durch harte Grenzen statt durch immer komplexere IAM-Policies.

Eng damit verbunden ist Kostentransparenz. Ohne Account-Trennung ist es schwer, Kosten sauber zuzuordnen, Abweichungen zu erkennen und unerwartete Ausgaben frühzeitig zu bemerken. Cost-Allocation-Tags helfen dabei, aber nur bedingt und sie decken nicht alle Services sauber ab. Mit eigenen Accounts pro Workload oder Team ist Kostentrennung und -kontrolle einfacher.

Ein Thema, das gerne übersehen wird: Service Quotas. Jeder AWS-Account hat Limits - etwa Lambda Concurrency oder API Gateway Requests. Manche kann man erhöhen, manche nicht - und wenn, dann weder sofort noch garantiert. Eigene Accounts geben jedem Workload seinen eigenen Satz an Quotas - Problem gelöst.

Und schließlich Compliance. Für Audits, Zertifizierungen oder interne Governance braucht es eine klare Trennung zwischen Produktion und Nicht-Produktion. Mit separaten Accounts ist diese klar vorhanden, ohne dass man sie künstlich erzeugen muss.

Wie eine saubere Org-Struktur aussieht

AWS Organizations bildet dabei immer das Fundament. Die Struktur ist simpel: Ein Management-Account als Wurzel, darunter Organizational Units (OUs), und in den OUs die einzelnen Accounts. Klingt nach viel Verwaltung - ist es aber nicht, wenn man es richtig aufsetzt.

Ein pragmatischer Startpunkt: Eine Security OU mit Accounts für Log Archive und Security Tooling. Hier laufen CloudTrail-Logs zusammen, hier liegt GuardDuty, hier hat nur das Security-Team Zugriff. Daneben eine Infrastructure OU für globale Ressourcen wie DNS oder Shared Networking. Und dann die Workload OUs - getrennt nach Produktion und Nicht-Produktion, mit eigenen Accounts pro Team oder Workload.

Dazu eine Sandbox OU für Experimente und Lernen. Harte Guardrails, aber maximale Freiheit innerhalb dieser Grenzen. Entwickler können ausprobieren, ohne dass jemand nervös wird.

Das Schöne daran: Diese Struktur ist kein technischer Overhead. Sie ist ein Governance-Instrument. Sie definiert, wer was darf, wo Kosten entstehen und wie Risiken isoliert werden - auf einer Ebene, die über einzelne IAM-Policies hinausgeht. Und neue Accounts sind in wenigen Minuten provisioniert und ready to go.

Die richtigen Werkzeuge

Eine Multi-Account-Strategie steht und fällt mit der Frage, wie man sie betreibt. Accounts manuell anlegen, Berechtigungen per Hand pflegen, Policies in der Console zusammenklicken - das skaliert nicht. Die gute Nachricht: AWS bringt die richtigen Services mit, und mit dem richtigen Tooling wird die gesamte Org-Struktur zum verwalteten Code-Artefakt.

IAM Identity Center (ehemals AWS SSO) räumt mit einem der häufigsten Probleme auf: IAM-User-Wildwuchs. Statt in jedem Account eigene User und Credentials zu verwalten, gibt es einen zentralen Einstiegspunkt. Mitarbeiter melden sich einmal an und wechseln zwischen Accounts und Rollen - ohne je einen Access Key anfassen zu müssen. Wer bereits ein Identity-System wie Entra ID oder Active Directory im Einsatz hat, bindet es einfach an.

Service Control Policies (SCPs) sind Leitplanken auf Organisationsebene. Sie definieren, was in einem Account maximal erlaubt ist - unabhängig davon, welche IAM-Rechte ein User hat. Bestimmte Regionen sperren, das Löschen von CloudTrail verhindern, den Root-User in Workload-Accounts einschränken - alles zentral, alles durchsetzbar. Keine Empfehlung, sondern eine harte Grenze.

Org Formation ist unser bevorzugtes Tool fü rLanding-Zones. Wo Control Tower nicht genug Flexibilität bietet, gibt uns Org-Formation deutlich mehr Kontrolle: Accounts, OUs, SCPs, Identity Center - alles als Infrastructure as Code, versioniert in Git, reproduzierbar und über CI/CD ausrollbar. Der eigentliche Clou: Neue Accounts lassen sich direkt mit Ressourcen und Deployments vorkonfigurieren - auf Basis von CloudFormation oder CDK. Ein neuer Workload-Account kommt nicht leer, sondern bereits mit den wichtigsten Basis-Ressourcen.

Wo anfangen?

Wer heute mit einem einzelnen Account arbeitet, muss nicht alles auf einmal umstellen. Der Weg zur Multi-Account-Struktur ist kein Big Bang - er lässt sich schrittweise gehen.

Zuerst die Organization anlegen und die Grundstruktur aufbauen: Security-Accounts, Log Archive, eine saubere OU-Hierarchie. Dann IAM Identity Center einrichten und bestehende IAM-User ablösen. Anschließend Workloads in eigene Accounts migrieren - neue Projekte zuerst, bestehende sukzessive.

Zwei Dinge, die man dabei im Blick behalten sollte: Erstens, nicht overengineeren. Nicht jedes Team braucht von Tag eins fünf Accounts. Schlank starten, mit den Anforderungen wachsen. Zweitens, von Anfang an eine Tagging-Strategie definieren. Auch in einer Multi-Account-Welt bleiben Tags wichtig - für Kostenzuordnung, Automatisierung und Compliance.

Fazit

Eine Multi-Account-Strategie klingt nach viel - ist aber mit den richtigen Werkzeugen und ein paar Kniffen eine solide Basis, um auf AWS nachhaltig zu skalieren. Die AWS-Bordmittel sind da und ausgereift. Mit Organizations, Org Formation, Identity Center, SCPs und CloudTrail lässt sich ein gutes Fundament schaffen, auf dem man Stück für Stück weiter aufbauen kann.

Mit ein bisschen Erfahrung und Weitblick gelingt das auch im laufenden Betrieb. Wenn du dich dazu austauschen möchtest, nimm gerne Kontakt mit uns auf 😉