So standardisierst du die App-Bereitstellung über AWS, Azure und GCP hinweg

Workloads über AWS, Azure und GCP hinweg auszuführen, ist für die meisten Engineering-Teams in Unternehmen die operative Realität. Die Herausforderung sind nicht die Anbieter selbst, sondern das, was passiert, wenn jeder seine eigene Bereitstellungs-Pipeline, seine eigene Sicherheitskonfiguration und seine eigenen Tools zur Umgebungsverwaltung aufbaut. Was als Flexibilität der Anbieter beginnt, wird still und leise zu anbieterspezifischer Komplexität, die sich auf jedes Team auswirkt, das Workloads bereitstellt.

Die Kosten dieser Komplexität sind kein hypothetisches Problem. Laut Benchmarks für das Jahr 2026 aus der cloud-TCO-Analyse von DataStackHub machen die betrieblichen Gemeinkosten (die Management-, Governance- und Tooling-Ebene, die über den reinen Infrastrukturkosten liegt) mittlerweile 25 bis 30 % der gesamten cloud-TCO aus. Für die meisten cloud-Landschaften in Unternehmen ist das kein Rundungsfehler. Es ist eine strukturelle Belastung für jeden Lieferzyklus, die mit der Anzahl der Anbieter steigt, anstatt mit zunehmender Reife der Cloud-Umgebung abzunehmen.

Was es tatsächlich wert ist, anbieterübergreifend zu standardisieren

Das Wichtigste auf einen Blick: Nicht alles muss bei AWS, Azure und GCP einheitlich sein. Die Bereitstellungsschicht schon. Die Diensteebene nicht. Diese Grenze richtig zu ziehen, macht den Unterschied zwischen einem Standard, der Geschwindigkeit ermöglicht, und einem, der dem Anbieter-Ökosystem entgegenwirkt.

Der Instinkt angesichts der Komplexität von Multicloud-Umgebungen ist entweder, alles zu standardisieren – was bedeutet, auf anbieterspezifische Funktionen zu verzichten, die echten Mehrwert bieten – oder jedem Anbieter zu erlauben, die Dinge auf seine eigene Art zu handhaben, was bedeutet, dass sich die Komplexität mit jedem neuen Team und jeder neuen Arbeitslast vervielfacht. Keines dieser Extreme funktioniert.

Die praktische Lösung besteht darin, die Grenze auf der Bereitstellungsebene zu ziehen: der einheitlichen operativen Ebene, die über den einzelnen Anbieterdiensten liegt und regelt, wie Code vom Commit in die Produktivumgebung gelangt. Diese Ebene sollte identisch sein, unabhängig davon, welcher Anbieter darunter liegt. Alles darunter – der spezifische Datenbankdienst, die ML-Plattform, die Rechenkonfiguration – kann anbieterspezifisch bleiben, wo diese Spezifität einen Mehrwert bietet.

In der Praxis gehören drei Dinge in die standardisierte Ebene:

1. Umgebungsdefinitionen
   Wie eine Entwicklungs-, Staging- oder Produktionsumgebung konfiguriert ist, sollte in einer einzigen versionsverwalteten Datei festgehalten werden, die auf AWS, Azure und GCP gleich funktioniert. Wenn die Umgebungskonfiguration anbieterspezifisch ist, müssen Paritätsprüfungen manuell durchgeführt werden und es kommt bei jedem Anbieter separat zu Abweichungen in der Umgebung. Bei einer Standardisierung ist die Parität strukturell gewährleistet.
2. Pipeline-Logik
   Der Weg von einem Git-Commit zu einer laufenden Umgebung (Build, Test, Sicherheitsgate, Deployment) sollte unabhängig davon, auf welchen Anbieter die Workload abzielt, immer derselben Abfolge und denselben Regeln folgen. Anbieterspezifische Pipelines bedeuten anbieterspezifische Fehlermodi, anbieterspezifische Compliance-Nachweise und anbieterspezifisches „Stammwissen“. Eine einheitliche Pipeline bedeutet einen einzigen Prüfpfad, einen Satz von Gates und eine Definition von „ausgeliefert“, die überall gilt.
3. Richtlinien und Zugriffskontrollen
   Sicherheitsrichtlinien, Zugriffsbereichsfestlegung und Compliance-Kontrollen sollten einmalig definiert und auf der Bereitstellungsebene durchgesetzt werden, anstatt in der Konsole jedes Anbieters separat konfiguriert zu werden. Genau hier liegen die meisten Lücken in der Multicloud-Governance. Laut der „Cyber Security Breaches Survey 2026“ der britischen Regierung haben 43 % der Unternehmen im vergangenen Jahr eine Cybersicherheitsverletzung oder einen Angriff festgestellt, und von diesen war knapp die Hälfte von tatsächlicher Cyberkriminalität mit spürbaren Auswirkungen betroffen. Wenn Kontrollen in der Konsole jedes Anbieters separat konfiguriert werden, werden sowohl die Erkennung als auch die Eindämmung schwieriger (eine Fehlkonfiguration in einer Umgebung wird erst sichtbar, wenn sie in einer anderen ausgenutzt wird). Governance, die an der Anbietergrenze endet, ist keine Governance. Es handelt sich um eine anbieterbezogene Konfigurationsmaßnahme, die aus dem Ruder läuft, sobald eine Einstellung in einer Konsole geändert wird, in den anderen jedoch nicht.

Was anbieterspezifisch bleiben kann

Das Wichtigste auf einen Blick: Die Standardisierung der Bereitstellungsschicht bedeutet nicht, auf die Dienste zu verzichten, die den Einsatz einzelner Anbieter lohnenswert machen. Es bedeutet, diese Dienste von der Bereitstellungslogik zu entkoppeln, damit sie genutzt werden können, ohne Governance-Lücken zu schaffen.

Der Grund, warum die meisten Standardisierungsbemühungen in der Multicloud ins Stocken geraten, ist, dass sie als Einschränkung der Anbieterfunktionen betrachtet werden und nicht als darüber liegende Governance-Ebene. Teams wehren sich gegen die Standardisierung, weil sie diese so interpretieren: „Du darfst den verwalteten Datenbankdienst, um den herum du deinen Stack aufgebaut hast, nicht nutzen.“ Das ist nicht das, was die Standardisierung der Bereitstellungsschicht erfordert.

Anbieterspezifische Dienste – RDS bei AWS, Cosmos DB bei Azure, BigQuery bei GCP – können genau dort bleiben, wo sie sind. Die Standardisierung betrifft die Art und Weise, wie diese Dienste verbunden, konfiguriert und gesteuert werden, nicht die Auswahl der Dienste selbst. Eine versionsverwaltete Konfigurationsdatei, die eine Datenbankabhängigkeit festlegt, kümmert sich nicht darum, auf die Datenbank welches Anbieters sie verweist. Eine Bereitstellungs-Pipeline, die ein Sicherheitsgate durchsetzt, kümmert sich nicht darum, auf welcher Recheninstanz welches Anbieters die Workload ausgeführt wird.

Das ist der Unterschied, der das Modell praktisch und nicht nur theoretisch macht. Teams behalten die Freiheit, den besten Dienst für die jeweilige Aufgabe auszuwählen. Die Bereitstellungsschicht stellt sicher, dass diese Auswahl dokumentiert, überprüfbar und reproduzierbar ist – unabhängig davon, welcher Anbieter den Dienst bereitstellt.

Das gemeinsame Bereitstellungsmodell in der Praxis

Das Wichtigste auf einen Blick: Ein anbieterübergreifendes Shared-Delivery-Modell ist keine Architektur nach dem kleinsten gemeinsamen Nenner. Es ist eine einheitliche operative Basis, die anbieterspezifische Funktionen besser nutzbar macht – nicht schlechter.

Der Wert eines gemeinsamen Bereitstellungsmodells ergibt sich aus drei Dimensionen, die speziell für ITMMs von Bedeutung sind:

Transparenz bei der Governance:
Wenn Pipeline-Logik, Umgebungsdefinitionen und die Durchsetzung von Richtlinien anbieterübergreifend standardisiert sind, ist der Prüfpfad einheitlich statt fragmentiert. Nachweise zur Compliance werden automatisch als Nebenprodukt jeder Bereitstellung bei jedem Anbieter erstellt, anstatt vor jedem Überprüfungszyklus manuell aus drei separaten Konsolenprotokollen zusammengestellt zu werden. Das Team, das AWS verwaltet, erstellt keine anderen Nachweise als das Team, das Azure verwaltet – beide erstellen dieselben Nachweise aus derselben Bereitstellungsschicht.

Bereitstellungsgeschwindigkeit
Laut dem DORA 2024 State of DevOps Report stellen leistungsstarke Entwicklungsteams 182-mal häufiger bereit als leistungsschwache, mit 127-mal schnelleren Durchlaufzeiten und 8-mal niedrigeren Ausfallraten bei Änderungen. Der entscheidende Faktor ist nicht die Mitarbeiterzahl oder das Budget, sondern der Grad, in dem die Bereitstellung systematisiert wurde, anstatt sie den Unterschieden zwischen den einzelnen Umgebungen zu überlassen. Ein Team, das mit derselben Pipeline, denselben Umgebungsdefinitionen und denselben Gates auf AWS und Azure bereitstellen kann, macht die Arbeit nicht zweimal. Es macht sie nur einmal, wobei der Anbieter als Ausgabevariable und nicht als Einschränkung dient.

Operative Ausfallsicherheit
Wenn es bei einem Anbieter zu einem Ausfall oder einer Dienstunterbrechung kommt, erholen sich jene Unternehmen am schnellsten, deren Bereitstellungsschicht nicht an die Tools des ausgefallenen Anbieters gekoppelt ist. Befinden sich die Pipeline, die Umgebungsdefinitionen und die Durchsetzung der Richtlinien alle bei dem ausgefallenen Anbieter, muss das ausgefallene System selbst an seiner Wiederherstellung mitwirken. Befinden sie sich hingegen in einer gemeinsamen Bereitstellungsschicht oberhalb des Anbieters, kann die Workload verlagert werden, ohne dass die operative Infrastruktur drumherum neu aufgebaut werden muss.

Das Ziel erreichen, ohne alles neu aufzubauen

Das Wichtigste auf einen Blick: Die Standardisierung der Bereitstellung über verschiedene Anbieter hinweg erfordert weder die Migration von Workloads noch den Ersatz anbieterspezifischer Dienste. Es geht darum, die Bereitstellungsschicht zu kodifizieren und sie ab dem nächsten neuen Projekt konsequent anzuwenden.

Die Frage, die ITMMs beim Übergang am häufigsten stellen, ist genau die richtige: Erfordert das eine Big-Bang-Migration? Nein, tut es nicht. Der praktische Ansatz folgt derselben Abfolge, die auch bei der Standardisierung mit einem einzigen Anbieter funktioniert:

Neue Projekte starten vom ersten Commit an auf dem gemeinsamen Bereitstellungsmodell. Jede neue Workload, unabhängig davon, auf welchen Anbieter sie abzielt, wird vom ersten Tag an in der standardisierten Konfigurationsebene definiert. Das verhindert, dass die Fragmentierung weiter zunimmt, während bestehende Workloads schrittweise angepasst werden.

Bestehende Workloads werden bei passender Gelegenheit migriert. Wenn aktiv an einem Dienst gearbeitet wird (ein Feature-Zyklus, ein Upgrade von Abhängigkeiten, eine Sicherheitskorrektur), wird die Bereitstellungsschicht im Rahmen dieser Arbeit standardisiert und nicht in einem eigenen Migrationssprint. Die Kosten der Migration werden in die bereits laufenden Arbeiten integriert.

Die Konfigurationsebene kommt zuerst. Noch vor den Pipelines, noch vor den Zugriffskontrollen, noch vor der Observability: Lege fest, wie Umgebungen anbieterübergreifend definiert werden. Dieser einzelne Schritt schließt die Lücke bei der Umgebungsparität bei jedem Anbieter gleichzeitig und macht jeden nachfolgenden Standardisierungsschritt kostengünstiger in der Umsetzung.

Wenn man in dieser Reihenfolge vorgeht, laufen die meisten aktiven Dienste innerhalb eines Standard-Planungszyklus auf dem gemeinsamen Bereitstellungsmodell, ohne eine einzige erzwungene Umstellung und ohne die anbieterspezifischen Dienste zu stören, auf die sich die Teams gestützt haben.

Sieh dir die Referenzarchitektur für portable Umgebungen mit Richtlinien-Leitplanken an.

Häufig gestellte Fragen (FAQ)

Muss man dafür für alles denselben cloud-Anbieter nutzen? 

Nein. Das Shared-Delivery-Modell ist speziell darauf ausgelegt, gleichzeitig über AWS, Azure und GCP hinweg zu funktionieren. Die Standardisierung erfolgt auf der Bereitstellungsebene (wie Umgebungen definiert werden, wie Pipelines ablaufen, wie Richtlinien durchgesetzt werden) und nicht auf der Infrastrukturebene, auf der die Wahl des Anbieters stattfindet. Die Teams nutzen weiterhin die Dienste des Anbieters, die am besten zu ihrer Arbeitslast passen; die Bereitstellungsebene sorgt für die Konsistenz darüber hinaus.

Wie funktioniert das Zusammenspiel mit anbieterspezifischen IAM- und Zugriffskontrollsystemen? 

Jeder Anbieter hat sein eigenes Identitäts- und Zugriffsmanagementsystem, und diese bleiben weiterhin bestehen. Was die Standardisierung auf der Bereitstellungsebene bietet, ist eine einheitliche Richtliniendefinition, die auf die Zugriffskontrollen der einzelnen Anbieter abgebildet wird, anstatt in jeder Konsole separat konfiguriert zu werden. Die Richtlinie wird einmal definiert; die Bereitstellungsebene übersetzt sie in die entsprechenden anbieterspezifischen Kontrollen. Das verringert das Risiko inkonsistenter Zugriffskonfigurationen zwischen den Anbietern – eine der häufigsten Ursachen für Sicherheitsvorfälle in Multicloud-Umgebungen.

Was passiert mit unseren bestehenden anbieterspezifischen Pipelines? 

Sie müssen nicht sofort ersetzt werden. Das Übergangsmodell ist schrittweise: Neue Projekte nutzen von Anfang an die gemeinsame Delivery-Ebene, und bestehende Pipelines werden migriert, sobald aktiv an den von ihnen bedienten Diensten gearbeitet wird. Das Ziel ist es, keine neue Fragmentierung mehr entstehen zu lassen und gleichzeitig bestehende Fragmentierung zu beseitigen, sobald sich die Gelegenheit dazu ergibt.

Wie wirkt sich das auf Teams aus, die über fundierte Kenntnisse der Tools eines bestimmten Anbieters verfügen? Das Anbieter-Know-how bleibt wertvoll, insbesondere für die Service-Ebene, auf der anbieterspezifische Funktionen angesiedelt sind. Was sich ändert, ist die darüber liegende Bereitstellungsschicht. Teams, die sich mit AWS bestens auskennen, nutzen weiterhin AWS; sie führen die Bereitstellung lediglich über eine gemeinsame Pipeline statt über eine anbieterspezifische durch. In der Praxis stellen die meisten Teams fest, dass dies die kognitive Belastung durch die Verwaltung anbieterspezifischer Bereitstellungstools verringert, anstatt sie zu erhöhen.

Wie wirkt sich ein gemeinsames Bereitstellungsmodell auf unsere Compliance-Situation in den verschiedenen Regionen aus? In den meisten Fällen positiv. Wenn Compliance-Kontrollen auf der Bereitstellungsebene durchgesetzt werden, anstatt pro Anbieter konfiguriert zu werden, gelten sie einheitlich in jeder Umgebung bei jedem Anbieter in jeder Region. Die Prüfungsnachweise sind vereinheitlicht, anstatt dass eine manuelle Abstimmung über drei Konsolenprotokolle hinweg erforderlich ist. Für Unternehmen, die in mehreren Rechtsräumen Datenhoheitsanforderungen unterliegen, ermöglicht die gemeinsame Bereitstellungsebene die einheitliche Durchsetzung von Residenzrichtlinien, anstatt Ausnahmen pro Anbieter zuzulassen.