Philipp Koch
Partner Principal Architect
Man hört immer nur: „Wir wollen in die Cloud!“ …“Wir sind auf AWS!“ …“Über Infrastructure as Code können wir schnell und dynamisch unsere Umgebungen aufsetzen.“
Das ist alles natürlich richtig und gut, aber es gibt einen Spielverderber, den viele Projekte nicht auf dem Schirm haben: Für ein professionelles AWS-Setup wird einiges an Grundinfrastruktur benötigt.
Eine zentrale Frage ist dabei, wie viele Accounts benötigt werden. Kann man alles in einem Account machen oder ist es sinnvoll, hierfür mehrere zu verwenden? Entspricht das Setup den Anforderungen eines Unternehmens in den Punkten:
– Sicherheit
– Nachvollziehbarkeit
– Compliance?
Wie schnell und unkompliziert können neue Accounts für Entwickler und Projekte erstellt werden? Gibt es ggf. sogar eine Best-Practices-Setup?
In meinem Vortrag im Kontext der Senacor „StreamedCon“ zeige ich euch, wie wir das Ganze im Rahmen unseres InnovationLabs für Senacor aufbauen wollten und wie wir daran gescheitert sind. Aber vor allem auch, was man daraus lernen kann! Alle die eher an einer schriftlichen Zusammenfassung interessiert sind, lesen bitte einfach unten weiter.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube (USA). Mehr erfahren
Mit einem Klick auf dieses Vorschaubild willigen Sie ein, dass Inhalte von Google (USA) nachgeladen werden. Hierdurch erhält Google (USA) die Information, dass Sie unsere Seite aufgerufen haben sowie die in diesem Rahmen technisch erforderlichen Daten. Wir haben auf die weitere Datenverarbeitung durch Google keinen Einfluss. Bitte beachten Sie, dass in Bezug auf Google (USA) kein angemessenes Datenschutzniveau vorliegt. Weitere Informationen finden Sie in unserer Datenschutzerklärung.
Wozu braucht man AWS Organizations?
Wenn man meine Einleitung gelesen hat, kommt sicherlich die Frage auf, was sind denn diese AWS Organizations und warum sind sie relevant? Vielleicht ist es dazu hilfreich, erst einmal einen Schritt zurückzugehen und sich anzusehen, wie AWS strukturiert ist.
AWS Account
Der zentrale Einstieg in die Welt von AWS ist der AWS-Account. Damit ist kein Nutzer-Account gemeint, sondern eine Organisationseinheit. An dieser Organisationseinheit sind alle relevanten Informationen hinterlegt wie:
• eine eindeutige und einzigartige Root-Email Adresse
• die Kreditkarte für die Abrechnung
• der Supportvertrag
• das AWS Identity and Access Management (IAM), welche die eigentlichen Benutzer und Rollen sowie deren Rechte beinhaltet.
Der eigentliche Workload wird in Virtual Private Clouds (VPCs) ausgeführt, welche bestimmten Regionen zugeordnet sind. Dabei kann ein Account mehrere VPC beinhalten, welche auf verschiedene Regionen verteilt sein können. Zu beachten ist jedoch, dass die Benutzer mit ihren Rollen und Rechten auf alle VPCs und deren Infrastrukturkomponenten gleichberechtigt zugreifen können. Auch werden alle Komponenten des Account über dieselbe Kreditkarte abrechnet.
Ein Account ist nicht genug
Grundsätzlich lässt sich mit so einem einzelnen AWS Account natürlich ein ganze IT Organisation abbilden. Allerdings wenn man sich vor Augen hält, wie viele Projekte eine IT Organisation umfasst und dass diese meist noch mehrere Stages wie eine PreProd und Prod besitzen, kommt man hier schnell an seine Grenzen.
Die drei wesentliche Nachteile an diesem Konstrukt sind:
– die Abrechnung
– Security Belange
– der Blast Radius.
Abrechnung
Einzelne Komponenten und damit Projekte sind in der Abrechnung nur schwer voneinander zu trennen. Es gibt Lösungen, die über die Verwendung von Tags bestimmte Kostenstellen markieren. Dies ist aber fehleranfällig und aufwendig.
Security Belange
Da Benutzer und Rollen und deren Rechte nur pro Account eingegrenzt werden können, ist eine feingranulare Trennung der Zugriffe auf einzelne Projekte oder Stages eines Projektes nicht möglich. Dies stellt ein hohes Sicherheitsrisiko dar und verletzt in der Regel das Need-to-Know-Prinzip.
Blast Radius
Dadurch dass VPCs nur eine schwache Trennung voneinander haben und den gleichen Rechten und Limits unterliegen, kann ein Fehler weitreichende Auswirkungen haben. Beispielsweise kann ein Problem auf einer PreProd Umgebung alle anderen VPCs unter anderen Prod Umgebungen betreffen.
Beispiel 1: Durch ein Autoscaler Experiment werden die Limits von bestimmten EC2 Instanzen aufgebraucht, dadurch können produktive System nicht mehr skalieren und geraten in Lastprobleme.
Beispiel 2: Durch Manipulation im IAM werden zentralen Rollen die Rechte entzogen und mehrere Anwendungen, welche diese als Servicerolle verwenden, funktionieren nun nicht mehr.
AWS Organizations bringen die Lösung
Um diese Probleme zu lösen, kommen die AWS Organizations ins Spiel. Ein Grundprinzip hier ist, dass mehrere Accounts für die verschiedenen Belange wie Projekte oder Stages eines Projekts verwendet werden. Somit sind diese sauber buchhalterisch und auf der Rollen-Rechte-Ebene technisch getrennt. Dadurch ist der Blast Radius auf nur einen Account und damit einen kleinen Teil der Organisation beschränkt.
Um keine große Anzahl von AWS Accounts einzeln managen zu müssen, ist die AWS Organizations vorhanden. Über AWS Organizations gewinnt man einen gemeinsamen Blick auf den einzelnen Account und es werden Möglichkeiten geboten, diese zentral zu verwalten. So werden Zahlungsinformationen zentral hinterlegt und je nach Plan ein zentraler Support bestellt.
Dabei dient ein Account als sogenannter Root-Account. Dieser beinhaltet die zentralen Zahlungs- und Supportinformationen sowie die AWS Organizations an sich. Ansonsten wird dieser Account nicht für Workloads verwendet.
In der Organisation lassen sich Accounts nun über sogenannte Organizational Units (OUs) in beliebiger Hierarchie zusammenfassen. Allerdings empfiehlt sich hier eher eine flache Hierarchie zu verwenden. An den OUs können wiederum Service Control Policies (SCP) hinterlegt werden, diese gelten für den gesamten darunterlegenden Ast und können im Account auch nicht überschrieben werden. Dies kann gut verwenden werden, um Complianceregeln zu definieren.
Die Landing Zone als Best Practice für die Automatisierung
Schaut man sich das reine Konstrukt von AWS Organizations an, stellt man schnell fest, dass dies zum einen schon eine gewisse Komplexität mit sich bringt, aber viele Aspekte für eine „Enterprise Ready Cloud“ noch nicht abgebildet sind. Glücklicherweise gibt es hier mittlerweile mit dem Konstrukt der Landing Zone ein Best-Practice Vorgehen und Setup, welches die meisten Probleme adressiert und umsetzt.
Idee ist hier, dass der Root-Account gleichzeitig genutzt wird, um eine zentrale Automatisierungspipeline zu erstellen. Diese kann über eine zentrale Konfiguration angepasst werden und verwaltet die Accounts und deren Konfiguration. Zudem kann mit AWS SSO ein zentraler SSO-Dienst angebunden werden, welcher ein einheitliches und zentrales Login und Benutzer-Management für alle Accounts darstellt.
Zusätzlich sind in einer Core-OU weitere Accounts für globale Belange der IT Organisation vorhanden. So werden beispielsweise im Logging-Account sämtliche CloudTrail Logs aller Accounts gesammelt und bereitgestellt. Auf diese Informationen kann von Security Accounts aus zugegriffen und darüber analysiert werden.
Zentrale Dienste können zudem in einem sogenannten Shared Services Account bereitgestellt werden.
Neue Accounts werden durch Erweiterung des „desired state“ in der Konfiguration z.B. durch den IT-Support beschrieben und darauf folgend durch die Pipeline erstellt.
AWS Control Tower vs. AWS Landingszone Solution vs. X
AWS selbst bietet zwei Wege eine Landing Zone aufzusetzen:
- AWS Control Tower
- AWS Landing Zone Solution
Daneben gibt es auch noch andere Wege, eine Landing Zone zu definieren – für mich am bekanntesten ist die Lösung von Grundworks. Allerdings wird sich dieser Artikel nur mit den AWS Lösungen beschäftigen.
AWS Control Tower
Der AWS Control Tower ist ein Managed Service von AWS und soll den ganzen Prozess rund um das Managen der Landing Zone und AWS Organizations abbilden. Dabei ist der Control Tower eine sehr leichtgewichtige Lösung, die ein bestimmtes Standard-Szenario abdeckt. Sie ist dabei aber wenig flexibel und erweiterbar.
Vorteile:
• Schnelles Setup (mit einem komplett neuen Account)
• Komplett von AWS betrieben
• Verwendet guten Standard für das Aufsetzen der Landing Zone
• Gute Integration in Tools wie AWS SSO etc.
Nachteile:
• Sehr eingeschränkte Möglichkeiten zur Erweiterbarkeit
• Integration vorhandener Accounts nicht möglich
• Reduktion der Kosten durch Deaktivieren bestimmter Services nicht möglich
• Schwer zu Debuggen
Aus meiner Sicht ist der Control Tower eher für kleine Firmen und Start-Ups geeignet, welche selbst wenig Infrastruktur mit sich bringen und mit dem Standardweg von AWS gut klar kommen.
AWS Landing Zone-Solution
Die AWS Landing Zone-Solution ist eine bereitgestellte Lösung von AWS, welche jedoch unter Anleitung vom Kunden selbst in einem Account installiert und betrieben werden muss. Die Lösung basiert auf Cloud Formation Skripten und kann vollumfänglich modifiziert werden. Allerdings ist für das Aufsetzen dieser Solution eine Beratung (kostenlos) durch AWS nötig, in welche die Solution im Rahme eines Workshops/Schulung aufgebaut wird. Eine Alternative ist, dass eine zertifizierter Dienstleister diese Solution aufsetzt und konfiguriert, da anderenfalls kein Support geleistet wird.
Vorteile:
• Sehr flexible Lösung, eine volle Anpassbarkeit ist gegeben
• Verwendet guten Standard für das Aufsetzen der Landing Zone
• Kosten können durch das Weglassen von Services reduziert werden
• Nach dem Workshop steht einem eine gute Dokumentation zur Verfügung
• Durch die längere Verfügbarkeit der Solution hat diese eine hohe Reife
Nachteile:
• AWS selbst oder ein entsprechender Partner sind erforderlich
• Sehr komplexe Lösung, welche schwer zu verstehen ist
• Es wird ein Team benötigt, um diese aufzusetzen und langfristig zu betreiben
Basierend auf diesen Vor- und Nachteilen, ist die AWS Landing Zone Solution für mich die passendere Lösung, wenn es darum geht „Enterprise-Ready“ Cloud Umgebungen aufzubauen.
Vorkehrungen für eine gelungenes Aufsetzen
Aufgrund der Erfahrungen haben sich folgende Best Practices ergeben. Diese sollten für einen erfolgreichen Aufbau eine Landing Zone beachtet werden:
Gute Planung:
• Kontaktieren Sie ihren AWS Account Manager sehr früh (mindestens einen Monat vorher)
• Planen Sie den Workshop „Landing Zone Immersion Day“ mit dem Start des Projektes
• Erstellen Sie den Root-Account eine Woche vorher
• Planen Sie genügend Zeit für die Erstellung der Landing Zone ein.
Was sollte man vorher bedenken:
• Sollen die VPCs mit dem Firmennetzwerk verbunden werden?
• Welche IP Ranges können für die AWS Accounts reserviert werden?
• Wie groß sind die IP-Ranges der VPCs dimensioniert?
• Wie kannst du die Einzigartigkeit der Root-Emails pro Account behandeln (z.B. durch die Verwendung von Email Aliase)
• Was könnte eine gute Struktur der OUs in der Organisation sein.
Fazit
Der Aufbau einer AWS Organizations mit Hilfe einer funktionierenden Landing Zone ist der Schlüssel für eine funktionierenden Cloud Infrastruktur, welche den Bedarfen eines Unternehmens gerecht wird. Da hier Basisarbeit geleistet wird, ist dies oft ein Projekt an sich und sollte vom Umfang her nicht unterschätzt werden. Richtig umgesetzt profitieren folgend aber alle Projekte von einem einheitlichen Setup ihrer Cloud Infrastruktur, in welche dann innerhalb der Regeln des Konzerns eine freie Entfaltung möglich ist. So kann man von den Vorteilen der Cloud profitieren ohne in übliche Falle bezüglich der Security und Compliance zu tappen.
Auch ist zu bedenken, dass so eine Infrastruktur nicht einmal angelegt wird und dann funktioniert. In der Regel muss diese betreut, überwacht und optimiert werden, sodass idealerweise ein eigenes Team dafür verantwortlich ist.
Ein erfahrener Partner oder die enge Zusammenarbeit mit den AWS Solution Architekten sind dabei ein Schlüssel zum Erfolg!