Multiaccount-Strategie mit AWS

Zuletzt aktualisiert am 25. Oktober 2022

Am Anfang war der AWS Account: Der AWS Account ist die allumspannende Hülle, in dem deine gesamte Umgebung mit allen Ressourcen, Abrechnungsinformationen und alles rund um Zugriff und Berechtigung lebt. 

Aber wenn doch dein Account alles beinhaltet, warum solltest Du dann mehr als einen haben wollen? 

Gibt es Gründe dafür oder dagegen? 

Das erwartet dich:

• Schatten IT 
• Entitäten bei feindlicher Übernahme
• Weil wir‘s können 
• Accounts nach Zuständigkeiten 
• Same same – but different 
• Rapid prototyping 
• Aber wo bekomme ich jetzt eine Armee trainierter Affen her? 
• Fazit 

Schatten IT 

Schauen wir doch erst einmal, wie man „aus Versehen“ zu mehreren Accounts kommt. 

Seit wir Tower-PCs unter Schreibtischen stehen haben, wo mal eben die neue Version des Abrechnungstools bereitgestellt wird, ist die Schatten IT ein Dorn im Auge eines jeden ITlers. 

Der große Segen der Cloud ist der, dass man sich mal eben schnell einen Account erstellen kann. Hierfür ist nur eine Kreditkarte nötig und man kann direkt loslegen – größtenteils for free. Doch das kann auch schnell zum Fluch werden. 

Jede Fachabteilung erklickt sich mal eben einen AWS-, Azure- oder Google-Account. Vielleicht auch einen zweiten oder dritten. Denn: Kommunikation ist ja so eine Sache. „Wir wollen nur schnell etwas ausprobieren“ – so fängt jeder gute IT-Horrorfilm an. Abgesehen von den Problemen, die Compliance und Security von unbekannten Accounts unter einen Hut zu bekommen, ergeben sich meist auch organisatorische und finanzielle Nachteile. 

Man hat natürlich eher die Chance, über Enterprise Agreements besondere Rabatte und organisatorische Vorteile zu erzielen, wenn man alle Accounts seiner Firma benennen und konsolidieren kann. Die Masse überzeugt hier einfach. Außerdem kann man leichter die Compliance und Security gleichziehen, wenn man weiß, wo man die Richtlinien anwenden muss. 

Entitäten bei feindlicher Übernahme

In der heutigen Zeit passiert es öfter, dass Firmen aufgekauft und eingegliedert werden. Jede Entität hat natürlich eine eigene funktionierende IT. Vielleicht auch viele Fachabteilungen mit Kreditkarte. Jeder bringt also neben Mitarbeitern und Marotten auch seine eigenen Cloud-Accounts mit. Diese sollten dann aus bereits erwähnten Gründen konsolidiert werden. Es hat sicher jeder schon mal etwas von Harmonisierung der IT gehört. 

Aus eigener Erfahrung muss ich sagen: es ist nicht einfach, alle AWS-Accounts eines global agierenden Unternehmens mit verschiedenen Entitäten weltweit zu konsolidieren. Accounts wurden vielleicht unter alten Firmennamen eröffnet. Jede Entität hat mindestens einen eigenen Ansprechpartner bei AWS. Und von den politischen Empfindlichkeiten der einzelnen Account Besitzer wollen wir gar nicht sprechen. Von Harmonie ist da nichts zu spüren, es könnte einem ja etwas weggenommen werden. 

Weil wir‘s können 

Aber wenn man nun gar nicht dazu gezwungen wird – will man dann eventuell mehrere AWS Accounts aus freien Stücken erstellen, da es möglicherweise doch Vorteile bietet? 

Es gibt in der Tat sehr interessante Gründe, sich für mehr als einen Account zu entscheiden. 

Hier mal ein paar Anregungen: 

Accounts nach Zuständigkeiten 

Es ist ja nicht verwerflich, dass man für bestimmte Tools, Daten oder Versionen von Applikationen, verschiedene Befugnisse und Verantwortungen hat. Wir haben am Anfang bereits festgestellt, dass sich in einem Account die Authentisierung und Autorisierung befindet. Von Haus aus kann eine Ressource aus dem einen Account nicht auf die Ressource aus einem anderen Account zugreifen. Interessant ist das zum Beispiel für Datenbanken in Entwicklung und Produktion. Die Bereitstellung, Konfiguration und Verwaltung sind aber in beiden Accounts identisch. Nur eine der Umgebungen ist aber produktiv. 

Eine andere Möglichkeit ist, die Accounts nach Computing, Netzwerk, Security, Backup, Monitoring etc. zu unterscheiden. (Nach einer Cloudmigration gibt es ja sicher einige IT Fachabteilungen, die ihre Zuständigkeiten nicht verlieren wollen.) 

Ich glaube es ist nicht schwer, noch das ein oder andere Beispiel im Day to Day Business zu finden. 

Same same – but different 

Ja wir gehören zwar alle zur selben Unternehmensgruppe, haben aber vielleicht andere Firmennamen, Rechnungsadressen oder Kostenstellen. 

Warum soll die Buchhaltung Rechnungen umständlich “auseinanderfieseln” müssen? Tagelange Diskussionen per SAP welche Teile von welcher Kostenstelle getragen werden sollen, oder umständliche Weiterverrechnungen an die Tochterunternehmen, ist definitiv kein Cloud-Lifestyle. Zwar kann man Kostenstellen und dergleichen schon lange über Tags abbilden, aber da Abrechnungsinformationen und damit auch die Rechnungsadresse und UstID in jedem Account „lebt“, ist es doch leichter das alles passend auf der Gesamtrechnung zu haben. AWS macht das schon. 

Rapid prototyping 

„Ich will mal schnell was testen.“

Warum soll man aber seine Live-Umgebung riskieren, um mal schnell eine mittel komplexe Umgebung zu erstellen. Besonders beim Abräumen kann dann vielleicht aus Versehen mal die falsche EC2 Instanz gelöscht werden und schon ist der Onlineshop nicht erreichbar. Hat man sein Lab in einem eigenen Account gebaut, ist es natürlich ein Einfaches den gesamten Account zu löschen. Damit hat man sicher auch nicht die ein oder andere Ressource vergessen, die dann monatelang die Rechnung in die Höhe treibt. Ist der AWS Account gelöscht, ist auch die gesamte Umgebung darin verschwunden. 

Aber wo bekomme ich jetzt eine Armee trainierter Affen her? 

Okay, es gibt in der Tat gute Gründe mehrere Accounts zu erstellen. Aber wenn ich alles doppelt und dreifach in jedem Account erstellen und pflegen muss – wer soll das alles machen? 

Account übergreifende Verwaltung von Ressourcen ist schon seit Längerem möglich. Auch kann man schon immer Ressourcen für den jeweils anderen Account zur Verfügung stellen. Konsolidierte Rechnungen waren aber sicherlich einer der Grundsteine für AWS Organizations. Mittlerweile können über AWS Organizations ohne Weiteres auch Zugriffe, Berechtigungen und zentrale Ressourcen über Account Grenzen hinweg verwaltet werden. Der AWS Ressource Access Manager ermöglicht es unter anderem, Netze und Teile von AWS Route53 einfach zwischen Accounts zu teilen. Hier kommen in Zukunft sicher noch weitere Ressourcen hinzu. Zum aktuellen Stand sind beide Dienste sogar kostenfrei. Wenn man es geschickt anstellt, hält sich der Mehraufwand somit in Grenzen. 

Fazit 

Ob man nun durch äußere Umstände dazu gezwungen wird oder sich selbst dazu entscheidet mehrere Accounts zu betreiben: es ist unter anderem dank AWS Organizations und AWS RAM definitiv kein Beinbruch. Im Gegenteil sollte man von Anfang an darüber nachdenken, wie man seine Umgebung auf mehrere AWS Accounts verteilt. Wie erwähnt, gibt es verschiedene Treiber für die Strukturierung in verschiedene Accounts. Von Anfang an auf mehr als einen Account zu setzen, kann ich definitiv empfehlen. Wie weit man das Ganze treibt, bleibt jedem selbst überlassen. Jeden Microservice einer großen Onlineplattform in einen eigenen Account zu verbannen, wie wir es schon in der freien Wildbahn gesehen haben, ist vielleicht auch zu viel des Guten.