Mit der zunehmenden Nutzung von Cloud Ressourcen in AWS stehen Unternehmen vor der Herausforderung, Rechte der Cloud-Nutzung möglichst einfach zu definieren, Kosten zu kontrollieren und Security- und Compliance-Anforderungen zentral durchzusetzen. Hier ist AWS Organizations das Mittel der Wahl – mehr dazu in diesem Beitrag.
AWS Organizations bietet viele Möglichkeiten, essenzielle Aspekte der Cloud-Nutzung zentral zu kontrollieren:
Zentrales Management aller AWS-Accounts: Alle Accounts* eines Unternehmens können hier verwaltet werden (mit hinterlegten Rechnungs- und Accountinformationen). Bestehende teils historisch gewachsene Accounts lassen sich per Einladung dem Haupt-Firmenaccount hinzufügen. Durch die hierarchische Struktur ist es möglich, Sicherheits- und Compliance-Anforderungen zentral zu steuern.
Mit „Consolidated Billing“ werden die Rechnungsinformationen, welche über den Haupt- (bzw. Firmen-)Account generiert werden, konsolidiert, um sie für die interne Kostenrechnung oder aber die Weiterverwendung in AWS (z.B. im Cost Explorer) zu nutzen.
Mithilfe von Richtlinien lässt sich beispielsweise eine standardisierte Tag-Nutzung von Ressourcen etablieren oder erzwingen. Backup-Policies unterstützen das regelmäßige Backup von Ressourcen und KI-Services kann der Zugriff auf Ressourcen zum Training verweigert oder erteilt werden. Wird die Organisation erweitert, erben neue Organisationseinheiten/ Accounts automatisch die für sie geltenden Richtlinien und Rechte – eine deutliche Vereinfachung des Account-Managements.
Der Aufbau: Organisationseinheiten und Benutzer
Die Struktur von AWS Organizations dürfte Benutzern von Directory Services – wie z.B. Active Directory oder LDAP – vertraut sein: Unter dem Dach einer Root-Organisation (dem AWS Root Account) können mehrere „Organizational Units“ (OU) definiert werden, welche wiederum zwei Arten von Objekten enthalten können: „Member Accounts“, also einen direkten Account, oder weitere „Organizational Units“ (OU). OUs können beliebig ineinander verschachtelt werden.
Mit einer solchen Struktur ist es z.B. möglich, ein Unternehmen mit verschiedenen Standorten und/oder Teilbereichen (Produktion, Forschung und Entwicklung, Vertrieb) abzubilden und spezifische Richtlinien festzulegen. So darf zum Beispiel die Entwicklungsabteilung nicht auf die Produktionsumgebung des Unternehmens zugreifen, die Produktion nur Ressourcen in Europa erstellen oder die Verwaltung keine besonders teuren Ressourcen erstellen.
Möchte ein Unternehmen seine möglicherweise schon aus verschiedenen Accounts bestehende Struktur in einer gemeinsamen Organisation zusammenführen, kann es dies durch so genannte „Invitations“ an die zukünftig untergeordneten Accounts tun. Dadurch ist es möglich, auch für Accounts, die bisher nicht hierarchisch organisiert waren, die Vorteile von Consolidated Billing und zentralen Policies zu nutzen.
Policies: Tags und Services
Richtlinien, auch Policies genannt, können auf Ebene der Root-Organisation (dem Root-Account) oder den jeweiligen OUs definiert werden. Sie vererben sich jeweils nach „unten“ weiter, sofern sie nicht durch speziellere Richtlinien überschrieben werden. Auch können Richtlinien einzelnen Accounts zugeordnet werden. So ist es z.B. möglich, einer OU in Deutschland per Richtlinie nur die Nutzung von Ressourcen in Deutschland oder von bestimmten Lokationen im europäischen Ausland zu erlauben.
Policies nützen nicht nur beim Erteilen oder Entziehen von Rechten. Sie können auch dazu verwendet werden, bestimmte Konfigurationen zu erzwingen. So kann beispielsweise das Tagging von Ressourcen erzwungen und damit vereinheitlich werden. Dies ist für die genaue Zuordnung von Kosten zu verwendeten Ressourcen oder auch für das Lifecycle Management von Umgebungen unerlässlich.
Ein Beispiel für eine erzwungene Konfiguration sieht man im folgenden Screenshot: Bei der Anlage einer Ressource (hier: eine EC2-Instanz) wird überprüft, dass der Ressource ein Tag angehangen wird (im Beispiel: Tagname „Environment“) und dass diesem Tag ein gültiger Wert zugewiesen wird (im Beispiel einer der Werte „Prod“, „Test“, „Dev“ oder „Ref“).
Aber aufgepasst: Durch diese Policy wird einer Ressource bei der Anlage nicht automatisch das entsprechende Tag angehängt. Vielmehr wird kontrolliert, dass ganz unabhängig vom gewählten Deployment-Weg (IaC, ClickOps, …) ein entsprechendes Tag vergeben wurde. Ist das nicht der Fall, wird die Ressource nicht angelegt und der Prozess abgebrochen. Auch werden bestehende Ressourcen nicht geändert. Diese Policy greift also nur bei der Neuanlage von Ressourcen. Wie man überwacht, ob eine Ressource ein gültiges Tag hat, können Sie hier nachlesen.
Andere Policies können zum Beispiel die Verwendung einer speziellen Region für Ressourcen vorschreiben, aber auch hier gilt: Die Policy greift nur bei der Anlage einer Ressource – bestehende Ressourcen werden nicht automatisch in eine erlaubte Region verschoben. In unserem Beispiel handelt es sich um eine „Deny“-Policy. Der Vorgang wird also grundsätzlich verboten, es sei denn, die ausgewählte Region ist (in diesem Fall) eu-central-1, also Frankfurt.
Fazit
AWS Organizations ist ein gutes Hilfsmittel, wenn es darum geht, verschiedene AWS-Accounts (welche es vermutlich in fast jedem Unternehmen gibt) zu vereinheitlichen und unter einem zentralen Billing und Account Management zu vereinen. Dies kann bei Einführung auch ohne die Vererbung von Richtlinien geschehen (und ist auch zu empfehlen). Danach können Richtlinien (Policies) und Services auf die Organisation ausgerollt werden.
Neue Accounts, welche unter bestehenden OUs angelegt werden, erhalten automatisch die für diese OU geltenden Rechte und Richtlinien. Dies vereinfacht das Account Management ungemein. AWS Organizations ist zudem „free to use“, erzeugt also keine Extra-Kosten in der Cloud-Nutzung. Lediglich Services, welche auf AWS Organizations zugreifen, können weitere Kosten verursachen.
* Anm.: In diesem Artikel wird mehrfach auf so genannte „Accounts“ verwiesen. Dieser Begriff bezieht sich hier lediglich auf „AWS-Accounts“, für die ein „Root“-Account (Stammbenutzer) definiert wurde. Diese unterscheiden sich von den so genannten „IAM-Accounts“ (oder IAM-Benutzern), also den Benutzer-Accounts.
Alle Beiträge unserer Blogserie zu den System-Management-Tools von AWS:
Teil 1 – Cloud Umgebungen managen mit AWS Systems Manager
Teil 2 – Compliance in der AWS-Cloud überwachen mit AWS Config
Teil 3 – Accounts strukturieren mit AWS Organizations
Teil 4 – Container erfolgreich überwachen mit AWS CloudWatch
