Meine eigene Landezone auf AWS einrichten

Als Berater bin ich an ein bestimmtes Qualitätsniveau gewöhnt, das ich unseren Kunden liefern muss. Aus diesem Grund habe ich eine Landing Zone für meine eigene Website, Initiativen und Experimente eingerichtet. Indem ich dieselbe Struktur verwende, die auch unsere Kunden haben, kann ich meine Ideen testen und weiterentwickeln und sie bei Erfolg im Kundenumfeld anwenden.

Zunächst mag es sich wie ein gewaltiger Overkill anfühlen, eine komplette Landezone einzurichten. Aber wenn Sie sie erst einmal eingerichtet haben, werden Sie sehr leicht Experimente durchführen können.

Meine Landezone

Für meine Landezone habe ich das Projekt Customizations for AWS Control Tower (CfCt) verwendet. Als ich meine Landing Zone erstellt habe, war der Landing Zone Accelerator noch nicht verfügbar. Ich muss noch evaluieren, ob ich umsteigen kann, aber meine ersten Bedenken sind die Kosten für den Betrieb. CfCt hat niedrige Kosten und je nach Nutzung könnte es sogar in den kostenlosen Bereich passen. Der Landing Zone Accelerator wird mit VPCs und Transit-Gateways und einigen anderen Diensten geliefert, die unabhängig davon, was Sie mit der Landing Zone machen, Kosten verursachen.

Eine Standard-Wolkenlandezone hat in der Regel die folgenden Konten:

• Verwaltung - Dient zur Abrechnung aller Konten in einer Organisation, zur Erstellung neuer Konten und zur Verwaltung des Zugriffs auf alle Konten.
• Audit - Ein eingeschränktes Konto für Ihre Sicherheits- und Compliance-Teams, um Lese- und Schreibzugriff auf alle Konten zu erhalten.
• Protokolle - Dient als Aufbewahrungsort für Protokolle von API-Aktivitäten und Ressourcenkonfigurationen von allen Konten.

Neben den Standardkonten habe ich einige zusätzliche Konten eingerichtet:

• Build - Wird für alle CodeCommit-Repositories und CodePipelines verwendet, die in der Landing Zone bereitgestellt werden.
• Domains - Wird verwendet, um die von mir registrierten Domainnamen zu hosten. Wenn Sie wissen möchten, warum ich dafür ein separates Konto verwende, lesen Sie bitte meinen Artikel DNS-Verwaltung im Cross Account.
• Service Catalog - Wird verwendet, um alle meine AWS Service Catalog-Produkte zu hosten, die ich in meiner Landing Zone verwende.
• Team - Wird verwendet, um innerhalb meiner Landezone ein temporäres erhöhtes Zugangsmanagement (TEAM ) durchzuführen.

Für den Rest habe ich einige Workload-Konten, die ein Konto pro Umgebung haben. Jeder Workload hat mindestens ein Entwicklungskonto, aber es kann auch auf ein Test-, Abnahme- und Produktionskonto erweitert werden.

Kontoerstellung

Wenn ich etwas Neues erstellen möchte, benötige ich ein neues Entwicklungskonto. Für die Kontoerstellung verwende ich aws-samples/aws-control-tower-automate-account-creation. Ich habe die Lösung geändert, um direkt einen Datensatz in die DynamoDB-Tabelle zu injizieren, der den Prozess der Kontoerstellung auslöst. Ich habe einen einfachen Befehl, den ich in der Befehlszeile ausführen kann und der die folgenden Argumente benötigt: Name des Workloads, Beschreibung und den Umgebungstyp.

Bauen Sie!

Nachdem ich ein Entwicklungskonto erstellt habe, logge ich mich in das Build-Konto ein und navigiere zum Service Catalog-Dienst. Je nach Idee benötige ich ein anderes Produkt, aber bis jetzt habe ich die folgenden Produkte erstellt:

• Generisches Projekt - Enthält eine CodePipeline mit einem CodeCommit-Repository, einem CodeBuild-Schritt und einem CloudFormation-Bereitstellungsschritt für jede Umgebung.
• S3 Hosted Website - Enthält eine CodePipeline mit einem CodeCommit-Repository, einem CodeBuild-Schritt und einem CloudFormation-Bereitstellungsschritt für jede Umgebung sowie einen S3-Bereitstellungsschritt.

Ich verwende diese Service Catalog-Produkte, um die CI/CD-Pipelines zu erstellen, mit denen ich zum Beispiel meine eigene Website Conijn.io hoste.

Das CodeCommit-Repository wird mit den folgenden Dateien vorbelegt:

• .pre-commit-config.yaml - enthält die cfn-lint und cfn_nag Pre-Commit-Hooks.
• buildspec.yml - installiert die aws-sam-cli und erstellt und verpackt die Vorlage.
• parameters-development.json - Die CloudFormation Parameter, Tags und Richtlinien für die Entwicklungsumgebung.
• parameters-production.json - Die CloudFormation Parameter, Tags und Richtlinien für die Produktionsumgebung.
• README.md - Initiale Lies-mich-Datei.
• template.yaml - Erste CloudFormation-Vorlage.

Nachdem das Produkt Service Catalog erfolgreich gestartet wurde. Ich muss nur den folgenden Befehl ausführen:

git clone codecommit::<AWS_REGION>://<MY_PROFILE_NAME>@<PROJECT_NAME>

Und ich bin bereit, mit der Erstellung zu beginnen. Ich kann damit beginnen, meiner Vorlage Ressourcen hinzuzufügen. Wenn ich Parameter verwenden muss, kann ich die Datei verwenden. Wenn ich zusätzliche Schritte ausführen muss, kann ich diese in der Datei hinzufügen. Wenn ich die Änderungen übertrage und sie in das entfernte Repository schiebe, wird CodePipeline ausgelöst und die Änderungen werden im Entwicklungskonto bereitgestellt.

Für die Sichtbarkeit der Pipelines habe ich ein NotificationTopic eingerichtet. Dieses Topic ist ein SNS Topic, das AWS ChatBot als Abonnent hat. Chatbot sendet dann die Updates an meinen Slack-Arbeitsbereich, den ich eingerichtet habe. Wenn die Pipeline ausgelöst wird, erhalte ich auf diese Weise die Benachrichtigungen auf meinem Telefon und meinem Laptop.

Fazit

Die Einrichtung Ihrer eigenen Landing Zone ist eine Menge Arbeit, aber Sie werden viel dabei lernen. Und wenn Sie eine haben, ist es sehr einfach, eine neue Initiative in einem leeren AWS-Konto zu starten.

Foto von Vincent Albos