AWS-Konten sinnvoll schneiden

Wer bei AWS anfängt, hat ein Konto, und in diesem einen Konto entsteht alles: die Datenbank der Produktion, der Spielplatz für Experimente, die Rechteverwaltung, die Rechnung. Das fühlt sich am Anfang einfach an und wird genau deshalb selten hinterfragt. Der Preis dafür fällt erst später an, wenn ein falsch gesetztes Recht plötzlich auch die Produktion trifft, wenn niemand mehr sagen kann, welcher Kostenposten zu welchem Zweck gehört, oder wenn ein kompromittierter Zugang Zugriff auf wirklich alles hat.

Die Trennung in mehrere Konten ist deshalb kein Bürokratie-Aufschlag für große Organisationen, sondern eine Grundentscheidung, die früh am meisten bringt und später am teuersten nachzuholen ist. AWS selbst behandelt das Konto nicht als Abrechnungseinheit nebenbei, sondern als die wichtigste Grenze, die die Plattform kennt. Wir schauen an, warum diese Grenze so viel trägt, was das AWS Well-Architected Framework dazu sagt, und wie ein sinnvoller Zuschnitt für ein kleines Produktunternehmen konkret aussieht.

Warum überhaupt mehrere Konten

Alles innerhalb eines Kontos teilt sich denselben Rahmen für Rechte, dieselbe Sichtbarkeit und dasselbe Schicksal, wenn etwas schiefgeht. Genau deshalb entscheidet der Schnitt der Konten darüber, wie weit ein Problem reicht. Liegt die Produktion im selben Konto wie das Development, dann ist ein zu weit gefasstes Recht, ein durchgesickerter Schlüssel oder eine fehlgeleitete Automatisierung nie auf die harmlose Seite beschränkt, sondern trifft potenziell das, wovon der Umsatz abhängt.

AWS nennt in seinem Whitepaper zur Organisation der Umgebung mehrere Gründe für mehrere Konten, und sie lesen sich wie die Liste der Probleme, die ein einzelnes Konto verursacht. Konten gruppieren Arbeitslasten nach Zweck und Verantwortung, sodass klar ist, wem was gehört. Sie erlauben unterschiedliche Sicherheitskontrollen je Umgebung, weil Produktion und Development eben nicht dieselben Regeln brauchen. Sie begrenzen den Blast Radius, also die Reichweite eines Vorfalls, weil ein Problem in einem Konto nicht auf die anderen überspringt. Und sie sind die Standardeinheit, über die AWS Kosten zuordnet, weshalb getrennte Konten das Berichten, Vorhersehen und Budgetieren der Ausgaben überhaupt erst sauber möglich machen.

Der Satz „ein Konto ist die Standardeinheit der Kostenzuordnung“ hat eine direkte Konsequenz für die Support-Kosten, weil Business Support+ pro Konto abrechnet. Wie sich das auf die Rechnung auswirkt und wann sich ein aggregierter Enterprise-Plan lohnt, rechnen wir im Artikel Was AWS Support wirklich kostet mit einem Rechner durch.

Was Well-Architected dazu sagt

Das AWS Well-Architected Framework ist die Sammlung von Grundsätzen, an denen AWS gut gebaute Systeme misst, geordnet nach Säulen wie Betriebsexzellenz, Sicherheit, Zuverlässigkeit und Kostenoptimierung. Das Besondere an der Multi-Account-Strategie ist, dass sie nicht auf eine dieser Säulen einzahlt, sondern auf mehrere zugleich. Dieselbe Trennung, die die Sicherheit erhöht, verbessert auch die Zuverlässigkeit, schärft die Kostentransparenz und macht den Betrieb übersichtlicher.

AWS empfiehlt deshalb, eine Multi-Account-Strategie bewusst zu definieren, statt sie dem Zufall zu überlassen, und stellt dafür mit AWS Organizations die Klammer bereit, unter der alle Konten zentral verwaltet werden. Über Organizations laufen die konsolidierte Abrechnung, gemeinsame Leitplanken über Service Control Policies und die geordnete Gruppierung der Konten in Organisationseinheiten. Die einzelnen Konten sind damit getrennt, wo Trennung schützt, und verbunden, wo gemeinsame Steuerung hilft.

Ein sinnvoller Zuschnitt

Für ein kleines Produktunternehmen muss der Zuschnitt nicht die volle Landing Zone eines Konzerns nachbauen, aber ein paar Konten tragen von Anfang an. Wir bevorzugen mindestens fünf, und jedes hat einen klaren, nicht verhandelbaren Zweck.

Das Management-Konto ist die Spitze der Organisation und betreibt selbst keine Arbeitslast. Es hält die Organisation zusammen, führt die konsolidierte Abrechnung und trägt die organisationsweiten Leitplanken. Weil es die höchsten Rechte im gesamten Verbund hat, gehört in dieses Konto so wenig wie möglich, damit die mächtigste Stelle zugleich die am wenigsten exponierte ist.

Das Backup-Konto ist der getrennte Aufbewahrungsort für Sicherungen und Logs. Sein Sinn liegt genau in der Trennung, denn eine Sicherung, die im selben Konto wie das Original liegt, schützt nicht vor dem Fall, in dem dieses Konto selbst kompromittiert oder falsch bedient wird. Liegen Backups und zentrale Logs in einem eigenen Konto mit sehr engen Schreib- und Löschrechten, bleiben sie belastbar, auch wenn anderswo etwas brennt. AWS bündelt Logs aus diesem Grund in einem dedizierten Log-Archiv-Konto, und für ein kleines Team lässt sich diese Rolle gut mit dem Backup-Konto zusammenlegen.

Die drei übrigen Konten trennen die Umgebungen nach Reifegrad. Development ist der Ort zum Bauen und Ausprobieren, mit breiterem Zugriff, aber ohne echte Kundendaten, sodass ein Fehler dort nichts kostet außer Zeit. Staging ist die produktionsnahe Probe, möglichst identisch zur Produktion aufgebaut, damit sich zeigt, was in der echten Umgebung passieren würde, bevor es dort passiert. Production trägt die echten Kunden und Daten und bekommt deshalb die engsten Rechte und die strengste Kontrolle. Die wichtigste Grenze im ganzen Bild verläuft vor der Produktion, weil hinter ihr das liegt, dessen Ausfall wirklich weh tut.

Was das für dich heißt

Die Aufteilung in mehrere Konten ist kein Selbstzweck und kein Zeichen von Größe, sondern die Grenze, an der AWS Sicherheit, Zuverlässigkeit und Kostentransparenz zugleich aufhängt. Für ein kleines Produktunternehmen genügt ein überschaubarer Zuschnitt aus Management, Backup, Development, Staging und Production, der mitwächst, statt später mühsam nachgezogen zu werden. Wer früh sauber schneidet, spart sich die teure Entflechtung und hat nebenbei die Kosten pro Zweck im Blick. Ob es um den ersten Zuschnitt geht oder darum, ein gewachsenes Sammelkonto zu entwirren, wir ordnen das gerne gemeinsam mit dir ein.