Rewion bietet Ihnen herstellerunabhängige Cloud Beratung und unterstützt Sie dabei, das Thema Cloud für Ihr Unternehmen greifbar zu machen. Von der Vision und Strategie über die Implementierung und den Betrieb sind wir Ihr Partner für die Cloud.
Als herstellerunabhängiger und ganzheitlicher Cloud Partner begleiten wir Sie bei allen Themen rund um die Cloud und stellen Ihren Nutzen in den Vordergrund. Für Sie bedeutet das: eine Lösung, die auf Ihr Unternehmen zugeschnitten ist mit einem klaren Fokus auf Ihre Mehrwerte. Sie erhalten von uns eine neutrale Beratung, die nicht von einer Kooperation mit einem bestimmten Cloud-Anbieter beeinflusst wird.
Unsere Leistungen rund um die Cloud umfassen Beratung, Implementierung und Betrieb – alles aus einer Hand. In der Cloud Beratung entwickeln wir gemeinsam mit Ihnen die passende Strategie und schaffen die Grundlagen für nachhaltigen Erfolg. In der Implementierung setzen wir Pläne pragmatisch und effizient um und unterstützen Sie bei konkreten technischen Projekten. Und im Betrieb sorgen wir dafür, dass Ihre Cloud-Lösungen sicher, stabil und zukunftsfähig laufen. Je nachdem, welche Problemstellung Sie gerade haben, wir steigen an der passenden Stelle ein und begleiten Sie bis zum nachhaltigen Erfolg in der Cloud.
Wir entwickeln individuelle Cloud-Strategien, analysieren Anforderungen und unterstützen bei der Priorisierung und Projektplanung. Zudem beraten wir Sie zu Herausforderungen wie Souveräne Cloud, Governance und dem Aufbau eines Cloud Competence Centers.
Wir realisieren maßgeschneiderte Cloud-Lösungen inklusive Architekturdesign und Engineering. Ein erfahrenes Team sorgt für skalierbare, sichere und effiziente Ergebnisse.
Wir gewährleisten einen stabilen und performanten Cloud-Betrieb, inklusive Security-Monitoring und Plattformoptimierung. Zusätzlich befähigen wir Teams, ihre Cloud-Umgebungen langfristig eigenständig und effizient zu nutzen.
Gemeinsam erarbeiten wir eine Vision Ihrer Arbeit mit der Cloud, die Mehrwerte in den Fokus stellt. Basierend auf konkreten Zielen und Ihrer IT-Strategie definieren wir Ihre individuelle Cloud Strategie als Basis für den nachhaltigen Erfolg.
Durch geopolitische Entwicklungen, regulatorische und betriebliche Erfordernisse ergeben sich neue Anforderungen an die Cloud. Als Trusted Advisor helfen wir Ihnen, souveräne Alternativen zu evaluieren, ihre Strategie zu optimieren und Lösungen umzusetzen.
Wir konzipieren und realisieren automatisierte und skalierbare Plattformen, um Betrieb, Sicherheit und Innovation in Einklang zu bringen. Wir entwickeln die relevanten Fähigkeiten in Ihrer Organisation, um Plattformen erfolgreich zu entwickeln und zu betreiben.
Mithilfe des FinOps Frameworks schaffen wir Transparenz und senken Ihre Cloud Kosten signifikant. Wir enablen Sie, den maximalen Mehrwert mit den verwendeten Mitteln für Sie zu erzielen. Damit realisieren wir gemeinsam den schnellsten ROI in der IT.
Für eine effiziente und unternehmensweit sichere Nutzung der Cloud benötigen Sie eine klare Governance. Dazu gehört z.B. das Festlegen von Verantwortlichkeiten und Rollen sowie die Definition neuer Prozesse.
Im Rahmen der Migration und Modernisierung setzen wir für Ihr Unternehmen systematisch die Überführung und Modernisierung Ihrer IT-Landschaft in die Cloud um.
Richtig angewandt bieten Cloud Technologien die besten Mittel zur Sicherstellung ihrer IT-Sicherheit. Wir helfen Ihnen, die Technologie richtig einzusetzen und sichern Ihre Cloud sowie deren Anwendungen und die in der Cloud gespeicherten Daten.
STACKIT kombiniert die Leistungsfähigkeit einer modernen Enterprise Cloud mit der digitalen Souveränität, die für den europäischen Markt entscheiden ist. So schaffen Sie die Grundlage für eine sichere und souveräne IT.
Wir unterstützen Sie bei Ihrem Cloud Projekt und beantworten Ihre Fragen. Vereinbaren Sie jetzt Ihre kostenlose Erstberatung direkt online.
Cloud Beratung umfasst die strategische und operative Unterstützung von Unternehmen bei allen Themen rund um die Cloud. Dazu gehört die Entwicklung einer Vision und Strategie, die Auswahl geeigneter Cloud Services und Anbieter sowie die Implementierung und der laufende Betrieb. Als herstellerunabhängiger Berater stellen wir Ihren individuellen Nutzen in den Mittelpunkt und entwickeln Lösungen, die auf Ihre spezifischen Anforderungen zugeschnitten sind. Von der ersten Konzeption bis zur kontinuierlichen Optimierung begleiten wir Sie partnerschaftlich auf Ihrem Weg in die Cloud.
Typische Cloud Services umfassen Infrastructure as a Service (IaaS) mit virtuellen Servern und Speicher, Platform as a Service (PaaS) für Entwicklungsumgebungen sowie Software as a Service (SaaS) für geschäftsfertige Anwendungen. Weitere wichtige Services sind Cloud-Datenbanken, Container-Plattformen, Backup-Lösungen, Sicherheitsdienste und Object Storage. Moderne Cloud-Angebote beinhalten zudem KI-Services, Analytics-Tools und IoT-Plattformen. Die Auswahl der richtigen Services hängt von Ihren geschäftlichen Anforderungen, technischen Rahmenbedingungen und strategischen Zielen ab. Wir helfen Ihnen dabei, die optimale Service-Kombination zu identifizieren.
Durch geopolitische Entwicklungen, regulatorische Anforderungen wie DSGVO, NIS2 oder DORA sowie betriebliche Erfordernisse sind neue Anforderungen an Cloud-Lösungen entstanden. Digitale Souveränität bedeutet Kontrolle über Daten, Unabhängigkeit von einzelnen Anbietern und Rechtssicherheit bei der Cloud-Nutzung. Besonders kritische Infrastrukturen, öffentliche Einrichtungen und regulierte Branchen benötigen souveräne Alternativen. Als Trusted Advisor unterstützen wir Sie dabei, souveräne Cloud-Lösungen zu evaluieren, Ihre Strategie anzupassen und Lösungen umzusetzen, die digitale Unabhängigkeit mit den Vorteilen der Cloud verbinden.
Unsere Cloud Beratung umfasst die Entwicklung Ihrer Cloud Vision und Strategie, Cloud Souveränität und Governance, Platform Engineering, FinOps zur Kostenoptimierung sowie Migration und Modernisierung Ihrer IT-Landschaft. Zusätzlich bieten wir Unterstützung in der Cloud Security an, um Ihre Infrastruktur und Daten zu schützen. Wir begleiten Sie von der ersten Strategiephase über die Implementierung bis zum laufenden Betrieb – alles aus einer Hand. Als herstellerunabhängiger Partner stellen wir dabei immer Ihren individuellen Mehrwert in den Mittelpunkt und entwickeln pragmatische, nachhaltige Lösungen.
Rewion zeichnet sich durch herstellerunabhängige und ganzheitliche Beratung aus, die ausschließlich Ihren Nutzen in den Fokus stellt. Wir bieten neutrale Expertise ohne Bindung an spezifische Cloud-Anbieter und decken alle Phasen ab – von Vision und Strategie über Implementierung bis zum Betrieb. Unsere Stärke liegt in der Kombination aus technischer Tiefe, strategischem Weitblick und praktischer Umsetzungskompetenz. Mit Expertise in Bereichen wie Souveränität, FinOps, Security und Platform Engineering entwickeln wir maßgeschneiderte Lösungen, die nachhaltigen Erfolg ermöglichen und Ihre Cloud-Transformation ganzheitlich begleiten.
Vom Beginn der Planung in der Visions- und Strategiephase über den Cloud Blueprint sowie die technische Umsetzung zur Implementierung und Nutzung der Cloud für neue Businessanforderungen. Betrachtung aller relevanten Punkte wie einem Cloud Governance Konzept, einer Cloud Nutzungsrichtlinie und einer Cloud Security Policy.
Durchführung eines detaillierten Cloud Readiness Assessments. Analyse der gesamten IT Infrastruktur mit anschließenden Handlungsempfehlungen und Erarbeitung eines Cloud-Blueprints. Erarbeitung der IT Strategie, Governance Policy und den gesamten Cloud Management Prozessen bis hin zur Implementierung. Herstellerunabhängige und neutrale Beratung, Konzeption und Umsetzung für den gesamten Public Cloud Bereich.
Cloud-Kosten verstehen und optimieren – darum geht es im FinOps Framework. In diesem Whitepaper geben wir Einblicke in die Ziele und Anwendung des Frameworks und wie es Unternehmen in der Kostenoptimierung für Cloud und Technologie unterstützen kann.
Cloud-Infrastrukturen entwickeln sich nahezu tagtäglich weiter und mit ihnen die Anforderungen an Teams, die diese Umgebungen betreiben und weiterentwickeln. Auch das Cloud Platform Engineering ist entsprechend in Bewegung: Neue Technologien, Nutzungsmuster und Anforderungen nehmen Einfluss darauf, wie Plattformen gebaut werden und aussehen sollen. Dieser Artikel gibt einen Überblick über vier Entwicklungen, die das Cloud Platform Engineering in den kommenden Jahren beeinflussen und welche Veränderungen sich dadurch ergeben können.
In klassischen Cloud-Umgebungen bauen Entwicklungsteams ihre Anwendungen und sind zusätzlich für die Verwaltung der Infrastruktur dahinter verantwortlich: Server bereitstellen, skalieren, aktualisieren und überwachen. Serverless Architekturen verschieben diese Verantwortung vollständig. Statt die Infrastruktur selbst zu verwalten, übernimmt das der Cloud Provider. Server gibt es natürlich weiterhin, das Unternehmen muss sich aber nicht mehr selbst darum kümmern. Entwicklungsteams stellen nur noch ihren Code oder Container bereit, der automatisch skaliert und nutzungsbasiert abgerechnet wird.
Daraus ergeben sich verschiedene Veränderungen und Vorteile:
Serverless ist für viele Anwendungsfälle ein Effizienzgewinn und ist teilweise schon heute fester Bestandteil moderner Plattformstrategien.
Klassische Cloud-Architekturen folgen einem klaren Prinzip: Daten werden gesammelt, in ein Rechenzentrum übertragen und dort verarbeitet. Das funktioniert gut, solange Geschwindigkeit keine kritische Rolle spielt und die Datenmenge beherrschbar bleibt. Dieser Weg wird aber immer häufiger zu langsam. Geräte am sogenannten Edge, also am Rand eines Netzwerks wie beispielsweise Maschinen in einer Produktionshalle, Fahrzeuge oder medizinische Geräte erzeugen besonders große Datenmengen. Diese alle erst in ein zentrales Rechenzentrum zu schicken, kostet Zeit und Bandbreite.
Beim Edge Computing wird ein Teil der Verarbeitung dorthin verlagert, wo die Daten entstehen. Sie findet direkt auf dem Gerät oder in unmittelbarer Nähe davon statt. Das bringt mehrere Vorteile mit sich:
Für Cloud Platform Engineering bedeutet dieser Trend, dass Plattformen künftig nicht mehr nur zentrale Rechenzentren, sondern auch dezentrale Infrastruktur an verschiedenen Standorten verwalten können müssen. Das Modell ist zwar deutlich komplexer, aber auch zukunftsfähig.
Cloud-Umgebungen wachsen. Mit der Zahl der Services, Teams und Anwendungen steigt auch die Komplexität irgendwann in Dimensionen, die manuell kaum noch beherrschbar sind. In solchen Fällen kann der Einsatz KI-gestützter Plattformverwaltung sinnvoll sein. Konkret geht es darum, wiederkehrende Aufgaben zu automatisieren und Muster zu erkennen, die für Menschen schwer zu erfassen sind. Plattformen, die KI einsetzen, können zum Beispiel:
Wichtig ist dabei: KI-gestützte Verwaltung ersetzt Plattformteams nicht, sondern ist zur Entlastung da. Der Routineaufwand sinkt, sodass sich Mitarbeitende auf Entwicklungsaufgaben fokussieren können.
Cloud-Infrastrukturen verbrauchen große Mengen an Energie. Rechenzentren gehören zu den energieintensivsten Einrichtungen überhaupt. Mit steigender Cloud-Nutzung wächst dieser Fußabdruck entsprechend weiter. Nachhaltigkeit ist damit längst zum wichtigen Trend im Cloud Platform Engineering geworden. Unternehmen reagieren darauf auf verschiedenen Ebenen:
Nachhaltigkeit und Effizienz gehen hier Hand in Hand: Optimieren Unternehmen ihren Energieverbrauch, sparen sie in der Regel auch Kosten.
Aktuelle Entwicklungen im Cloud Platform Engineering, von Serverless Architekturen über Edge Computing und KI-gestützter Verwaltung bis hin zu Green IT, sind schon heute im Einsatz. Unternehmen nutzen die Möglichkeiten schon in unterschiedlichen Reifegraden. In vielen Firmen stehen die Entwicklungen allerdings noch am Anfang, sodass wir davon ausgehen können, dass diese Trends uns noch einige Jahre begleiten werden. Beziehen Unternehmen für sie sinnvolle Trends frühzeitig in ihre Plattformstrategie ein, schaffen sie Strukturen, die sich zukünftigen Anforderungen anpassen können. Dabei ist nicht jedes Thema für jedes Unternehmen gleich relevant. Es lohnt sich aber, einen Blick auf die Möglichkeiten zu werfen.
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.
Der STACKIT Telemetry Router ist eine zentrale Komponente der STACKIT Cloud zur Verarbeitung und Weiterleitung von Telemetriedaten. Aktuell liegt der Fokus vor allem auf Audit Logs, die über standardisierte OpenTelemetry-Schnittstellen verarbeitet werden. Dieser Dienst ersetzt die STACKIT Lagacy Audit Logs zum Juni 2026.
Der Telemetry Router fungiert als zentrale Routing-Schicht für Telemetriedaten innerhalb der STACKIT Cloud. Über sogenannte Telemetry Links wird er mit Projekten, Ordnern oder Organisationen verbunden. Diese Links sorgen dafür, dass Telemetriedaten strukturiert erfasst und an den Router übergeben werden.
Wichtig ist dabei die regionale Bindung: Ein Telemetry Link kann nur mit einem Router innerhalb derselben Region verwendet werden. Dadurch entsteht eine klare und nachvollziehbare Datenstruktur.
Weitere Informationen zur Architektur des Dienst finden Sie hier: STACKIT Docs
Nach der Aufnahme durch den Router können die Daten über sogenannte Destinations an verschiedene Zielsysteme weitergeleitet werden. Dazu gehören unter anderem Observability-Stacks, Object Storage oder externe OpenTelemetry-Endpunkte. So ist beispielsweise auch die Anbindung an STACKIT Dienste wie STACKIT Observability und STACKIT Logs möglich.
Die Konfiguration der Destinations ist flexibel und erlaubt es, mehrere Zielsysteme parallel zu bedienen, ein Vorteil für hybride oder bereits bestehende Monitoring-Setups.
In ersten praktischen Tests zeigt sich, dass der Telemetry Router grundsätzlich zuverlässig arbeitet und Telemetriedaten stabil verarbeitet und weiterleitet. Die Integration in bestehende STACKIT-Umgebungen funktioniert in vielen Fällen ohne Probleme.
Allerdings merkt man auch deutlich, dass der Dienst noch in einer frühen Phase ist. Besonders bei komplexeren Setups treten gelegentlich Konfigurationsprobleme auf, etwa bei der sauberen Abstimmung von Links, Destinations und Filtern. Auch die Dokumentation deckt noch nicht alle Edge Cases ab, die in realen Umgebungen auftreten.
Ein weiterer Punkt ist der fehlende native Terraform-Support. Infrastruktur-as-Code ist in vielen Umgebungen jedoch Standard, weshalb das aktuell eine spürbare Lücke darstellt.
Der Support im STACKIT Portal ist mittlerweile schon vollständig vorhanden.
Mit dem Update des STACKIT Terraform Providers auf Version 0.98 können Telemetry-Router-Ressourcen nun direkt über die offiziell bereitgestellten Terraform-Blöcke verwaltet werden.
Damit entfällt die Notwendigkeit, auf Workarounds wie null_resource-Blöcke, individuelle REST-API-Aufrufe, die STACKIT CLI oder Curl-Skripte zurückzugreifen. Links, Destinations und weitere Konfigurationen lassen sich vollständig deklarativ über Terraform definieren und im regulären Infrastruktur-Lebenszyklus verwalten.
Die Nutzung der offiziellen Provider-Ressourcen vereinfacht nicht nur die Implementierung, sondern verbessert auch Wartbarkeit, Nachvollziehbarkeit und Konsistenz von Deployments. Anwender profitieren dabei von den üblichen Terraform-Funktionen wie State Management, Plan-Validierung und Drift Detection.
Für neue Implementierungen sowie bestehende Automatisierungen empfehlen wir daher, die mit Version 0.98 eingeführten Terraform-Ressourcen zu verwenden und auf bisherige API-basierte Workarounds zu verzichten.
Ein besonders interessanter Anwendungsfall des Telemetry Routers ist die Integration direkt in Anwendungen. Applikationslogs können dabei aus den Services ausgelagert und zentral über den Telemetry Router verarbeitet werden. Statt Logs lokal zu speichern oder direkt an einzelne Backend-Systeme zu senden, werden sie als Telemetriedaten erfasst und über einen Telemetry Link an den Router übergeben.
Von dort aus lassen sich die Daten flexibel weiterleiten, beispielsweise in einen Object Storage Bucket zur langfristigen Archivierung oder in einen zentralen Log-Dienst zur Analyse und Visualisierung. Das erleichtert nicht nur die Entkopplung der Anwendungen von der Logging-Infrastruktur, sondern sorgt auch für eine einheitliche und skalierbare Logging-Pipeline über mehrere Services hinweg.
Gerade in verteilten Systemen oder Microservice-Architekturen entsteht dadurch ein klarer Vorteil: Logs müssen nicht mehr pro Anwendung individuell verarbeitet werden, sondern folgen einem zentral gesteuerten Observability-Ansatz innerhalb der STACKIT Cloud.
Der STACKIT Telemetry Router ist eine vielversprechende Komponente für modernes Observability-Management in der Cloud. Die grundlegende Architektur mit Links, Destinations und Filterlogik ist durchdacht und funktioniert bereits gut im Alltag, obwohl es sich noch in der Beta befindet.
Wechseln Unternehmen in die Cloud, stehen sie schnell vor einer wichtigen Frage: Wie stellen wir sicher, dass aus einem vielversprechenden Start kein unkontrolliertes Wachstum wird? Der Aufbau von Landing Zones kann die Antwort darauf sein. Sie schaffen die Grundlage, auf der Teams sicher, effizient und eigenständig arbeiten können, ohne dass Sicherheit oder Ordnung auf der Strecke bleiben. In diesem Artikel zeigen wir, wie Landing Zones als Teil des Cloud Platform Engineerings funktionieren und warum sie weit mehr sind als ein technisches Setup.
Cloud Landing Zones klingen erst einmal sehr abstrakt, stellen aber letztendlich nichts anderes dar als eine vorbereitete und geplante Umgebung. Zum Vergleich: Stellen Sie sich vor, ein Unternehmen bezieht ein neues Bürogebäude. Bevor die ersten Mitarbeitenden ihre Arbeitsplätze beziehen, werden Zugangssysteme installiert, Netzwerke eingerichtet und Brandschutzregeln festgelegt. Niemand würde einfach loslegen und hoffen, dass sich alles irgendwie ergibt. Eben dieses Prinzip steckt auch hinter dem Aufbau von Landing Zones in der Cloud.
Eine Landing Zone ist eine vorkonfigurierte, sichere Umgebung innerhalb der Cloud-Infrastruktur. Sie definiert von Anfang an, wie Ressourcen organisiert werden, welche Sicherheitsanforderungen gelten und wie Teams miteinander und mit der Infrastruktur interagieren. Sie ist damit der geordnete Rahmen, in dem Cloud-Nutzung erst richtig funktioniert.
Im Cloud Platform Engineering nimmt der Aufbau von Landing Zones eine wichtige Rolle ein. Cloud Platform Engineering insgesamt sorgt dafür, dass Entwicklungsteams produktiv und sicher in der Cloud arbeiten können. Landing Zones wiederum sind das strukturelle Fundament dafür. Ohne sie fehlt die gemeinsame Ausgangsbasis, sodass Teams im schlimmsten Fall parallel zueinander, mit unterschiedlichen Standards und großem Aufwand für alle Beteiligten arbeiten.
Governance klingt zuerst nach Kontrolle, Bürokratie und langen Freigabeprozessen. Im Kontext des Aufbaus von Landing Zones bedeutet es jedoch etwas anderes: Governance schafft automatisierte Leitplanken, die sicherstellen, dass Entwicklungsteams gar nicht erst in problematische Bereiche geraten können, ohne dass jemand jeden Schritt manuell prüfen muss.
Das Prinzip dahinter ist einfach: Regeln werden nicht als Checkliste verteilt, an die sich alle halten müssen, sondern stattdessen direkt in die Infrastruktur eingebaut. Setzt jemand eine neue Umgebung in der Cloud auf, bekommt er oder sie automatisch den richtigen Rahmen mitgeliefert.
Konkret können solche Governance-Regeln zum Beispiel so aussehen:
Was zunächst nach Einschränkung klingt, ist in der Praxis nützlich. Entwicklungsteams gewinnen durch klar definierte Regeln mehr Autonomie. Sie müssen sich nicht mit Sicherheitsfragen beschäftigen, die eigentlich Aufgabe der Plattform sind und können sich voll auf ihre eigentliche Arbeit konzentrieren.
Der Aufbau von Landing Zones wird oft fälschlicherweise als einmaliges Infrastrukturprojekt verstanden, das nach einem Projektzeitraum abgeschlossen ist. In der Realität zeigen Landing Zones ihren größten Nutzen erst dann, wenn sie tief in die alltäglichen Arbeitsprozesse der Entwicklungsteams integriert sind.
Der wichtigste Schritt ist die Verbindung mit bestehenden DevOps-Prozessen. Konkret bedeutet das: Wenn ein Team eine neue Anwendung in der Cloud entwickeln will, muss es nicht mehr händisch Umgebungen beantragen, Zugriffsrechte klären oder Pipelines von Grund auf aufsetzen. Stattdessen stellt die Landing Zone automatisch bereit, was gebraucht wird, zum Beispiel:
Diese Automatisierungen haben einen direkten Effekt auf die Arbeitsgeschwindigkeit. Teams starten nicht bei null, sondern können auf einer fertigen, geprüften Grundlage mit der Arbeit beginnen. Gleichzeitig wird sichergestellt, dass alle Umgebungen nach denselben Standards aufgebaut sind. Das passiert unabhängig davon, welches Team sie anlegt oder wann. Besonders in größeren Unternehmen, in denen viele Teams parallel in der Cloud arbeiten, macht dieser Unterschied sich deutlich bemerkbar. Ohne Landing Zones entsteht schnell ein Flickenteppich aus unterschiedlichen Konfigurationen, durch den irgendwann niemand mehr vollständig durchblickt. Mit Landing Zones bleibt die Infrastruktur konsistent und damit auch wartbar.
Der Aufbau von Landing Zones ist für Unternehmen eine wichtige und grundlegende Entscheidung. Sie schaffen durch die solide Grundstruktur die Voraussetzung dafür, dass Cloud-Nutzung langfristig funktioniert und sicher, effizient und skalierbar bleibt. Governance-Regeln schützen die Infrastruktur dabei, ohne Teams auszubremsen, die Verzahnung mit DevOps-Prozessen wiederum sorgt dafür, dass Teams schnell und eigenständig arbeiten können. Indem sie Landing Zones von Anfang an richtig aufbauen, legen Unternehmen den wichtigen Grundstein für eine Cloud-Infrastruktur, die mit den Anforderungen des Unternehmens wachsen kann.
Mit STACKIT VPN (bzw. STACKIT Managed VPN) bietet STACKIT einen vollständig verwalteten Service für sichere Site-to-Site-VPN-Verbindungen. Der Dienst hat mittlerweile den Status General Availability (GA) erreicht und ist über die API, das STACKIT Portal sowie teilweise über den Terraform Provider nutzbar.
Für Umgebungen, die konsequent auf Infrastructure as Code setzen, bestehen derzeit noch einige Einschränkungen: Im Terraform Provider wird aktuell lediglich die Verwaltung von STACKIT VPN Gateways unterstützt, während die Konfiguration von VPN Connections noch nicht implementiert ist. Mit überschaubarem zusätzlichem Entwicklungsaufwand lässt sich der Dienst jedoch bereits heute, durch die Verwendung der API, gut in bestehende Automatisierungs- und Deployment-Prozesse integrieren.
Das STACKIT VPN kann nur in Verbindung mit einer STACKIT Network Area genutzt werden. Die Network Area fungiert als zentrales Routing‑Konstrukt und ermöglicht es, Netzwerke, Projekte und deren virtuelle Netze übergreifend miteinander zu verbinden.
Das VPN Gateway erhält eine zentrale IP‑Adresse aus der Network Area, und über statische Routen werden die CIDR‑Ranges weiterer Netzwerke dorthin geleitet. Dadurch eignet sich der Service besonders gut für Hub‑and‑Spoke‑Architekturen.
Das STACKIT VPN unterscheidet zwischen zwei Ressourcentypen:
Das VPN Gateway bildet den zentralen Einstiegspunkt und definiert die grundlegenden Eigenschaften der VPN‑Anbindung:
Für jede angegebene Availability Zone wird automatisch ein eigenes Tunnel Interface erzeugt. Dadurch entstehen immer zwei Tunnel, was eine hochverfügbare Anbindung ermöglicht.
Hinweis: SKUs bzw. Performanceklassen können nicht herabgestuft werden. Wenn eine kleinere Leistungsstufe benötigt wird, ist ein entsprechendes Redeployment erforderlich.
Ein VPN Gateway kann mit einer oder mehreren VPN Connection‑Ressourcen verknüpft werden.
In diesen Objekten wird die eigentliche Site‑to‑Site‑Verbindung definiert:
STACKIT unterstützt alle gängigen modernen Verschlüsselungs‑ und Integritätsalgorithmen, was eine sehr gute Interoperabilität mit gängigen Gegenstellen ermöglicht.
Die Hochverfügbarkeit ist integraler Bestandteil des Designs:
Das erhöht zwar minimal den Konfigurationsaufwand, sorgt aber für eine ausfallsichere Verbindung.
Die Konfiguration erfolgt aktuell ausschließlich über die STACKIT API. In der Praxis lässt sich das sehr gut mit Terraform umsetzen, beispielsweise über Local Blocks und den offiziellen STACKIT Terraform Provider. Auch Beta‑Ressourcen werden unterstützt. Es ist nur eine Frage der Zeit, bis der das STACKIT VPN vollwertig mit eigenen STACKIT Terraform Resource-Blocks unterstützt wird.
Für IaC‑getriebene Umgebungen ist das STACKIT VPN dadurch gut reproduzierbar und versionskontrolliert betreibbar.
Unsere bisherigen Erfahrungen mit STACKIT Managed VPN sind durchweg positiv. Der Aufbau der VPN-Tunnel funktionierte in verschiedenen Szenarien zuverlässig und ohne größere Herausforderungen. Auch im laufenden Betrieb erwiesen sich die Verbindungen über längere Zeiträume hinweg als stabil. Die Unterstützung moderner IPsec-Algorithmen trägt zusätzlich zu einer sicheren und zuverlässigen Konnektivität bei.
Derzeit größte Einschränkung ist die noch begrenzte Transparenz des Dienstes. Der Service bietet aktuell zwar die Möglichkeit per GUI oder API den Status der Komponenten abzufragen, jedoch keine Möglichkeit, Logs oder Metriken für Monitoring- und Analysezwecke zu exportieren.
Für viele Network Engineers dürfte außerdem die Bezeichnung der Schlüsselaustauschgruppen zunächst ungewohnt sein. Während in der Praxis häufig die klassischen IPsec-DH-Gruppennummern (z. B. Gruppe 19, 20 oder 21) verwendet werden, setzt STACKIT auf die kryptografischen Gruppenbezeichnungen wie ecp256, ecp384 oder ecp521. Technisch handelt es sich um dieselben elliptischen Kurven, die alternative Benennung kann bei der Konfiguration jedoch zunächst für Verwirrung sorgen.
Ebenfalls erwähnenswert sind die vergleichsweise strengen Anforderungen an den Pre-Shared Key (PSK). Dieser muss:
Diese Vorgaben sind aus Sicherheitsgründen nachvollziehbar, sollten jedoch bei der Planung und Automatisierung von VPN-Verbindungen berücksichtigt werden.
Das STACKIT VPN ist unserer Meinung nach ein technisch ausgereifter Dienst:
Sobald die Terraform-Unterstützung vollständig verfügbar ist, dürfte sich der Service auch für Infrastructure-as-Code-affine Teams deutlich wartbarer und sauberer integrieren lassen. Für Teams, die primär über API oder Web-UI arbeiten, ist STACKIT VPN eine sehr solide und praxistaugliche Lösung.
Die Cloud verspricht Flexibilität, schnelle Skalierung und moderne Infrastruktur. Viele Unternehmen erleben jedoch nach den ersten Monaten eine unangenehme Überraschung: Die monatliche Rechnung wächst schneller als der Mehrwert. Dabei liegt das Problem selten an der Cloud selbst. Vielmehr liegt es darin, wie sie genutzt wird. Möchten Unternehmen ihre Cloud-Kosten nachhaltig im Griff halten, brauchen sie mehr als nachträgliche Sparmaßnahmen. Wir zeigen in diesem Artikel, wie Unternehmen die Kostenoptimierung in der Cloud von der Wahl des Abrechnungsmodells bis hin zur Berücksichtigung von Kosten schon im Cloud Platform Engineering erfolgreich umsetzen können.
Wer zum ersten Mal eine Cloud-Rechnung aufschlüsselt, steht oft vor einer langen Liste an Posten: Rechenleistung, Speicher, Datentransfer, Support-Tarife. Der Grund für diese Komplexität liegt im Grundsatz vieler Cloud-Modelle: Anders als klassische On Premises IT-Infrastruktur wird Cloud-Nutzung in der Regel nicht pauschal abgerechnet, sondern verbrauchsabhängig. Verstehen Unternehmen, welches Modell wann sinnvoll ist, ist das ein Kostenvorteil. Andernfalls kann es jedoch schnell zur Kostenfalle werden. Die meisten Cloud Provider arbeiten mit ähnlichen Abrechnungsformen, die sich je nach Anbieter in Name und Details unterscheiden können.
Zusätzlich dazu bieten viele Anbieter weitere Einsparmöglichkeiten, die sich je nach Situation lohnen können:
Die Herausforderung für Unternehmen liegt vor allem darin, die Abrechnungsformen sinnvoll miteinander zu kombinieren. Viele Unternehmen starten mit nutzungsbasierter Abrechnung und vergessen, die Abrechnungsform später anzupassen, obwohl ein Großteil der Workloads mittlerweile stabil und planbar wäre. Mit diesem Verständnis beginnt die eigentliche Kostenoptimierung in der Cloud.
Die Kostenoptimierung der Cloud-Umgebung ist ein kontinuierlicher Prozess. Zwei Faktoren sind dabei besonders wichtig: Automatisierung und Kostentransparenz. Beide sollten unbedingt schon beim Aufbau der Cloud-Infrastruktur berücksichtigt werden, um zuverlässige Kostenoptimierung zu ermöglichen.
Beim Cloud Platform Engineering geht es um den strukturierten Aufbau einer internen Plattform, auf der Entwicklungsteams ihre Anwendungen betreiben. Dabei geht es besonders auch darum, wie Ressourcen von Grund auf verantwortungsvoll genutzt werden können. Schon im Aufbau der Cloud-Plattform hat das Team demnach die Aufgabe, entsprechende Maßnahmen nach Möglichkeit in die Plattform zu integrieren, zum Beispiel:
Neue Projekte starten so von Beginn an in einer Umgebung, die kosteneffizientes Verhalten unterstützt, etwa durch vordefinierte Budgetgrenzen pro Team oder automatische Warnmeldungen bei ungewöhnlich hohem Verbrauch.
Einer der häufigsten Kostentreiber in der Cloud ist denkbar simpel: Systeme laufen, obwohl sie gerade niemand braucht, Testumgebungen bleiben am Wochenende aktiv, Rechenleistung läuft nachts auf vollen Touren, obwohl keine Anfragen eingehen.
Durch automatisiertes Skalieren können Cloud-Teams dieses Problem lösen, indem Kapazitäten dynamisch an den tatsächlichen Bedarf angepasst werden: nach oben bei hoher Last, nach unten oder ganz aus bei Leerlauf. Was früher manuelle Eingriffe erfordert hätte, lässt sich heute regelbasiert steuern. Unternehmen können selbst definieren, wann eine Umgebung läuft und wann nicht und haben so einen starken Einfluss auf ihre Cloud-Kosten.
Wichtig: Eine automatische Abschaltung der Ressourcen ist allerdings nicht in jeder Umgebung möglich, etwa wenn Systeme rund um die Uhr verfügbar sein müssen. In solchen Fällen ist zuverlässiges Alerting umso wichtiger: Warnmeldungen bei ungewöhnlich hohem Verbrauch oder ungeplanten Laufzeiten helfen Unternehmen, teure Ressourcen zu erkennen, bevor sie die nächste Rechnung in die Höhe treiben.
Automatisierung funktioniert nur, wenn überhaupt sichtbar ist, welche Ressourcen und Prozesse wann laufen. Deshalb ist Kosten-Reporting ein so wichtiger Faktor. Dashboards und Auswertungen machen sichtbar, welche Teams, Projekte oder Anwendungen wie viel verbrauchen und wo es noch Optimierungspotenzial gibt. Viele Cloud-Anbieter stellen dafür eigene Tools bereit wie etwa Azue Advisor, die konkrete Einsparpotenziale aufzeigen. Sie identifizieren beispielsweise überdimensionierte Ressourcen und schlagen eine bedarfsgerechte Anpassung vor.
Im Rahmen von FinOps, einem Framework, das Finanz-, Entwicklungs- und Betriebsteams bei Cloud-Kosten zusammenbringt, ist Transparenz die Grundlage für alle weiteren Entscheidungen. Indem Teams Kosten sichtbar machen, ermöglichen sie Verantwortlichkeit: Sie sehen, was ihre Entscheidungen kosten und können entsprechend gegensteuern. Wichtig ist dabei außerdem, frühzeitig zu klären, wie lange Kostendaten aufbewahrt werden sollen. Manche Anbieter speichern historische Kostendaten nur für einen begrenzten Zeitraum. Sollen langfristige Auswertungen oder Vergleiche angestellt werden, sollten die Daten regelmäßig exportiert und extern gesichert werden.
Wie kann Kostenoptimierung konkret aussehen, wenn sie schon im Plattformaufbau berücksichtigt wird? Potenzial liegt oft in verschiedenen Bereichen.
Kostenoptimierung in der Cloud ist kein einmaliges Projekt, das nach einigen Wochen oder Monaten abgeschlossen ist. Vielmehr geht es darum, Kostenbewusstsein von Anfang an als Teil der Plattform zu verstehen: eingebaut in Prozesse, Automatisierungen und Reporting-Strukturen. Das FinOps Framework liefert den organisatorischen Rahmen, Cloud Platform Engineering schafft das technische Fundament. Bringen Unternehmen beides zusammen, schaffen sie eine Infrastruktur, die mit neuen Anforderungen wachsen kann, effizient und transparent läuft und deren Kosten dauerhaft unter Kontrolle bleiben.
Warum Identitäten manuell verwalten, wenn Provisionierung das automatisch erledigt?
Identitäten sollten in STACKIT nicht isoliert gepflegt werden müssen. Die Provisionierung kann auch von dem bestehenden IdP seiner Wahl übernommen werden. Während Single Sign-On (SSO) den Zugriff vereinfacht, kümmert sich SCIM (System for Cross-domain Identity Management) um den nächsten logischen Schritt, die automatisierte Bereitstellung von Benutzern und Gruppen.
So entsteht ein durchgängiger Identity Lifecycle: vom Anlegen über Änderungen bis hin zur Deaktivierung, ohne manuelle Eingriffe in STACKIT.
Warum ist das wichtig?
In STACKIT sind User Accounts entkoppelt von den Organisationen. Das heißt, anders als beispielsweise in Microsoft Entra ID existieren die User Accounts in STACKIT nicht nativ unter einem Verzeichnisdienst je Kunde, sondern sind unabhängig voneinander. User Accounts können frei erstellt werden und sind nativ mit keinen STACKIT Organisationen bzw. Ressourcen assoziiert. Dafür ist erst ein Roleassignment nötig.
Neue Mitarbeitende, Rollenwechsel oder Austritte werden direkt aus dem führenden Identity Provider übernommen. Benutzer und Gruppen erscheinen automatisch in STACKIT bzw. werden an Änderungen angepasst oder gelöscht.
Gruppen aus dem Identity Provider lassen sich in STACKIT direkt für Role Bindings verwenden. Dadurch entstehen klare, wiederverwendbare Zugriffsmuster statt individueller Einzelberechtigungen.
Durch die zentrale Pflege im Identity Provider gibt es eine eindeutige Quelle für Identitäten. Das reduziert Inkonsistenzen und verbessert Auditierbarkeit sowie Compliance.
STACKIT trennt bewusst zwischen Authentifizierung und Identitätsverwaltung:
Diese Architektur vermeidet doppelte Datenhaltung und sorgt dafür, dass Identitäten immer aus einer zentralen Quelle stammen.
Der STACKIT SCIM-Endpunkt unterstützt die wichtigsten Ressourcen für modernes Identity Management:
Besonders relevant: Heute existieren noch keine STACKIT Gruppen Objekte. Durch die Verwendung von SCIM wird in STACKIT die Möglichkeit gegeben, Gruppen überhaupt erst zu nutzen. Durch SCIM können Gruppenmitgliedschaften dynamisch aktualisiert werden. Damit lassen sich Zugriffe indirekt über Gruppen steuern, was einen entscheidender Vorteil für skalierbare IAM-Konzepte darstellt.
SSO und SCIM erfüllen unterschiedliche, aber komplementäre Aufgaben:
Erst die Kombination ermöglicht ein sauberes Betriebsmodell:
Ein Benutzer wird im Identity Provider angelegt → per SCIM nach STACKIT provisioniert → authentifiziert sich per SSO → erhält Zugriff über Gruppen und Rollen:
Warum mehrere Identitäten verwalten, wenn Single Sign-On alles vereinfacht?
STACKIT setzt bewusst auf einen föderierten Ansatz für Identitäten. Statt Benutzerkonten neu anzulegen, werden bestehende Identitäten sicher angebunden. Genau hier kommt eine Identity Provider Federation mit Single Sign-On (SSO) ins Spiel. Sie reduziert den administrativen Aufwand und stärkt gleichzeitig Security, Compliance und Governance. Wir zeigen, wie die STACKIT SSO Integration funktioniert und geben ein Praxisbeispiel für die Integration mit Entra ID.
Mit einer föderierten Anmeldung lassen sich vorhandene Conditional Access Policies übernehmen, zum Beispiel für Geofilter oder Multi-Faktor-Authentifizierung (MFA).
Risikosignale wie Risky User oder Risky Sign-In können zentral bewertet und genutzt werden. Das erhöht die Sicherheit und sorgt für konsistente Entscheidungen.
Mitarbeitende müssen nicht mehrere Konten und Passwörter verwalten. Ein zentraler Login über den eigenen Identity Provider macht den Zugang einfacher und komfortabler.
STACKIT ist kein klassischer Identity Provider (IdP). Stattdessen agiert STACKIT als Relying Party und vertraut für die Authentifizierung auf einen externen Identity Provider.
Diese Entscheidung ist bewusst getroffen und bringt klare Vorteile:
Die Authentifizierung erfolgt extern, während STACKIT die Autorisierung übernimmt.
Durch die Identity Provider Federation können bestehende Verzeichnisdienste direkt genutzt werden, zum Beispiel:
STACKIT setzt auf etablierte Protokolle für die föderierte Anmeldung:
Mehr Informationen finden Sie hier: STACKIT IdP verstehen
In vielen Organisationen ist Microsoft Entra ID bereits die zentrale Identitätsplattform. Die Integration mit STACKIT erfolgt über OpenID Connect und folgt immer dem gleichen Prinzip:
Die Entra-ID-Integration folgt einem klaren, kontrollierten Ablauf:
Für den erfolgreichen Einsatz von Strategien, Technologien und Konzepten in Ihrem Unternehmen.
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].
