In diesem Beitrag tauchen wir tiefer in das Konzept der AWS-Plattform ein und sehen uns einige Best Practices und Überlegungen zum Definieren einer AWS-Multi-Account-Umgebung an.
Obwohl Best Practices eine Orientierungshilfe bieten, wird die Architektur Ihrer AWS-Umgebung maßgeblich von geschäftlichen Faktoren, individuellen Anforderungen und Ihrer strategischen Ausrichtung beeinflusst werden. Lassen Sie uns daher einige der üblichen Benefits hinsichtlich der Definition einer AWS-Account-Strategie untersuchen. Nicht jeder davon wird auf Ihren Anwendungsfall zutreffen. Letztlich müssen die unterschiedlichen Aspekte beleuchtet werden, um eine passgenaue Multi-Account-Strategie und Landing Zone zu definieren.
7 Gründe, warum Sie Ihren monolithischen AWS-Account in mehrere Accounts aufteilen sollten
1. Fördern Sie Innovation und Agilität
Mit fortschreitender Digitalisierung ist die IT-Abteilung Triebfeder für Innovationskraft und Agilität in einem Unternehmen. Um Ideen frühzeitig zu fördern, können Sie Ihren Mitarbeitern separate AWS Accounts zur Verfügung stellen. Mit breiterem Zugriff auf AWS-Services bieten diese Umgebungen mehr Freiheiten als streng kontrollierte produktionsähnliche Test- oder gar Produktionsumgebungen welche zentral verwaltet werden.
Damit nichts aus dem Ruder läuft, empfehlen wir Ihnen, für diese Art von Accounts Sicherheits-Leitplanken und Kostenbudgets einzurichten.
2. Trennung von Kundendaten
Gerade als SaaS-Anbieter stellt sich die Frage, wie unterschiedliche Kundendaten effizient voneinander getrennt werden sollen. Eine Trennung über unterschiedliche AWS Accounts zu erreichen ist vor allem dann attraktiv, wenn eine sehr einfach zu beschreibende Grenze pro Tenant erforderlich ist. Wenn Ihre Kunden besorgt über einen möglichen mandantenübergreifenden Zugriff sind, ist ein AWS-Account basiertes Isolationsmodell das überzeugendste Argument hinsichtlich Datensicherheit.
3. Explosionsradius reduzieren
Ressourcen eines Accounts sind von Ressourcen eines anderen Accounts isoliert, sogar innerhalb Ihrer eigenen AWS Organisation.
Diese Grenze bietet Ihnen die Möglichkeit, die Auswirkungen eines anwendungsbezogenen Problems, einer Fehlkonfiguration oder einer böswilligen Handlung zu begrenzen. Wenn ein Problem innerhalb eines Accounts auftritt, werden die Auswirkungen auf Workloads in anderen Konten entweder reduziert oder eliminiert.
4. Security und Compliance
Angenommen Ihre Anwendungen verarbeiten DSGVO relevante Daten, wäre es dann nicht viel effizienter, Ihren Auditor oder Pentester auf einen dedizierten Produktions-Account zu verweisen? Diese dedizierten Konten ermöglichen es den Sicherheitsteams, sich auf die notwendigen Kontrollen und detaillierten Bedrohungsmodelle zu konzentrieren, anstatt die gesamte Cloud-Landschaft zu auditieren. Dies vereinfacht nicht nur Ihren Auditierungsprozess, sondern fördert auch Innovationen durch die Nutzung weniger restriktiver Accounts in anderen Bereichen Ihres Unternehmens.
5. Unterstützung unterschiedlicher IT-Betriebsmodelle, Team- und Organisationsstrukturen
Nehmen wir an, eine Organisation möchte die Autonomie ihrer Projektteams fördern. Hier ist es sinnvoll, jedes Team innerhalb eines dedizierten AWS-Accounts zu isolieren und jedem Team eine Spielwiese oder Sandbox zum Experimentieren zu bieten. Somit kann jedes Team das für die jeweilige Anwendung optimale Betriebsmodell wählen, wie zum Beispiel Traditional Ops - CloudOps - DevOps.
Eine passend konfigurierte Landing Zone bietet Ihnen die Möglichkeit für die verschiedenen Modelle Leitplanken zu setzen.
6. Verwalten von Kosten
Viele Unternehmen haben die Anforderung, AWS-Kosten einer bestimmten Geschäftseinheit (BU), Umgebung, Anwendung oder Projektkostenstelle zuzuordnen. Eine Multi-Account-Strategie erlaubt es Ihnen, Kosten pro Account aufzuschlüsseln. Aus diesem Grund ist die Verwendung unterschiedlicher Konten für verschiedene Geschäftseinheiten und Gruppen von Workloads hilfreich, Ihre Cloud-Ausgaben einfacher zu kontrollieren, prognostizieren und budgetieren.
Darüber hinaus besteht die Möglichkeit der Kostenzuweisung durch feingranulare Berichte und Filter unter Verwendung von AWS-Ressourcen-Tags. Auch wenn diese Funktion hilfreich ist, ist sie möglicherweise nicht der einfachste Mechanismus für die Kostenzuweisung für vielseitige und umfangreiche Workloads. Außerdem ist zu berücksichtigen, dass nicht jeder Ressourcentyp Tagging für eine detaillierte Abrechnung unterstützt.
7. Verteilen von AWS Service Quotas und API request rate limits
AWS Service Quotas, auch als Limits bezeichnet, sind die maximale Anzahl von Service-Ressourcen oder Vorgängen, die für einen Account gelten. Zum Beispiel die Anzahl der Amazon Simple Storage Service (Amazon S3) Buckets.
Eventuell betreiben Sie eine High-Performance Anwendung, die Ereignisse über verschiedene ereignisgesteuerte AWS Lambda-Pipelines verarbeitet, die nicht durch Service-Limits und Schwellenwerte für die gleichzeitige Lambda-Ausführung beeinträchtigt werden sollten, weil sie von anderen Anwendungen genutzt werden. Dann haben Sie einen sehr guten Anwendungsfall, um diese Anwendung in einem spezifischen AWS-Account zu isolieren.
Die oben genannten Punkte können nicht getrennt voneinander betrachtet werden, sondern jeder Aspekt sollte bei der Abwägung des für Ihren Fall geeigneten Multi-Account-Konzepts in AWS gewichtet werden.