Ein AWS-Konto oder mehrere: wann die Trennung sich lohnt

Ein AWS-Konto ist am Anfang die richtige Größe. Ein zweites Konto trennt an dem Tag nichts, was getrennt werden müsste. Die Frage stellt sich später, und sie stellt sich an einem konkreten Zustand.

Ich fange deshalb nicht mit einer Kontenlandschaft an. Ich fange mit einem Konto an und bleibe dabei, solange die Grenzen, die zählen, auch so halten.

Was hier eigentlich verglichen wird

Verglichen wird nicht eine Landing Zone mit einem unordentlichen Konto. Die Landing Zone ist das, was entsteht, nachdem die Entscheidung für mehrere Konten gefallen ist: Struktur, Zugang, Protokolle. Diesen Aufbau beschreibt die Seite zum Aufbau einer AWS Landing Zone. Hier geht es um die Entscheidung davor.

Die eigentliche Frage lautet: Muss eine Grenze halten, die ein Administrator im selben Konto heute überschreiten kann? Wenn nein, bleibt es bei einem Konto. Wenn ja, ist das Konto selbst die Grenze. Alles andere ist Beiwerk: Organisationseinheiten, Leitplanken, ein Werkzeug, das die Konten anlegt.

Was ein Konto schon trägt

Ein Konto ist bereits eine Grenze. Rechte, Kontingente und die Rechnung enden dort. Innerhalb dieser Grenze lässt sich vieles sauber halten, und damit fange ich an, bevor von einem zweiten Konto die Rede ist:

• Anmeldung über IAM Identity Center, Rollen je Aufgabe, keine dauerhaften Zugangsschlüssel.
• Produktion und Test in getrennten Netzen, nicht nur unter getrennten Namen.
• Rechte so eng, dass die Rolle für den Alltag die Produktionsdaten nicht löschen kann.
• Schlagworte, die in der Kostenaufschlüsselung ankommen, und eine Regel, die sie erzwingt.

Für ein Produkt, ein Team und eine Rechnung, die sich erklären lässt, ist das die ganze Lösung. Was es nicht leistet: Es hält niemanden auf, der in diesem Konto mehr darf als die Alltagsrolle. Eine Namenskonvention ist eine Absprache. Eine Rolle im selben Konto ist ein Weg zur Ressource.

Wie die Schlüssel und Rollen in einem gewachsenen Konto wieder auf eine nachvollziehbare Menge kommen, steht in IAM aufräumen in einem gewachsenen AWS-Konto.

Wann ich bei einem Konto bleibe

Ich bleibe bei einem Konto, solange diese vier Sätze stimmen.

• Es gibt ein Produkt und ein Team, das es betreiben darf.
• Wer Produktion ändern kann, soll das auch dürfen. Es gibt keinen Auftragnehmer und keine zweite Umgebung, die Produktionsdaten nicht sehen darf.
• Die Rechnung lässt sich einem Produkt zuordnen, weil die Schlagworte gehalten werden.
• Noch verlangt niemand, dass die Protokolle einen Vorfall überstehen, den derselbe Zugriff auch löschen könnte.

Zwei oder drei Leute, eine Anwendung, Test und Produktion in zwei Netzen, Zugang über Rollen. Ein zweites Konto würde eine Organisation, ein Protokollkonto, kontenübergreifende Rollen und einen Adressplan dazunehmen. Keines davon entfernt ein Risiko, das diese Umgebung heute hat.

In diesem Zustand ist ein Konto die endgültige Architektur. Es ist kein Zwischenstand, der später „richtig“ gemacht werden muss.

Was die Trennung wirklich löst

Vier Dinge. Ich trenne Konten, wenn mindestens eines davon heute nicht hält.

Die Reichweite eines Fehlers. Eine zu weite Berechtigung in der Testumgebung erreicht die Produktion, solange beides im selben Konto liegt. Getrennte Konten sind auf AWS die Grenze, die auch gegen den Administrator eines Kontos hält. Nicht gegen den der Organisation: Wer im Verwaltungskonto Administrator ist, erreicht die Mitgliedskonten über deren Zugriffsrolle. Diese Grenze ist der Kern einer Landing Zone, und sie ist die Bedingung, unter der ich diese Form anfange.

Wer wohin darf, ohne sich zu vergreifen. Rollen im selben Konto reichen, solange niemand eine Rolle hat, die beide Welten umfasst. Sobald eine Person oder eine Pipeline im Alltag in beiden Welten unterwegs ist, hängt die Trennung an Aufmerksamkeit. Ein eigenes Konto macht die falsche Welt unerreichbar.

Protokolle, die der Vorfall nicht mitlöscht. Die Trails von CloudTrail und ihre Protokolle im selben Konto kann derselbe Zugriff abschalten und löschen, der gerade etwas zerstört. Übrig bleibt die Ereignishistorie mit den Verwaltungsereignissen der letzten 90 Tage, mehr nicht. Ein Protokollkonto, in das die Anwendung nur liefern und nichts löschen kann, übersteht genau diesen Moment.

Eine Rechnung, die nicht an freiwilligen Schlagworten hängt. Schlagworte bleiben freiwillig, bis sie jemand erzwingt. In einem gewachsenen Konto sind sie es oft jahrelang nicht. Ein Konto je Produkt ist eine Zuordnung, die niemand vergisst. Solange ein Produkt die ganze Rechnung ist, brauche ich das nicht.

Wo die Rechnung innerhalb eines Kontos trotzdem aus dem Ruder läuft, steht in Schlechte Architektur schickt keine Alerts. Die Kontentrennung ersetzt diese Suche nicht. Sie macht nur sichtbar, welches Produkt den Posten verursacht.

Vier Argumente, die allein nicht reichen

„AWS empfiehlt mehrere Konten.“ Die Empfehlung beschreibt eine Organisation, die mehrere Grenzen hat. Sie beschreibt nicht die erste Woche eines Produkts. Wer sie vorher umsetzt, besitzt fünf leere Konten und dieselbe Anwendung in einem davon.

„Das Audit verlangt getrennte Konten.“ Was ein Fragebogen sehen will, ist die Trennung der Umgebungen und ein Nachweis, wer wohin kann. Eine feste Kontenzahl steht da nicht. Ein Konto mit engen Rollen und getrennten Netzen beantwortet das, solange der Nachweis stimmt. Er stimmt nicht mehr, wenn ein Administrator beide Umgebungen in derselben Sitzung erreicht und das niemand belegen kann. Dann ist ein zweites Konto die ehrliche Antwort, weil der Nachweis sonst eine Absprache bleibt.

„Wir werden wachsen.“ Wachstum ist kein Termin. Der Schnitt zahlt sich aus, wenn ein zweites Produkt, ein zweites Team mit eigenen Rechten oder ein Vertrag kommt, der eine Grenze verlangt. Vorher ist die Struktur eine Vermutung. Vermutungen betreibe ich nicht.

„Konten kosten nichts.“ Das Konto selbst hat keinen Preis. Die Struktur darum schon: AWS Config, ein zweiter CloudTrail neben dem, den die Organisation bereits schreibt, Verkehr zwischen den Konten, und jemand, der die Organisation versteht. Control Tower nimmt von diesem Aufbau Arbeit ab und hat selbst keinen Aufpreis. Die Dienste darunter haben ihn. Die Grenze der Kontenzahl ist die Verwaltbarkeit. Genau die ist der Preis.

Wie der Schnitt aussieht, wenn er fällig ist

Geschnitten wird nach der Grenze, die halten muss, nicht nach dem Organigramm. Teams ändern sich. Eine Isolationsgrenze seltener.

Die Form, die dann entsteht, ist die einer Landing Zone: Verwaltung, Protokolle, Sicherheit, Produktion, Nicht-Produktion. Das sind fünf Konten. Sie sind die Zielform, nicht die Startgröße am ersten Tag. Ich öffne sie, wenn die Entscheidung gefallen ist. Ich öffne sie nicht, damit die Entscheidung irgendwann leichter fällt.

Eine neue Organisation darf zunächst zehn Konten haben. Die Grenze lässt sich anheben und schränkt auf Dauer nichts ein. Fünf davon belegt die Landing Zone aber schon am ersten Tag. Was wirklich einschränkt: ob das nächste Konto aus einem beschriebenen Weg entsteht oder aus einem Nachmittag in der Konsole.

Ob dieser Weg über Control Tower läuft oder direkt als Infrastructure as Code, ist eine zweite Entscheidung. Sie hängt daran, wer die Umgebung danach betreibt. Die Leistungsseite sagt dazu das Nötige, einschließlich der Kehrseite. Eine Werkzeugwahl würde diesen Artikel nur länger machen.

Womit die Struktur beschrieben wird, sobald sie beschrieben werden soll, steht in Terraform oder AWS CDK.

Das Verwaltungskonto bleibt frei von der Anwendung. Service-Control-Policies, die Leitplanken der Organisation, wirken dort nicht auf Benutzer und Rollen. Das Konto, dem die Organisation gehört, ist deshalb der schlechteste Ort für das Produkt.

Was der Schnitt kostet

Eine laufende Anwendung in ein anderes Konto zu bringen ist ein Umzug, keine Einstellung. Wer schon weiß, dass die Grenze kommen wird, zieht sie vor der ersten Produktionslast. Danach werden Ressourcen neu angelegt und Daten bewegt.

Adressbereiche werden vergeben, bevor das zweite Netz entsteht. Überschneidungen zeigen sich bei der ersten Verbindung, und dann hängt Produktivlast daran.

Der Zugang wird mit der Kontenzahl nicht multipliziert. Identity Center und Rollen gelten für ein Konto wie für zehn. Jedes Konto bringt einen Root-Benutzer mit. Wer dessen Zugangsdaten in jedem Konto pflegt und dazu eigene Schlüssel anlegt, hat die Grenze gezogen und den ursprünglichen Zustand vervielfacht. In einer Organisation lassen sich die Root-Zugangsdaten der Mitgliedskonten zentral entfernen; neu angelegte Konten haben dann keine.

Pipelines holen sich Rechte über kurzlebige Tokens. Ob dahinter ein Konto steht oder mehrere, ändert die Rolle, gegen die getauscht wird, nicht die Strecke. Was in diese Strecke gehört, steht in Was eine normale Deployment-Pipeline wirklich braucht.

Die Entscheidung als Tabelle

Die Tabelle entscheidet nicht allein. Die Frage davor steht nicht in einer Zeile.

Die Frage, mit der ich anfange

Wenn jemand sagt, wir brauchen mehrere Konten, frage ich nicht nach Control Tower. Ich frage: Welche Grenze muss halten, obwohl jemand mehr darf, als er sollte?

Darauf gibt es klare Antworten. „Ein Fehler in der Testumgebung darf die Produktionsdaten nicht erreichen, und heute kann er das.“ „Die Protokolle müssen liegen bleiben, wenn das Anwendungskonto kompromittiert ist.“ „Zwei Produkte dürfen Rechnung und Administratoren nicht teilen.“ Alles tragfähig.

„Das macht man so“ reicht mir nicht. „Für später“ auch nicht.

Solange die Grenze mit Rollen, Netzen und einem Nachweis hält, bleibt das eine Konto die kleinste Lösung, die das Problem trägt. Hält sie nicht, ist der nächste Schritt die Struktur. Die entsteht auf der Seite zum Aufbau einer AWS Landing Zone, an der Umgebung, die schon läuft, ohne den Betrieb anzuhalten.