Projekt anfragen
Laptop mit technischem Bauplan auf dem Bildschirm, darunter ein ausgebreiteter blauer Bauplan und eine Planrolle

Cloud Landing Zone · AWS, Azure, STACKIT

Cloud Landing Zones und Infrastructure as Code

Konten, Netz, Identitäten, Leitplanken und Protokollierung als versionierter Code: SKAFFON baut das Fundament, auf dem Ihre Teams Workloads betreiben, und jede neue Umgebung entsteht reproduzierbar.

Projekt anfragen Zur Entwurfsmatrix
  • AWS, Azure oder STACKIT
  • Policies als Code
  • Abnahme mit Negativtests

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Ein Konto für das Projekt, eins für das Experiment, das Netz „später“

Cloud-Umgebungen entstehen oft schrittweise. Typische Folgen: Berechtigungen, die niemand mehr nachvollziehen kann, kein einheitliches Protokollierungsziel, Netzwerke mit überlappenden Adressbereichen, die sich nicht verbinden lassen, und Kosten, die sich keinem Team zuordnen lassen. Jede dieser Folgen ist nachträglich teurer zu beheben als in der Entwurfsphase.

Eine Landing Zone ist das Fundament, auf dem Ihre Teams Workloads in der Cloud betreiben: Konten- oder Projektstruktur, Netzwerk, Identitäten und Berechtigungen, Policy-Leitplanken, zentrale Protokollierung und eine Sicherheits-Grundkonfiguration. Relevant wird das vor der ersten Migration und nach gewachsenem Konto-Wildwuchs.

02Aufbau

Plattformteam und Workload-Teams: zwei Verantwortungen, ein Rahmen

Ein Plattformteam betreibt die zentralen Bausteine (Struktur, Netz, Identität, Leitplanken, Protokollierung). Workload-Teams erhalten daraus eigene Umgebungen und arbeiten innerhalb dieser Leitplanken. Diese Trennung beschreibt auch Microsoft für Azure: eine Plattform-Landing-Zone und Workload-Landing-Zones, wobei Workload-Teams ihre Umgebungen innerhalb der von der Plattform gesetzten Richtlinien verwalten.

Aufbau einer Landing Zone Organisation mit Plattformbereich (Netz, Identität, Leitplanken, Protokollierung) und Workload-Umgebungen für Entwicklung, Test und Produktion; alles wird per Code und Pipeline ausgerollt. Organisation / Wurzel der Hierarchie Code-Repository und Pipeline Änderungen per Pull Request, Prüfung, Rollout. Keine manuellen Eingriffe. Plattformbereich (betrieben vom Plattformteam) NetzwerkAdressplan, Anbindung Identität und RollenAnmeldung, Notfallzugang LeitplankenPolicies als Code Protokollierungzentrales Ziel Workload-Umgebungen (Teams arbeiten innerhalb der Leitplanken) EntwicklungKonto, Abonnement oder Projekt TestKonto, Abonnement oder Projekt ProduktionKonto, Abonnement oder Projekt
Aufbau einer Landing Zone Organisation mit Plattformbereich (Netz, Identität, Leitplanken, Protokollierung) und Workload-Umgebungen für Entwicklung, Test und Produktion; alles wird per Code und Pipeline ausgerollt. Organisation / Wurzel der Hierarchie Code-Repository und Pipeline Änderungen per Pull Request, Prüfung,Rollout. Keine manuellen Eingriffe. Plattformbereich(betrieben vom Plattformteam) NetzwerkAdressplan, Anbindung Identität und RollenAnmeldung, Notfallzugang LeitplankenPolicies als Code Protokollierungzentrales Ziel Workload-Umgebungen(Teams arbeiten innerhalbder Leitplanken) EntwicklungKonto, Abonnement oder Projekt TestKonto, Abonnement oder Projekt ProduktionKonto, Abonnement oder Projekt

03Eingaben

Was wir von Ihnen brauchen, bevor der erste Entwurf entsteht

Ihre Entscheidung über Schutzbedarf, Aufbewahrungsfristen und Freigabeprozesse ersetzen wir nicht. Wir machen sie technisch umsetzbar und prüfbar.

  • Ziel-Plattform(en) und die Gründe dafür (siehe ggf. Cloud-Beratung)
  • Organisationsmodell: Wer betreibt zentral, welche Teams brauchen eigene Umgebungen, welche Stufen (Entwicklung, Test, Produktion) gibt es
  • Bestehende Identitätsquelle (Verzeichnisdienst, Single Sign-on) und Anforderungen an Anmeldung und Rollen
  • Netzwerkvorgaben: vorhandene Adressräume, Anbindung ans Rechenzentrum oder an Standorte, Namensauflösung
  • Regulatorische und interne Vorgaben: Datenstandort, Protokollaufbewahrung, Schutzbedarf
  • Rahmen für die Kostenzuordnung (Kostenstellen, Produkte)

04Entwurfsmatrix

Dieselben Aufgaben, drei Vokabulare: Landing-Zone-Bausteine je Plattform

Die Begriffe unterscheiden sich je Anbieter, die Aufgaben nicht. Die Tabelle ordnet die Bausteine zu, die wir im Entwurf je Plattform festlegen. Sie ist ein Raster für den Entwurf, kein fertiges Zielbild; Zahl und Zuschnitt der Ebenen hängen von Ihrer Organisation ab.

Landing-Zone-Bausteine in AWS, Azure und STACKIT
BausteinAWSAzureSTACKIT
StrukturAWS Organizations mit Organisationseinheiten und KontenManagement-Gruppen-Hierarchie mit AbonnementsOrganisation, Ordner (eine Ordnerebene), Projekte
Standardisierte NeuanlageAccount Factory in AWS Control TowerAbonnement-Vending (Subscription Vending)Projekte nach einheitlicher Vorlage anlegen; Automatisierungsweg im Entwurf festlegen
LeitplankenKontrollen (präventiv, detektiv, proaktiv) in Control Tower, Service Control PoliciesAzure Policy auf Management-Gruppen-EbeneIm Entwurf festlegen: Rollen, Projektzuschnitt, Kontroll-Prozesse in der Pipeline
IdentitätIAM Identity CenterMicrosoft Entra IDSTACKIT IAM, Anbindung an Ihre Identitätsquelle im Entwurf klären
ProtokollierungZentrales Log-KontoZentraler Log-Analytics-Arbeitsbereich in der Plattform-Landing-ZoneZentrales Ziel im Entwurf festlegen

Quellen: AWS Control Tower (Organizations, Account Factory, Kontrollen), Azure Landing Zones (Management-Gruppen, Subscription Vending), STACKIT Organisationen und Ordner (eine Ordnerebene, Ordner enthalten keine Ressourcen direkt). Die STACKIT-Zellen zu Leitplanken, Identität und Protokollierung sind bewusst als Entwurfsaufgabe formuliert: Welche nativen Funktionen dafür genutzt werden, klären wir anhand der aktuellen STACKIT-Dokumentation im Projekt.

05Ablauf

Vom Entwurfsdokument zur übergebenen Landing Zone

  1. 01

    Entwurf

    Ergebnis: Entwurfsdokument

    Konten-/Projekthierarchie, Umgebungsmodell, Adressplan, Identitäts- und Rollenmodell, Policy-Katalog, Protokollierungskonzept. Das Dokument hält die getroffenen und die noch offenen Entscheidungen fest.

  2. 02

    Umsetzung als Code

    Ergebnis: Repo und Pipeline

    Die Landing Zone wird mit OpenTofu oder Terraform beschrieben. Änderungen laufen über Pull Requests und eine Pipeline, zum Beispiel in GitLab CI.

  3. 03

    Leitplanken

    Ergebnis: Policy-Katalog

    Policies als Code, je nach Plattform etwa Organisationsrichtlinien, Policy-Zuweisungen oder Kontrollen. Je Regel sind Zweck, Wirkung (verhindern oder melden) und Ausnahmeprozess dokumentiert.

  4. 04

    Neue Umgebungen bereitstellen

    Ergebnis: wiederholbarer Weg

    Ein definierter Weg, auf dem ein Team ein neues Konto, Abonnement oder Projekt mit der Grundkonfiguration erhält.

  5. 05

    Abnahme und Übergabe

    Ergebnis: Runbooks, Einweisung

    Tests gegen die Abnahme-Checkliste, Runbooks, Einweisung des Plattformteams. Betrieb durch Ihr Team oder auf Wunsch durch SKAFFON als Cloud-Betrieb.

06Code und Self-Service

Änderungen nur per Pull Request, Self-Service nur mit eigener API

Was im Repository steht, ist der Soll-Zustand der Landing Zone. Wo Sie ein Kubernetes-basiertes Self-Service-Modell wünschen, kann Crossplane als Control-Plane-Framework dienen, das eigene APIs für die Bereitstellung bereitstellt.

  • OpenTofu oder Terraform beschreiben die Bausteine
  • Pull Requests und Pipeline statt Klicken in der Konsole
  • Crossplane optional für Self-Service über eigene APIs

Handwerk: Infrastructure as Code

Farbig hervorgehobener Programmcode auf einem Monitor in abgedunkeltem Raum, schräg fotografiert

07Entwurfsentscheidungen

Sieben Fragen, die vor dem ersten Konto beantwortet sein müssen

Diese Entscheidungen legen wir mit Ihnen fest, bevor Code entsteht.

  1. 01

    Wie viele Ebenen?

    Entscheidung 1

    So wenige wie möglich. Jede Hierarchieebene ist ein Ort, an dem Richtlinien und Berechtigungen vererbt werden und den jemand pflegen muss.

  2. 02

    Wer legt Umgebungen an, und wie schnell?

    Entscheidung 2

    Self-Service mit Leitplanken oder Freigabe durch das Plattformteam.

  3. 03

    Hub-and-Spoke oder flaches Netz?

    Entscheidung 3

    Hängt von Zahl der Umgebungen, zentraler Inspektion und Anbindung ans Rechenzentrum ab. Adressräume werden vor dem ersten Konto zentral vergeben, damit sie sich später verbinden lassen.

  4. 04

    Wo liegen die Protokolle?

    Entscheidung 4

    Wer darf sie lesen, wie lange bleiben sie? Das Protokollziel ist von den Workloads getrennt, damit ein kompromittierter Workload seine eigenen Spuren nicht löschen kann.

  5. 05

    Was verhindert, was meldet nur?

    Entscheidung 5

    Verhindernde Regeln für klare Verstöße (etwa öffentliche Speicher ohne Freigabe), meldende für alles, was erst beobachtet werden soll.

  6. 06

    Wie laufen Ausnahmen?

    Entscheidung 6

    Wie werden sie genehmigt, befristet und sichtbar gemacht?

  7. 07

    Wie wird Drift erkannt?

    Entscheidung 7

    Manuelle Änderungen außerhalb des Codes werden erkannt und entweder übernommen oder zurückgesetzt.

08Abnahme

Abnahme-Checkliste: Was beim Übergabetest nachweisbar sein muss

  • Neue Umgebung entsteht allein aus dem Repository, ohne manuelle Schritte
  • Eine absichtlich verbotene Konfiguration wird tatsächlich blockiert oder gemeldet (Negativtest je Regel)
  • Protokolle aus Test-Umgebungen erscheinen im zentralen Ziel
  • Rollen: Plattform- und Workload-Rollen getrennt, Notfallzugang dokumentiert und getestet
  • Ausfall der Pipeline: Weg für dringende Änderungen beschrieben
  • Kostenzuordnung je Umgebung sichtbar (Etiketten oder Strukturzuordnung)
  • Runbooks: neue Umgebung anlegen, Rolle vergeben, Ausnahme einrichten, Landing Zone aktualisieren

09Zugriff und Grenzen

Zeitlich begrenzter Zugriff, Geheimnisse im Speicher, keine Anwendungen

Der Entwurf berücksichtigt Ihre Vorgaben zu Datenstandort und Protokollierung; eine rechtliche Bewertung bleibt bei Ihrem Datenschutz und Ihrer Compliance. Technische Absicherung darüber hinaus: Cloud Security und IAM und Zero Trust.

  • Zugriff auf Ihre Cloud-Konten über zeitlich begrenzte, rollenbasierte Berechtigungen
  • Pipeline-Geheimnisse liegen in einem Geheimnisspeicher, nicht im Repository
  • Die Landing Zone enthält keine Anwendungen; die kommen über Migration oder Neuentwicklung hinein
Glasfaser-Patchkabel mit LC-Steckern in einem Patchfeld im Serverraum

10Passung

Für wen sich eine vollständige Landing Zone lohnt, und für wen nicht

Lohnt sich

  • Mehrere Teams und Umgebungen, die sich eine Cloud-Grundlage teilen
  • Ein Plattformteam oder ein benannter Verantwortlicher für den Betrieb danach
  • Bereitschaft, Entwurfsentscheidungen zu treffen

Lohnt sich nicht

  • Ein einzelnes kleines Projekt in einem einzigen Konto ohne Wachstumsabsicht: eine saubere Grundkonfiguration reicht
  • Sie suchen ausschließlich Beratung zur Struktur von Terraform-Code: dafür ist Infrastructure as Code die passende Seite
  • Kein Plattformteam und kein Verantwortlicher für den Betrieb danach: dann klären wir zuerst, wer die Landing Zone besitzt, oder bieten den Betrieb an
  • Sie erwarten eine überall gleiche Schlüsselfertig-Landing-Zone ohne Entwurfsentscheidungen

11Angebot

Woran sich der Umfang eines Landing-Zone-Projekts bemisst

Was den Aufwand bestimmt, steht unten. Ein Angebot entsteht nach einem kurzen Scoping-Gespräch und legt Umfang, Phasen, Ergebnisse, Annahmen und Preismodell fest.

Zielplattform, Teams, Umgebungen, Termin der ersten Workload

Nennen Sie uns diese vier Angaben, daraus entsteht das Scoping-Gespräch.

Projekt anfragen Zur Leistungsübersicht