Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03348.jsonl.gz/1038

Viele Netcloud-Kunden betreiben eine Multi-AWS-Account-Umgebung basierend auf AWS Control Tower und / oder AWS Organizations. Für die Verwaltung der AWS-Umgebung wird zumeist auf Infrastructure as Code (IaC) in Form von Terraform zurückgegriffen. Dies erlaubt es, die AWS-Umgebung als Code abzubilden und diese konsistent nach Vorgaben zu erstellen und zu replizieren. Aus Performance- und Sicherheits-Gründen (Klumpenrisiko) empfiehlt es sich, die AWS-Umgebung in mehrere Terraform-Projekte aufzuteilen. Dies kann zum Beispiel anhand der AWS Accounts, einer Applikation oder aber eines anderen Use Cases geschehen.
Oft ist das Anlegen, Konfigurieren und Integrieren von neuen AWS Accounts in die Multi-AWS-Account-Umgebung ein manueller Prozess. Dieser Prozess erstreckt sich üblicherweise über mehrere Teams / Personen und ist dementsprechend fehleranfällig und langwierig. Dies war auch bei einem Netcloud-Kunden der Fall. Dieser besass eine Multi-AWS-Account-Umgebung basierend auf AWS Control Tower mit einem Konzept, welches im Groben folgendes vorgab:
- Eine Applikation / Workload kann mehrere Umgebungen (z.B. DEV, UAT und PROD) haben.
- Eine Applikations- / Workload-Umgebung entspricht einem AWS Account.
- Pro Applikation / Workload wird ein GitLab-Projekt angelegt.
- Das GitLab-Projekt beinhaltet ein Terraform-Root-Modul, welches für die Basiskonfiguration der AWS Accounts per IaC zuständig ist.
- Eine GitLab CI/CD Pipeline stellt sicher, dass Änderungen am Terraform-Root-Module sogleich auf den AWS Accounts umgesetzt werden.
Für einen Workload mit drei Umgebungen (DEV, UAT und PROD) würde die AWS Account- und GitLab-Konfiguration abstrahiert wie folgt aussehen.
Wie eingangs erwähnt, war der Erstellungsprozess und die anschliessende Konfiguration (AWS- sowie GitLab-seitig) eine manuelle Tätigkeit. Aus diesem Grund wurde Netcloud in einem Projekt beauftragt, die Bereitstellung neuer Applikationen / Workloads zu überarbeiten. Der überarbeitete Prozess sollte folgende Punkte adressieren:
Prozess und Governance bei der Account-Erstellung
Neue AWS Accounts sollen zentral über das existierende IT-Service-Management- (ITSM) Tool bestellt werden können. Dies stellt sicher, dass die definierten Prozesse eingehalten werden und auch alle nötigen Daten wie Kostenträger, Zuständigkeiten und CMDB-Einträge immer gesetzt sind.
AWS Account-Erstellung
Die AWS Account-Erstellung soll automatisiert sein, da dies ein zeitraubender, manueller Task darstellt. Dies speziell bei der Bestellung von mehreren AWS Accounts auf einen Schlag.
GitLab Projekterstellung & Konfiguration
Die Erstellung der benötigten GitLab-Projekte und die anschliessende Konfiguration muss automatisch geschehen. Dies soll manuelle und fehleranfällige Arbeiten eliminieren.
Erstellung der Basis-Infrastruktur der AWS Accounts
Nach der Erstellung neuer AWS Accounts müssen Basiskonfigurationen wie Single Sign-On, Security, Netzwerk und Logging vorgenommen werden.
Anhand der gestellten Anforderungen entstand ein automatisierter Bestellprozess, die «AWS Account Vending Machine». Bei der AWS Account Vending Machine handelt es sich um eine AWS Step Function, welche direkt vom eingesetzten ITSM gestartet wird. Anhand dem durch das ITSM mitgelieferten Input wird vollautomatisch der benötigte AWS Account provisioniert, für den Terraform-Zugriff / IaC vorbereitet und das GitLab-Projekt sowie CI/CD Pipeline erstellt und konfiguriert. Die GitLab CI/CD Pipeline wird auch sogleich ausgeführt, welche die Basiskonfiguration der AWS Accounts per Terraform / IaC sicherstellt.
Folgend wird die beim Kunden implementierte AWS Account Vending Machine in einem «high-level» Schema dargestellt und erläutert.
- Das ITSM (in diesem Fall ServiceNow) startet die AWS Account Vending Machine mit dem nötigen Input.
- Die AWS Account Vending Machine bestellt über den AWS Service Catalog* den neuen AWS Account nach den Vorgaben vom ITSM. *(AWS Control Tower erstellt beim Ausrollen ein Produkt innerhalb des AWS Service Catalog, welches für die Bestellung von neuen AWS Accounts dient.)
- Das bestellte AWS Service Catalog-Produkt greift während dem Bestellvorgang unter anderem auf AWS Control Tower und AWS Organizations zu, welche das effektive Erstellen des neuen AWS Accounts übernehmen.
- Nach dem der neue AWS Account bereitgestellt und in der AWS Organization hinzugefügt wurde, startet automatisch die Ausführung eines AWS CloudFormation StackSets, welches eine AWS IAM-Rolle erstellt. Diese Rolle wird für den Zugriff per IaC (Terraform) im Schritt 6 benötigt.
- Die AWS Account Vending Machine legt automatisch das GitLab-Projekt anhand einem vordefinierten Terraform Projekt-Template an und konfiguriert die CI/CD Pipeline, sobald die AWS Account-Bestellung über den AWS Service Catalog abgeschlossen ist.
- Die GitLab CI/CD wird ausgeführt und konfiguriert den neuen AWS Account wie im Terraform-Projekt definiert. Dies beinhaltet im Kundenbeispiel unter anderem das Einrichten vom AWS Single Sign-On, das Erstellen von VPCs und das Anlegen von AWS KMS Keys.
Dies ermöglichte, den Bestell- und Konfigurations-Prozess von neuen AWS Accounts durchgängig zu automatisieren. Diese durchgängige Automatisierung reduzierte die Wartezeit auf neue AWS Accounts für Endkunden / die Besteller um über 70% und förderte zugleich das Ausliefern von konsistenten Ergebnissen.
Haben Sie Fragen, suchen Sie Unterstützung im Aufbau einer AWS-Umgebung oder würden auch Sie gerne einen durchgängig automatisierten AWS Account-Bestellprozess in Ihre bestehende Umgebung integrieren? Unsere AWS Engineers stehen gerne für Ihre Anfrage zur Verfügung >