Diese Website nutzt Google Analytics, um den Besuch anonym auszuwerten. Ihre Daten werden nur nach ausdrücklicher Einwilligung erhoben.Datenschutzerklärung
Fast jede AWS-Umgebung fängt mit einem Konto an, und das ist am Anfang die richtige Entscheidung. Ab einer bestimmten Größe kippt sie: Produktion und Test teilen dieselben Rechte, die Rechnung lässt sich keinem Produkt zuordnen, der Zugang läuft über Schlüssel, die niemand mehr wechselt, und beim ersten Audit fehlt jede Antwort. Ich baue die Struktur nach, die von Anfang an hätte da sein sollen, ohne den Betrieb anzuhalten.
Konten getrenntZugang über SSOProtokolle zentralAlles in Terraform
Was Sie bekommen
Eine Kontenstruktur mit Begründung: welche Konten, welche OUs, wonach geschnitten
Zugang über IAM Identity Center statt Dauer-Zugangsschlüssel, mit Rollen je Aufgabe
Leitplanken, die zur Organisation passen: was verboten bleibt und warum
Zentrale Protokollierung und Verschlüsselung, mit einer Aufbewahrung, die jemand entschieden hat
Bestehende Konten aufgenommen statt neu gebaut, ohne Ausfall
Alles in Terraform beschrieben und übergeben, inklusive Anleitung für das nächste Konto
Umfang & Zusammenarbeit
Struktur und erstes Fundament als abgegrenztes Drei- bis Sechs-Wochen-Mandat, die Aufnahme bestehender Konten danach in Wellen. Der Betrieb bleibt bei Ihrem Team, dafür ist die Übergabe Teil der Arbeit.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Ein Konto ist keine Entscheidung, sondern ein Zustand.
Niemand entscheidet sich dafür, alles in ein Konto zu legen. Es fängt mit einem Konto an, weil ein zweites am ersten Tag Aufwand ohne Nutzen wäre, und dann kommt nie der Moment, an dem jemand innehält. Irgendwann liegen Produktion, Test und die Datenbank mit den Kundendaten in derselben Rechteumgebung, und die Trennung besteht aus Namenskonventionen und der Hoffnung, dass niemand sich vertippt. Das ist keine Sicherheitslücke im technischen Sinn, aber es ist die Sorte Aufbau, bei der ein einzelner Fehler den ganzen Bestand erreicht.
Der zweite Befund ist immer die Zuordnung. Wenn alle Lasten in einem Konto liegen und Tags freiwillig sind, kann niemand sagen, was ein Produkt kostet. Die Rechnung ist dann keine Steuerungsgröße, sondern eine Überraschung am Monatsende. Und weil eine Kostensenkung damit beginnt, die Kosten zuzuordnen, hängt an dieser Frage mehr als Ordnungsliebe: Ohne Kontenschnitt und Tagging fängt jede Kostenarbeit mit Archäologie an.
Der dritte Befund ist der Zugang. In gewachsenen Umgebungen gibt es Dauer-Zugangsschlüssel in Konfigurationsdateien, geteilte Anmeldedaten für den Notfall und einen Root-Benutzer, dessen Passwort in einem Passwortmanager liegt, auf den zu viele Menschen Zugriff haben. Das ist heute lösbar, ohne dass es unbequem wird: Zugang über IAM Identity Center mit Rollen je Aufgabe, und die Root-Zugangsdaten der Mitgliedskonten lassen sich zentral entfernen, statt sie zu verwahren. Neu angelegte Konten in einer Organisation haben von Anfang an keine.
Kommt Ihnen etwas davon bekannt vor?
Produktion und Test liegen im selben Konto, getrennt nur durch Namen.
Ein Kunde oder ein Wirtschaftsprüfer fragt nach Trennung, Protokollen und Zugriffskontrolle.
Niemand kann sagen, welches Produkt welchen Anteil an der AWS-Rechnung hat.
Es gibt Dauer-Zugangsschlüssel, die älter sind als das aktuelle Team.
Auf den Root-Benutzer haben mehr Menschen Zugriff als nötig.
Es gibt schon Konten, aber sie sind einzeln entstanden und folgen keinem Muster.
Was ich mache
Was dabei entsteht
01
Kontenstruktur mit Begründung
OrganizationsOUsKonten je Isolationsgrenze
Zuerst die Frage, wonach geschnitten wird. Nicht ein Konto je Team, denn Teams ändern sich, sondern je Isolationsgrenze: Produktion getrennt von allem, was nicht Produktion ist, sicherheitsrelevante Protokolle in ein Konto, an das niemand aus der Anwendung heranreicht, geteilte Dienste dort, wo sie geteilt werden. Die Kontenzahl ist längst keine Grenze mehr, bis zu tausend Konten passen in eine einzelne OU. Die Frage ist die Begründung, nicht die Menge.
02
Control Tower oder eigener Aufbau
Control TowerLanding Zone 4.0TerraformVersionswahl
Eine echte Entscheidung mit zwei richtigen Antworten. Control Tower nimmt Arbeit ab und gibt Struktur vor, dafür bleibt der von AWS ausgerollte Teil in dessen Hand, und die Landing Zone folgt einem Versionsstand, den AWS setzt. Ein eigener Aufbau in Terraform lässt mehr Freiheit und verlangt mehr Verantwortung. Ich entscheide das an Ihrem Fall und sage die Kehrseite dazu, nicht nur den Vorzug.
03
Zugang, der niemandem im Weg steht
IAM Identity CenterRollen je AufgabeRoot zentral entferntOIDC
Anmeldung über IAM Identity Center, angebunden an Ihr bestehendes Verzeichnis, mit Rollen je Aufgabe statt je Person. Dauer-Zugangsschlüssel verschwinden aus Konfigurationsdateien und werden zu kurzlebigen Sitzungen; Pipelines holen Rechte über OIDC. Und die Root-Zugangsdaten der Mitgliedskonten werden zentral entfernt statt verwahrt, mit einem beschriebenen Weg für die wenigen Aufgaben, die wirklich Root brauchen.
04
Leitplanken, die zur Organisation passen
SCPRCPDeklarative RichtlinienRegionsbegrenzung
Drei Arten, und sie tun Verschiedenes. SCPs begrenzen, was Handelnde in einem Konto überhaupt dürfen. RCPs begrenzen, was an einer Ressource erlaubt sein kann, und greifen damit auch gegen Zugriffe von außerhalb Ihrer Organisation. Deklarative Richtlinien setzen einen Sollzustand von Dienstmerkmalen und werden in der Steuerebene des Dienstes erzwungen, nicht am API-Aufruf. Wir nehmen wenige, die getragen werden, statt viele, die jemand nach drei Wochen wieder abschaltet.
05
Protokollierung, Verschlüsselung, Kosten
CloudTrailConfigKMSAufbewahrungKosten
CloudTrail auf Organisationsebene in ein eigenes Protokollkonto, Config für den Zustand, S3 mit Aufbewahrung, die jemand entschieden hat, und eigene KMS-Schlüssel, wo sie einen Unterschied machen. Dazu die unbequeme Seite: Config ist bei kurzlebigen Lasten der Kostentreiber dieses Aufbaus, und ein zweiter eigener CloudTrail-Trail neben dem verwalteten kostet doppelt. Beides wird entschieden, nicht übersehen.
06
Bestehende Konten aufnehmen und übergeben
KontoaufnahmeDrift-MeldungRunbookÜbergabe
Was schon läuft, wird aufgenommen, nicht neu gebaut: Konten kommen in die Struktur, Abweichungen werden gemeldet statt entdeckt, und die Reihenfolge respektiert das Risiko. Zum Abschluss die Dinge, die das Ergebnis haltbar machen: eine Anleitung, wie das nächste Konto entsteht, die Regel für Konsolenzugriff, ein Runbook für den Notfallzugang und eine Übergabesitzung.
Wie viele Konten haben Sie, und wonach sind sie geschnitten?
Schreiben Sie mir, wie Ihre Umgebung heute aufgeteilt ist und was der Anlass ist. Sie bekommen eine Einschätzung, bevor Sie etwas beauftragen.
Vier Schritte, und nach dem zweiten steht das Fundament. Kein Schritt setzt voraus, dass Sie den nächsten beauftragen.
SCHRITT 01
Bestandsaufnahme
Welche Konten es gibt, wie Zugang heute läuft, was protokolliert wird und welche Anforderung der Anlass ist. Ergebnis ist ein Vorschlag für die Struktur mit Begründung und Aufwand. Lesezugriff genügt.
SCHRITT 02
Fundament aufbauen
Organisation, OUs, Protokollkonto, Zugang und die ersten Leitplanken, beschrieben in Terraform. Danach existiert die Struktur, auch wenn noch keine Anwendung umgezogen ist.
SCHRITT 03
Konten aufnehmen, in Wellen
Bestehende Konten kommen in die Struktur, unkritisches zuerst. Zwischen zwei Wellen ist die Umgebung immer in einem gültigen Zustand, und jede Welle ist einzeln nützlich.
SCHRITT 04
Übergabe
Anleitung für das nächste Konto, Regeln für Konsolenzugriff und Notfallzugang, Drift-Meldung eingerichtet, und eine Sitzung mit dem Team.
Das Ergebnis
Was danach anders ist
Ein Fehler bleibt in einem Konto
Getrennte Konten sind die einzige Grenze auf AWS, die wirklich hält. Eine falsche Berechtigung in der Testumgebung erreicht danach die Produktion nicht mehr.
Die Rechnung ist erklärbar
Wenn Lasten in eigenen Konten liegen und Tags erzwungen sind, lässt sich jeder Posten einem Produkt zuordnen. Erst danach ist Kostenarbeit mehr als Raten.
Das Audit ist eine Abfrage
Wer Zugriff hat, was protokolliert wird, wie lange es liegt: Die Antworten kommen aus der Struktur und aus dem Repository, nicht aus einem Gedächtnis.
Das nächste Konto ist ein Formular
Ein neues Konto entsteht mit Leitplanken, Protokollierung und Zugang, ohne dass jemand daran denken muss. Das ist der eigentliche Gewinn, und er zeigt sich erst beim zehnten.
Produktion und Staging in zwei über Jahre gewachsenen Konten. Das erste Problem war nicht die Höhe der Rechnung, sondern ihre fehlende Erklärung: Keine Kostensteigerung ließ sich sicher einer Last, einer Datenmenge oder einer Entscheidung zuordnen. Genau diese Zuordnung ist es, die eine Kontenstruktur mit erzwungenem Tagging herstellt.
Migration eines Revenue-Reportings im neunstelligen Umsatzbereich in eine skalierbare AWS-Umgebung, bei laufendem Betrieb. Netz, Rechte und Protokollierung standen als Code, bevor die erste Last umzog.
Case Study lesen
Mit wem Sie es zu tun haben
Direkt mit mir als Freelancer. Keine Agentur dazwischen.
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, dazu die AWS-Zertifizierungen als Solutions Architect Professional und für Security. Ich baue Kontenstrukturen, die ein Audit übersteht und ein Team trotzdem benutzen kann. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
Beides ist verteidigbar, und die Antwort hängt an zwei Fragen: Wie viel Struktur wollen Sie geschenkt bekommen, und wie viel Eigenart müssen Sie abbilden. Control Tower nimmt viel Arbeit ab, richtet Protokollkonto, Leitplanken und Kontenfabrik ein und hält sie auf einem Versionsstand. Der Preis ist Bindung: Der von AWS ausgerollte Teil bleibt in dessen Hand, und Ihre Landing Zone folgt seinen Versionen. Immerhin lässt sich eine Landing Zone ab Version 3.1 reparieren und aktualisieren, ohne gleich auf die neueste Version zu springen, und mit Landing Zone 4.0 vom November 2025 sind einzelne Integrationen abschaltbar. Ein eigener Aufbau in Terraform passt, wenn Sie schon eine gewachsene Organisation, eigene Identitätsanbindung oder Anforderungen haben, die sich in Control Tower nur umgehen lassen. Beschrieben wird in beiden Fällen so viel wie möglich als Code.
Was kostet eine Landing Zone im Betrieb?+
Control Tower selbst kostet nichts, das steht so in der AWS-Preisdokumentation. Bezahlt werden die Dienste darunter: Service Catalog für die Kontenfabrik, CloudTrail für die Protokolle, Config für den Zustand, dazu S3, SNS und CloudWatch. Der Posten, der Menschen überrascht, ist AWS Config, und zwar dann, wenn viele kurzlebige Ressourcen entstehen und wieder verschwinden – AWS nennt das ausdrücklich. Der zweite ist ein selbst betriebener CloudTrail-Trail parallel zum verwalteten: Dann zahlen Sie zweimal für dieselben Ereignisse. Beides ist entscheidbar, wenn man es vorher weiß, deshalb steht es hier.
Wir haben schon zwanzig Konten, gewachsen. Müssen wir neu anfangen?+
Nein. Bestehende Konten werden in die Struktur aufgenommen, nicht ersetzt: Sie kommen unter eine OU, bekommen die Leitplanken und die Protokollierung und tauchen danach in der zentralen Sicht auf. Das läuft in Wellen, unkritisches zuerst, und zwischen zwei Wellen ist die Umgebung in einem gültigen Zustand. Was dabei regelmäßig auffällt, ist ein Konto, das niemand mehr braucht – das wird dann nicht aufgenommen, sondern geschlossen.
Wie viele Konten brauchen wir?+
Weniger als Ihnen jemand verkaufen will, und mehr als eins. Geschnitten wird nach Isolationsgrenzen, nicht nach Organigramm: Produktion getrennt von allem Nichtproduktiven, ein eigenes Konto für sicherheitsrelevante Protokolle, geteilte Dienste dort, wo sie tatsächlich geteilt werden. Ein Konto je Team klingt sauber und veraltet mit der nächsten Umstrukturierung. Die technische Grenze ist längst keine: Seit August 2024 passen bis zu tausend Konten in eine einzelne OU, und OUs dürfen verschachtelt sein.
Was ist der Unterschied zwischen SCP, RCP und deklarativen Richtlinien?+
Sie greifen an drei verschiedenen Stellen, und das wird oft vermischt. Eine SCP begrenzt, was Handelnde in Ihren Konten dürfen – sie erteilt keine Rechte, sie deckelt sie. Eine RCP begrenzt, was an einer Ressource erlaubt sein kann, und wirkt damit auch gegen Handelnde, die nicht zu Ihrer Organisation gehören; das ist der Fall, den eine SCP nicht abdeckt. Eine deklarative Richtlinie setzt keinen Rahmen um Aufrufe, sondern einen Sollzustand von Dienstmerkmalen, und wird in der Steuerebene des jeweiligen Dienstes erzwungen. Praktisch heißt das: SCP für „darf nicht", RCP für „auch nicht von außen", deklarative Richtlinien für „soll immer so eingestellt sein".
Ist das nicht einfach ein Security-Review?+
Nein, und das ist eine Festlegung. Ein Review liefert eine Bewertung, und dieselbe Bewertung gibt es bei AWS-Partnern kostenlos, teils gefördert mit Credits. Was hier entsteht, ist eine Änderung: eine Organisation mit OUs, ein Protokollkonto, Zugang über SSO, Leitplanken und Terraform-Code, den Ihr Team danach selbst weiterführt. Wenn am Ende ein Dokument stünde und sonst nichts, wäre die Seite falsch benannt.
Brauchen wir den Landing Zone Accelerator?+
Selten, und meistens nicht am Anfang. Der Landing Zone Accelerator ist für stark regulierte Umgebungen gebaut, die viele vorgefertigte Kontrollen und eine ausgeprägte Netztopologie brauchen. Er bringt entsprechend Umfang mit, und Umfang muss jemand verstehen und pflegen. Wenn Ihre Anforderung „wir müssen ein Audit bestehen und wollen unsere Konten trennen" lautet, ist eine schlanke, selbst beschriebene Landing Zone leichter zu betreiben. Wenn Ihre Anforderung ein Katalog von Kontrollen aus einem Regelwerk ist, sehen wir uns den Accelerator an.
Was kostet das, und gibt es einen Festpreis?+
Abgerechnet wird nach Aufwand, Struktur und Fundament als abgegrenztes Drei- bis Sechs-Wochen-Mandat. Ein Festpreispaket gibt es hier bewusst nicht: Zwischen einem einzelnen Konto und zwanzig gewachsenen Konten mit drei Identitätsquellen und einer bestehenden Control-Tower-Installation liegt zu unterschiedliche Arbeit. Nach der Bestandsaufnahme kann ich den Rest zum Festpreis anbieten, vorher wäre es geraten.
Übernehmen Sie danach den Betrieb?+
Nein. Ich baue die Struktur, beschreibe sie als Code und übergebe sie. Eine Kontenstruktur, deren Regeln nur ein Externer versteht, ist genau dann ein Problem, wenn es schnell gehen muss – etwa beim Notfallzugang. Was bleibt, sind Fragen, die ich gern beantworte, und keine Zuständigkeit.
Wenn die AWS-Umgebung nur noch per Hand administrierbar ist: Bestand erfassen und importieren, State sauber aufbauen, Drift beseitigen, reproduzierbare Umgebungen.