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 er einen Bucket nicht löschen durfte oder eine Policy bearbeiten. 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 dagegen geben jedem Workload seinen eigenen Satz an Quotas.

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 und ist im Prinzip schnell erklärt: 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 sieht schlanker aus, als man denkt: Eine Security OU für Log Archive, Security Tooling und alles, was mit Auditierung zu tun hat. Eine Produktions-OU für produktive Workloads und globale Ressourcen wie DNS oder Shared Networking. Und eine Dev/Sandbox OU für Entwicklung, Experimente und nicht-produktive Workloads. Drei OUs, klare Trennung - und von da aus kann man jederzeit weiter ausdifferenzieren, wenn es nötig wird.

Das Schöne daran: Der Overhead ist minimal, die Struktur bringt echte Vorteile und wächst einfach mit. Neue Accounts sind in wenigen Minuten provisioniert und ready to go - und die Trennung v on Kosten, Berechtigungen und Risiken ist von Anfang an eingebaut.

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 lässt sich die gesamte Org-Struktur als Code verwalten - versioniert, reproduzierbar und automatisierbar.

IAM Identity Center (ehemals AWS SSO) löst eines der häufigsten Probleme: 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 im Einsatz hat, bindet es über SAML oder OpenID Connect 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ür Landing-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 😉