Puh, versucht man sich in die AWS Multi Account Strategie einzulesen oder diese sogar mittels AWS Control Tower, Organizations und Single Sign On (SSO) umzusetzen, muss man mit vielen AWS-spezifischen Begriffen kämpfen. Deshalb unternehme ich hier den Versuch, es allgemein verständlich zu erklären. Das hilft mir hoffentlich, es selbst zu verstehen („nur was man erklären kann, hat man verstanden“).

Was sind AWS Accounts?

Früher (vor 10 Jahren) war die Welt noch einfach, auch bei AWS. Ich habe mich mit meiner Emailadresse registriert, den gewünschten Service wie S3 ausgewählt und konfiguriert und konnte loslegen. Genau dieses Konto, das ich dazu eröffnet habe, ist ein AWS Account bzw. AWS Konto.

Wollte ich in der Vergangenheit weiteren Nutzern Zugriff auf mein Konto geben, habe ich für diese so genannte IAM Nutzer angelegt und mit Rechten ausgestattet. In IAM kann ich natürlich auch Gruppen definieren und Nutzer diesen zuordnen. Mit diesen Mechanismen komme ich schon recht weit und kann durchaus mit mehreren Entwicklern gemeinsam arbeiten.

Warum sollte man mehrere AWS Accounts verwenden?

Amazon empfiehlt ein Multi Account Setup für AWS zu verwenden, wenn man AWS tatsächlich einsetzen will. Aus meiner Sicht sind die wichtigsten Argumente:

• klare Sicherheitsabgrenzung, da AWS Ressourcen (wie ein S3 Bucket) immer zu genau einem Account gehören
• klare Kostenzuordnung, da die AWS Ressourcen immer in dem AWS Account Kosten verursachen, zu dem sie gehören
• AWS Accounts können auf unterschiedliche Anforderungen zugeschnitten werden, etwa Hosting einer Webanwendung in EC2 Instanzen (also in virtuellen Maschinen) vs. Betrieb einer Serverless Anwendung
• Nutzerrechte und Zugriff lässt sich viel sauberer trennen, wenn Nutzer nur auf die AWS Accounts Zugriff haben, in denen sie auch arbeiten müssen

Gerade in großen Organisationen, in denen AWS für ganz unterschiedliche Zwecke genutzt wird und in denen eine Kostenzuordnung zu Abteilungen und Projekten notwendig ist, ist der Einsatz mehrerer Accounts absolut sinnvoll.

Einfach unabhängige AWS Accounts nutzen?

An diesem Punkt bin ich davon überzeugt, dass der Einsatz mehrerer AWS Accounts absolut sinnvoll ist. Auch bei kleineren Projekten möchte ich nicht jedem Entwickler Zugriff auf die Produktionsumgebung geben und bin froh, wenn es zwischen Entwicklung und Produktion eine klare Trennung gibt (und wenn ich erst an DSGVO denke, dann…).

In der Vergangenheit hätte ich einfach weitere AWS Accounts angelegt. Das haben in der Vergangenheit auch viele Organisationen getan. Das führte dann zu einer Vielzahl von Rechnungen, da für jeden AWS Account eine eigenen Rechnung erstellt wurde. Deshalb hat Amazon dann frühzeitig das Consolidated Billing Feature erfunden. Alle aufgelaufenen Kosten konnten von einem zentralen Account übernommen werden. Schön ist auch, dass Mengenrabatte über alle Accounts ermittelt werden, was zu beachtlichen Einsparungen führen kann.

Ein weiteres Problem mit mehreren AWS Accounts ist Nutzerzugriff. Ich muss für jeden menschlichen Nutzer einen IAM Nutzer in jedem Account erstellen, auf den er Zugriff haben soll. Das wird ganz schnell ganz schön aufwendig. Hinzu kommt, dass ich auch jeden IAM Nutzer in jedem AWS Account löschen muss, wenn der zugehörige Mensch die Firma oder das Projekt verlässt.

In großen Firmen kommt noch das beliebte Thema Compliance hinzu. Wie kann zum Beispiel eine europäische Firma sicherstellen, dass alle AWS Ressourcen immer nur in europäischen AWS Rechenzentren (also in europäischen AWS Regionen) angelegt werden? Da werden jedem Compliance Verantwortlichen ganz schnell die Haare grau :-)

AWS Organisationen

Die Lösung für das Problem ist der Dienst AWS Organization. Damit kann ich eine Organisation anlegen und in Organisationseinheiten gliedern. Jeder Organisationseinheit kann ich wiederum einen oder mehrere AWS Accounts zuordnen.

Ich kann Organisationseinheiten oder sogar einzelnen AWS Accounts so genannte Service Control Policies (SCP) zuweisen. Mit diesen Policies kann ich die maximal verfügbaren Rechte definieren, die Objekten in einer Organisationseinheit zur Verfügung stehen. Verweigere ich zum Beispiel das Recht EC2 Instanzen anzulegen, kann niemand in der Organisation, auch kein Administrator, eine EC2 Instanz anlegen.

Amazon verwendet einige sehr spezielle Begriffe für Organisationseinheiten. So wird zum Beispiel der Begriff Workload verwendet. Der Betrieb einer Web Applikation ist solch ein Workload. Da ich für eine Web Applikation mindestens eine Entwicklungs- und eine Produktionsumgebung benötige, würde ich 2 Organisationseinheiten mit 2 unabhängigen AWS Accounts anlegen:

• Workload_MyWebApp_SDLC (SDLC steht für Software Development Lifecycle und taucht häufig in der AWS Dokumentation auf)
• Workload_MyWebApp_Prod

Theoretisch können Organisationseinheiten in bis zu 5 Ebenen unterteilt werden, aber das wird vom AWS ControlTower Service nicht unterstützt, den ich weiter unten erkläre. Deshalb lege ich die Organisationseinheiten direkt unter der Wurzelorganisation an und deute über Namenskonventionen die Hierarchie an.

AWS SSO

Das aus meiner Sicht cleverste Konstrukt in der AWS Multi Account Strategie ist der AWS SSO (Single-Sign On) Service. Dies ist ein Verzeichnisdienst. In diesem kann ich Nutzer erstellen und diese in Gruppen organisieren und mit Berechtigungen (Permission Sets) versehen.

Anschließend ordne ich diese Nutzer mit ihren Gruppen den einzelnen Organisationseinheiten zu. So würde ich etwa alle Nutzer der Gruppe „Entwickler“ meiner Workload_MyWebApp_SDLC Einheit mit Administrationsrechten zuordnen. Einzelne wenige Nutzer, die auch für den Betrieb verantwortlich sind, würde ich in einer zusätzlichen Gruppe „Betrieb“ zusammenfassen und dieser Gruppe auf die Einheit Workload_MyWebApp_Prod mit den notwendigen Rechten zuweisen. Es versteht sich von selbst, dass ein Nutzer mehreren Gruppen angehören kann.

Loggt sich ein Nutzer mittels AWS SSO ein, wählt er während des Logins aus, auf welche Organisationseinheit er zugreifen möchte. Natürlich hat der Nutzer nur jene Einheiten zur Auswahl, für die er berechtigt ist. AWS sorgt im Hintergrund dafür, dem Nutzer Zugriff auf den entsprechenden AWS Account zu geben.

Damit das funktioniert, werden in jedem Account im AWS IAM Service Rollen erstellt. Nachdem ich mich eingeloggt und eine Organisationseinheit ausgewählt habe, wird mir die entsprechende Rolle zugewiesen. Deshalb unterscheidet sich der in der AWS Console angezeigte Nutzername je nach aktuellen Account und Berechtigung.

AWS SSO kann ich natürlich auch mit vorhanden Directory Services wie Microsoft Active Directory koppeln. Dann kann ich die Zuordnung von Nutzern zu Gruppen in den gewohnten Tools vornehmen. Details gibt es in einer AWS SSO Demo von der re:invent 2019 Konferenz.

Umsetzung AWS Multi Account Strategie mittels AWS ControlTower

An dieser Stelle mag der geneigte Leser einwenden, falls noch nicht eingeschlafen, dass sich das alles sehr aufwendig und kompliziert anhört. Ganz ehrlich – das ist es auch. AWS ist inzwischen eine höchst komplexe Plattform, vergleichbar mit Salesforce und SAP.

Für das Aufsetzen und die Verwaltung einer AWS Multi Account Strategie bietet sich AWS ControlTower als Hilfsmittel an. Dieser Service generiert die notwendige Basisorganisation, Accounts für Auditoren und Logzugriff sowie einige SCPs (Service Control Policy) und einen passend konfigurierten AWS SSO Dienst.

Diese Grundkonfiguration bezeichnet Amazon als Landing Zone, also als Ausgangsbasis für alle weiteren Account Arbeiten. Über AWS ControlTower kann ich weitere Organisationseinheiten und Accounts anlegen. Das geht recht konfortabel. Wichtig: AWS ControlTower unterstützt keine verschachtelten Organisationseinheiten!

Im ControlTower kann ich weiterhin so genannte Guardrails aktivieren. Diese prüfen regelmäßig, ob alle Organisationseinheiten und die zugehörigen Accounts meinen Vorgaben entsprechen. In einer Übersicht sehe ich, ob es Verstöße gegen meine zentralen Richtlinien gibt.

Hätte ich bereits bestehende Accounts oder Organisationseinheiten, könnte ich diese in AWS ControlTower übernehmen. Ab diesem Zeitpunkt sollte ich die Accounts und Organisationseinheiten aber nicht mehr manuell ändern.

Durchgängige Dokumentation: Fehlanzeige

Die offizielle AWS Dokumentation bezieht sich immer auf einzelne Services wie AWS ControlTower oder AWS Organization. Prinzipiell ist diese Dokumentation in Ordnung und gut, aber es fehlt an vielen Stellen der Gesamtüberblick.

Viele deutsche Übersetzungen der AWS Dokumentation sind maschinell erstellt und lesen sich holprig. Tatsächlich benutze ich die AWS Oberfläche und Dokumentation nur noch auf Englisch, um mich nicht durch ungelenke Übersetzungen weiter zu verwirren.

Eine erwähnenswerte Ausnahme ist die Seite „Get Started with AWS for Production Workloads„. Diese umfassende Anleitung führt schrittweise durch das Aufsetzen einer Multi Account Strategie unter Verwendung von AWS ControlTower. Die Seite wird wohl auch von Amazon gepflegt, ist aber nicht in die normale Dokumentation integriert und wird auch nirgends verlinkt. Ich bin nur durch Zufall darauf gestoßen.

Fazit

Die AWS Multi Account Strategie ist ein logischer Entwicklungsschritt. AWS ist nicht mehr die einfache Plattform der ersten Jahre, sondern ein hochkomplexes Gebilde. Entsprechend komplexer sind die Werkzeuge und Vorgehen, um solch eine Plattform zu nutzen und zentral zu verwalten. Wildwuchs wird es trotzdem geben :-)

In großen Firmen beschäftigen sich einzelne Mitarbeiter nur mit der Verwaltung der AWS Accounts und der Umsetzung von Compliance Anforderungen. Hier ist die Multi Account Strategie das aktuell richtige Vorgehen.

Für kleine Firmen und Startups ist die MultiAccount Strategie eine Herausforderung. Speziell die verschiedenen Begriffe und Dienste sind nicht selbsterklärend und bedürfen einer Einarbeitung. Ich nehme die von AWS ControlTower generierte Struktur erst mal hin und hoffe, dass sich mir alle Details zu einem späteren Zeitpunkt voll erschließen :-)

Dieser Beitrag wurde am 19.02.2021 um 19:44in der Kategorie Software Engineering veröffentlicht. Kommentare können per RSS 2.0 Feed abonniert werden. Sie können ein Kommentar schreiben oder einen Trackback von ihrer Seite hinterlassen.

Ein Kommentar to “AWS Multi Account Strategie”

1. GIT für AWS CodeCommit Repo einrichten sagt:

   20. Februar 2021 um 11:19 Uhr

   […] letzten Beitrag habe ich die AWS MultiAccount Strategie erläutert. Für das Login nutze ich nur noch Single-Sign On Nutzer, die über IAM Rollen Zugriff […]