Viele Unternehmen beginnen ihre Cloud-Reise mit einzelnen Projekten, ersten virtuellen Maschinen oder einem Kubernetes-Cluster. Was anfangs funktioniert, wird jedoch schnell zur Herausforderung, sobald mehrere Teams, Anwendungen und Compliance-Anforderungen hinzukommen. An dieser Stelle wird das Konzept der Landing Zone relevant. Eine Landing Zone bildet das organisatorische, technische und sicherheitsrelevante Fundament einer Cloud-Plattform. Sie schafft Standards, Governance-Strukturen und zentrale Dienste, auf denen spätere Anwendungen aufbauen können. Ziel ist es, von Anfang an eine Umgebung zu schaffen, die skalierbar, sicher und langfristig wartbar ist.
In diesem Artikel betrachten wir, wie eine moderne STACKIT Landing Zone aussehen kann und welche Aspekte aus unserer Sicht besonders wichtig sind.
Bevor Netzwerke, Firewalls oder Plattformdienste eingerichtet werden, sollte zunächst eine sinnvolle Projektstruktur definiert werden. STACKIT bietet hierfür verschiedene Möglichkeiten. Kleinere Umgebungen können bereits durch konsequente Naming-Konventionen strukturiert werden. Für größere Organisationen empfiehlt sich die Nutzung von Foldern, um Projekte logisch zu gruppieren.
Weniger bekannt ist, dass über den STACKIT Support aktuell sogar eine zweite Folder-Ebene freigeschaltet werden kann. Diese Funktion befindet sich noch in einer erweiterten Testphase und erfordert eine engere Abstimmung mit STACKIT. Für größere Organisationen eröffnet sie jedoch zusätzliche Möglichkeiten zur Abbildung von Geschäftsbereichen, Mandanten oder Plattformdomänen. Eine durchdachte Hierarchie bildet die Grundlage für Berechtigungen, Kostenzuordnung, Logging und Governance.
Bei der Netzwerkarchitektur empfehlen wir heute grundsätzlich den Einsatz von STACKIT Network Areas. Das klassische STACKIT Public Projekt sollte aus unserer Sicht nur noch für Sonderfälle wie Sandbox- bzw. Testumgebungen verwendet werden. Der Grund dafür ist, dass bereits viele neuere Plattformdienste eine Network Area voraussetzen. Gleichzeitig ist ein späterer Wechsel zwischen Projekttypen mit entsprechendem Migrationsaufwand verbunden.
Network Areas ermöglichen es, mehrere Projekte innerhalb einer gemeinsamen Netzwerkarchitektur miteinander zu verbinden. Dadurch lassen sich klassische Hub-and-Spoke-Architekturen aufbauen, wie sie aus Enterprise-Umgebungen bekannt sind.
Eine bewährte Landing-Zone-Architektur basiert auf einem zentralen Netzwerk-Hub. In diesem Hub können zentrale Dienste betrieben werden:
Die eigentlichen Anwendungen werden in separaten Spoke-Projekten betrieben und greifen auf die zentralen Dienste des Hubs zurück. Aktuell erfolgt die zentrale Anbindung typischerweise über:
Direkte private Netzwerkverbindungen stehen heute noch nicht zur Verfügung. Mit STACKIT Connect befindet sich jedoch bereits ein entsprechender Dienst in Vorbereitung, der künftig dedizierte private Verbindungen mit entsprechenden SLAs ermöglichen soll. Ende 2026 bzw. Anfang 2027 werden wir mehr dazu wissen.
STACKIT Network Areas ermöglichen eine klare Netzwerksegmentierung. So können beispielsweise Produktions- und Non-Produktionsumgebungen bereits auf Ebene der Network Area logisch und organisatorisch voneinander getrennt werden.
Dabei gibt es jedoch einen wichtigen Aspekt zu beachten:
Sobald ein STACKIT Virtual Network für das Routing in das Transfernetz konfiguriert wird, können Kommunikationspfade zwischen den angeschlossenen Projekten entstehen. Ohne zusätzliche Schutzmechanismen kann dies zu einer deutlich größeren Netzwerksichtbarkeit führen als ursprünglich beabsichtigt.
Aus diesem Grund sollten Network Security Groups (NSGs) von Beginn an ein zentraler Bestandteil jeder STACKIT Landing Zone sein. Wir empfehlen, sämtliche Subnetze durch NSGs abzusichern, besonders schützenswerte Workloads zusätzlich auf NIC-Ebene zu schützen und Netzwerkkommunikation ausschließlich explizit freizugeben. Ein konsequent umgesetztes Default-Deny-Prinzip stellt dabei sicher, dass nur die tatsächlich benötigten Kommunikationsbeziehungen erlaubt werden. Auf diese Weise bleibt jederzeit nachvollziehbar und kontrollierbar, welche Systeme über welche Ports und Protokolle miteinander kommunizieren dürfen.
Ein Thema, das viele Nutzer von Hyperscalern kennen, sind Private Endpoints für Plattformdienste. Diese Funktion steht bei STACKIT aktuell noch nicht flächendeckend zur Verfügung. Viele PaaS-Dienste werden deshalb bewusst als sogenannte Online Services bereitgestellt und sind über öffentliche Endpunkte erreichbar.
Wichtig zu verstehen ist dabei:
Greift eine virtuelle Maschine innerhalb der STACKIT Cloud auf einen solchen Dienst zu, verbleibt der Datenverkehr zwar im STACKIT Backbone. Die Architektur unterscheidet sich jedoch von den vollständig privaten Service-Endpunkten anderer Cloud-Anbieter.
Private Endpoints befinden sich bereits in der Entwicklung. Erste Dienste, beispielsweise für den STACKIT Objektspeicher, werden voraussichtlich zeitnah folgen. Bis dahin können ACLs und Netzwerkkonzepte dabei helfen, die Angriffsfläche zu reduzieren.
Ein weiterer wichtiger Unterschied zu vielen anderen Cloud-Plattformen betrifft das Identitätsmodell. STACKIT versteht sich bewusst nicht als eigener Identity Provider. Stattdessen integriert sich die Plattform in bestehende Identitätslandschaften und unterstützt etablierte Föderationsmechanismen.
Unternehmen mit vorhandenem Identity Provider können diesen direkt anbinden. Wer noch keinen zentralen Identity Provider besitzt, kann beispielsweise auf Open-Source-Lösungen wie Keycloak setzen und diese über SSO-Föderation integrieren. Zusätzlich lässt sich durch die Einrichtung einer SCIM-Anbindung zwischen STACKIT und dem Identity Provider die Benutzerverwaltung deutlich vereinfachen, da User-Accounts und Berechtigungen automatisiert bereitgestellt und synchronisiert werden können.
Besondere Aufmerksamkeit verdienen Service Accounts. Diese sind immer organisationsgebunden und leben innerhalb von Projekten. Wer seine Landing Zone vollständig über Terraform oder die STACKIT CLI automatisieren möchte, sollte daher frühzeitig einen ausreichend berechtigten Service Account bereitstellen. Ohne diesen können spätere Automatisierungsprozesse nicht starten. Unsere Empfehlung ist es außerdem, die Authentifizierung solcher Service Accounts mit OIDC zu konfigurieren, um die Aufwände für Verwaltung und Security bezogen auf Secrets zu minimieren.
Ein Backup wird häufig erst dann betrachtet, wenn produktive Workloads bereits laufen. Unsere Empfehlung ist genau umgekehrt: Die Backup-Strategie sollte Teil der Landing-Zone-Planung sein.
Viele Unternehmen bringen bestehende Lösungen wie Veeam mit. Dieser Ansatz funktioniert auf STACKIT sehr gut. Der S3-kompatible Objektspeicher lässt sich problemlos als Backup-Repository nutzen und integriert sich bereits heute in die meisten etablierten Backup-Produkte. Bei PaaS-Diensten empfehlen wir aktuell weiterhin die nativen Backup-Funktionen der jeweiligen Services. Externe Backup-Lösungen bieten hier häufig noch keine ausreichende Integration.
Interessant ist außerdem die Möglichkeit, Object Lock zu verwenden. Dadurch können Backup-Daten nach dem WORM-Prinzip (Write Once Read Many) gespeichert werden. Das erhöht den Schutz vor Manipulationen und kann insbesondere im Kontext von Ransomware-Angriffen eine wichtige Rolle spielen.
Auch Logging sollte Bestandteil jeder Landing Zone sein. Mit dem Telemetry Router stellt STACKIT inzwischen einen zentralen Mechanismus bereit, um Telemetriedaten und Audit Logs aus Projekten, Foldern, Organisationen und Services zu sammeln. Über Telemetry Router Links können diese Daten zentral exportiert und in externe Log-Plattformen oder eigene Auswertungssysteme übertragen werden. Dadurch entsteht eine zentrale Sicht auf sicherheitsrelevante Ereignisse und Plattformaktivitäten. In STACKIT könnte man diese Logs beispielsweise in Services wie STACKIT Logs oder STACKIT Observability einspeisen, verarbeiten und im letzterem Beispiel auch Alerts generieren.
Cloud Governance endet nicht bei Sicherheit und Netzwerkdesign. Auch Kostenkontrolle sollte Bestandteil jeder Landing Zone sein. STACKIT unterstützt heute Kostenexporte im FOCUS-Format. Dadurch können Verbrauchsdaten langfristig archiviert und automatisiert ausgewertet werden.
Zusätzlich lassen sich Projekte mit Abrechnungsinformationen versehen, wodurch interne Kostenstellen oder Business Units sauber zugeordnet werden können. Projektbudgets stehen aktuell noch nicht nativ zur Verfügung. Mit den vorhandenen APIs und Kostenexporten lassen sich entsprechende Mechanismen jedoch vergleichsweise einfach selbst implementieren.
Spätestens bei mehreren Projekten, Netzwerksegmenten, Service Accounts und Sicherheitsrichtlinien wird deutlich, dass sich eine STACKIT Landing Zone nicht mehr sinnvoll manuell betreiben lässt. Infrastructure as Code ist deshalb ein zentraler Bestandteil der Plattformstrategie.
Terraform bietet hierfür bereits eine sehr solide Grundlage. Auch wenn die neuesten STACKIT-Dienste nicht immer unmittelbar als native Terraform-Ressourcen verfügbar sind, stehen die zugrunde liegenden APIs in der Regel bereits bereit und können automatisiert angebunden werden. Dadurch lassen sich selbst komplexe Landing-Zone-Architekturen reproduzierbar, konsistent und revisionssicher verwalten.
Die programmatische Beschreibung der Infrastruktur bringt darüber hinaus eine Reihe weiterer Vorteile mit sich:
Eine Landing Zone auf STACKIT besteht aus deutlich mehr als einer Netzwerkverbindung und einigen Projekten. Sie definiert die organisatorische Struktur, die Netzwerkarchitektur, Sicherheitsrichtlinien, Identitäten, Backup-Konzepte, Logging und FinOps-Prozesse, die später von allen Anwendungen genutzt werden.
Wer diese Grundlagen frühzeitig etabliert, schafft die Voraussetzung für eine Cloud-Plattform, die langfristig skalierbar, sicher und betrieblich beherrschbar bleibt. Und das ist letztlich das eigentliche Ziel einer Landing Zone.
Willkommen bei unserem exklusiven Support für Bestandskunden. Hier finden Sie alle nötigen Informationen, um schnell und unkompliziert Hilfe bei technischen Anfragen zu erhalten.
Für eine direkte Unterstützung per Fernwartung, laden Sie bitte unser TeamViewer-Modul herunter:
Bitte beachten Sie: Dieser Kanal ist speziell für technische Anfragen unserer Bestandskunden vorgesehen. Für allgemeine Anfragen, Informationen zu unseren Dienstleistungen oder eine Erstberatung nutzen Sie bitte unser Kontaktformular oder schreiben Sie eine E-Mail an [email protected].
