Referenzarchitektur für AWS Multi-Account Kunden
Kunden mit einer AWS Multi-Account-Umgebung werden schnell mit den damit verbundenen Herausforderungen konfrontiert. Wie soll die Verantwortung für die Cloud auf die unterschiedlichen Organisationseinheiten übertragen werden?
Mit unserer Nuvibit-Referenzarchitektur bieten wir eine Lösung für diese Herausforderung. Die Referenzarchitektur berücksichtigt und implementiert Empfehlungen und Richtlinien aus den folgenden von AWS empfohlenen Quellen:
- AWS Landing Zone and AWS Control Tower
- Apply security services across your AWS organization
- AWS Security Reference Architecture
- Multi Account Network Architecture
Zusätzlich sind unsere Erfahrungen mit AWS Multi-Account-Umgebungen in diese Referenzarchitektur eingeflossen.
Unsere Nuvibit-Referenzarchitektur stellt die Realisierung einer Inhouse AWS Platform im Sinne von Gregor Hohpe - The Magic of Platforms [1] [2] dar und entspricht der Implementierung der Core Domains der Nuvibit Cloud Foundation, die im Blogbeitrag Nuvibit Cloud Foundation Map ausführlich behandelt werden.
In einer AWS Multi-Account-Umgebung sind nicht alle AWS-Accounts für denselben Zweck bestimmt. Um den Überblick zu behalten, teilen wir die AWS-Accounts in drei Domänen ein:
- Foundation Core
- Foundation Shared Service
- Business Workload
| Domain | Beschreibung |
|---|---|
| Foundation Core | Accounts, die Kernkomponenten der Nuvibit Cloud Foundation beinhalten und vom Cloud Foundation Core Team(s) verwaltet werden. |
| Foundation Shared Service | Accounts, die gemeinsame Dienste und Plattformen hosten (Streaming Plattform, Data Lake, Analytics Plattform, API Management) und vom Cloud Foundation Shared Service Team(s) verwaltet werden. |
| Business Workload | Accounts, auf denen alle Komponenten der Business-Applikationen gehostet werden und die vom Cloud Workload Development Team(s) verwaltet werden. |
Die folgende Grafik dient als Beispiel und gibt einen Überblick über die verschiedenen Accounts, kategorisiert nach Domänen:
Wir empfehlen, die folgenden Foundation Core Accounts und mindestens zwei Konten pro Business-Applikation einzurichten. Foundation Shared Service Accounts sind optional und ob Sie diese benötigen, hängt von Ihren individuellen Anforderungen ab.
| Domain | Account Typ | Beschreibung |
|---|---|---|
| Foundation Core | AWS Organizations Management | Verwaltung der AWS Organization, der Organisationseinheiten (OUs) und der Service Control Policies (SCPs). Abrechnung von Kosten der ganzen AWS Organization (Consolidated Billing) |
| Foundation Core | Core Account Lifecycle | Management der Erstellung, des Baselinings, und des Abbaus von AWS Accounts |
| Foundation Core | Core Security | Zusammenzug von AWS Config, AWS Security Hub und Amazon GuardDuty Daten. Unsere Security Event Management Lösung SEMPER wird auch in diesem Account aufgebaut. |
| Foundation Core | Core Logging | Ablage und Archivierung von Logs. Direkter Zugriff wird eingeschränkt um die Integrität der Logs zu gewährleisten. |
| Foundation Core | Core Monitoring | Beinhaltet zentrale Monitoring Systeme (z.B. AWS OpenSearch, Splunk, usw.). Dieser Account wird vom Logging Account getrennt, um zu verhindern, dass Logs manipuliert werden können. Die Integrität der Logs hat höchste Priorität und kann so am besten sichergestellt werden. |
| Foundation Core | Core Image Factory | Account um Amazon Machine Image (AMI) zu bauen. AMIs werden in diesem Account gebaut und mit der AWS Organization geteilt. |
| Foundation Core | Core Networking | Beinhaltet die zentralen Netzwerk Komponenten (Transit Gateway, Route53, Direct Connect, VPN). Optional: Shared VPCs für alle Accounts in der Organization. Damit kann erreicht werden, dass die Teams keine Änderungen an der Netzwerk Konfiguration machen können. |
| Foundation Shared Service | Shared Services | Shared Service Accounts beinhalten Plattformen oder Services, die von mehreren Business Workloads genutzt werden. Gute Beispiele sind Streaming Plattformen wie Kafka (z.B. MSK), Data Lakes, Active Directory oder ein geteiltes Kubernetes Cluster (z.B. EKS). |
| Business Workload | Business Workload | Wie Sie Ihre Business Workload Accounts strukturieren, überlassen wir ihnen. Wir empfehlen mindestens zwei Accounts pro Workload zu erstellen. Damit können produktive Workloads sehr einfach von nicht produktiven Workloads getrennt werden. Zusätzlich können so verschieden Rules und Policies (z.B. SCPs) für produktive und nicht produktive Accounts angewendet werden. |
Die Capabilities der Nuvibit Foundation Core Domain bestehen typischerweise nicht nur aus den Foundation Core Accounts sondern setzen voraus, dass einige Komponenten in allen Accounts innerhalb der AWS Organization bereitgestellt werden.
Diese verteilten Komponenten nennen wir Account Baseline.
Die Account Baseline umfasst die Härtung der Accounts, Compliance und Security Policies und auch die Konfiguration, um die Accounts mit den jeweiligen Foundation Core Accounts zu verbinden.
Die Account Baseline wird zentral verwaltet und in alle Accounts der AWS Organization ausgerollt.
Wir empfehlen dringend, alle für die Foundation Core Capabilities verwendeten Ressourcen über Infrastructure as Code bereitzustellen.
Aus Erfahrung setzen wir hierfür ausschliesslich auf Terraform.
Nuvibit ist darauf spezialisiert, Cloud Foundation Capabilities in Unternehmen einzuführen.
Wir passen unseren Foundation Blueprint an Ihre Bedürfnisse an und befähigen Sie, Foundation Capabilities mit einem hohen Reifegrad für Ihre Cloud Workload Development Teams bereitzustellen.
Kontaktieren Sie uns für weitere Informationen.