---
title: "Cloud-Strategie: Deployment- und Service-Modelle"
description: "Welche Cloud-Betriebsmodelle und Service-Ebenen für Ihre Organisation tragfähig sind — ein methodischer Entscheidungsrahmen für IT-Architektur, CIO und Geschäftsleitung."
sidebar:
order: 9
label: "Cloud-Strategie"
source_url: "https://framework.stackit.cloud/de/advisory/cloud-vision-and-strategy/cloud-strategy/"
source_file: "docs/de/advisory/cloud-vision-and-strategy/cloud-strategy.mdx"
---
## Strategischer Rahmen: Warum Modellentscheidungen frühzeitig getroffen werden müssen
Bevor eine Organisation bestimmte Cloud-Services auswählt, müssen zwei grundlegende Entscheidungen getroffen werden: Welches Deployment-Modell erfüllt die Anforderungen an Souveränität, Compliance und Betrieb? Und auf welcher Service-Ebene sollen primär Cloud-Kapazitäten konsumiert werden? Diese Entscheidungen sind keine technischen Details, sondern definieren den strukturellen Rahmen für alle nachgelagerten Architektur-, Governance- und Beschaffungsentscheidungen.
Überlässt man diese Entscheidungen dem operativen Team, riskiert man eine zersplitterte IT-Landschaft mit inkonsistenten Sicherheitsniveaus, inkompatiblen Plattformen und schwer zu kontrollierenden Kosten. Die Entscheidung über Deployment- und Service-Modelle liegt daher in der Führungsverantwortung.
## Cloud-Deployment-Modelle
Die Organisation nutzt differenzierte Deployment-Modelle, um den Anforderungen an Sicherheit, Compliance und Flexibilität gleichermaßen gerecht zu werden. Jedes Modell hat ein klares Anwendungsprofil.
Public Cloud ist das primäre Deployment-Modell für Applikationen ohne erhöhten Souveränitätsanspruch. STACKIT als europäischer Provider bietet skalierbare, kosteneffiziente Infrastruktur mit umfangreichen Managed Services. Public Cloud ermöglicht maximale Agilität mit standardisierten Sicherheitskontrollen.
Geeignet für: Entwicklungs- und Testumgebungen, SaaS-Workloads, neue digitale Produkte, Anwendungen mit dynamischen Lastprofilen.
Das Hybrid-Cloud-Modell kombiniert Cloud-Infrastruktur mit vorhandenen On-Premises-Ressourcen. Dies ist der richtige Ansatz für Organisationen, die behördliche Anforderungen, bestehende Investitionen oder Aufbewahrungspflichten von Daten berücksichtigen und gleichzeitig cloud-native Funktionen aufbauen müssen.
Geeignet für: regulierte Workloads mit spezifischen Anforderungen an die Datenresidenz, Legacy-Systeme in Migrationsphasen, kritische Geschäftsprozesse mit On-Premises-Abhängigkeiten.
Die strategische Regel lautet: Public Cloud ist der Standard. Hybrid wird gezielt dort eingesetzt, wo nachweisbare Anforderungen eine Abweichung erzwingen — nicht als Standardausweg für Bedenken, die durch gute Governance gelöst werden können.
## Warum Deployment-Modell-Entscheidungen Governance-Entscheidungen sind
Deployment-Modelle definieren nicht nur, wo sich Daten befinden — sie legen auch fest, wer die Verantwortung trägt. In einem Public-Cloud-Modell übernimmt der Anbieter die physische Infrastruktur, während die Organisation für Konfiguration, Datenschutz und Anwendungssicherheit verantwortlich bleibt. Im hybriden Modell erweitert sich der Verantwortungsbereich: Die Organisation betreibt Teile der Infrastruktur selbst und muss entsprechende Kapazitäten und Prozesse vorhalten.
Diese Differenzierung hat direkte Auswirkungen auf Personaleinsatzplanung, Sicherheitsarchitektur und Compliance-Nachweise. Eine Organisation, die ein hybrides Modell wählt, ohne die betrieblichen Konsequenzen zu verstehen, schafft keine Sicherheit — sie schafft Komplexität ohne Abdeckung.
## Cloud-Service-Modelle
Cloud Services werden auf unterschiedlichen Abstraktionsebenen konsumiert. Jede Ebene definiert, wo die Verantwortungsgrenze zwischen Anbieter und Organisation liegt — und daher, welche Fähigkeiten und Governance-Kontrollen intern erforderlich sind.
IaaS bietet grundlegende Rechenkapazität, Speicher und Netzwerk. Die Organisation stellt virtuelle Maschinen, Netzwerkkomponenten und Speicherressourcen selbst bereit und betreibt diese. Maximaler Gestaltungsspielraum geht mit maximaler operativer Verantwortung einher: OS-Patching, Härtung, Verfügbarkeit und Monitoring liegen vollständig in der Verantwortung der Organisation.
Einsatz: Infrastruktur-Workloads mit spezifischen Konfigurationsanforderungen, Lift-and-Shift-Migrationen, Workloads ohne geeignete Managed-Service-Äquivalente.
PaaS abstrahiert die Infrastrukturschicht. Als Managed Platforms werden Datenbanken, Containerplattformen, Message Queues und ähnliche Dienste bereitgestellt. Die Organisation fokussiert sich auf die Anwendungslogik; Betriebssysteme, Patching und Verfügbarkeit der Plattform übernimmt der Provider. PaaS reduziert den operativen Aufwand deutlich und ist das bevorzugte Modell für die Entwicklung neuer Anwendungen.
Einsatz: neue Applikationen, Microservice-Architekturen, Datenbankbetrieb, Applikationsplattformen.
SaaS liefert komplette Applikationen als Service. Die Organisation konfiguriert und nutzt die Anwendung — betreibt jedoch keine Infrastruktur oder Plattform. SaaS-Governance erfordert spezifische Maßnahmen in Bezug auf die Datenresidenz, die Integrationssicherheit und die Anbieterabhängigkeit.
Einsatz: Bürosoftware, CRM-/ERP-Systeme, Kollaborationsplattformen, spezialisierte Unternehmenssoftware.
## Das Prinzip der höheren Abstraktion
Die strategische Leitlinie lautet: Höhere Abstraktionsebenen werden bevorzugt, wenn sie den fachlichen und technischen Anforderungen entsprechen. Das bedeutet: SaaS vor PaaS vor IaaS — nicht aus Bequemlichkeit, sondern weil eine höhere Abstraktion den operativen Aufwand reduziert, die Standardisierung fördert und die Organisation von der Wartung der Infrastruktur zur Wertschöpfung führt.
Abweichungen von dieser Richtlinie sind zu begründen: Welche Anforderung erzwingt eine niedrigere Abstraktionsebene? Diese Rechtfertigungspflicht ist keine bürokratische Behinderung, sondern der Mechanismus, der verhindert, dass Gewohnheit oder Unkenntnis über verfügbare Managed Services die Cloud-Strategie untergraben.
## Entscheidungsverantwortung
Die Definition der Deployment- und Service-Modelle liegt beim Cloud Center of Excellence (CCoE) in enger Abstimmung mit IT-Architektur und Geschäftsleitung. Abweichungen von den strategisch definierten Modellen erfordern eine Ausnahmeentscheidung mit dokumentierter Begründung.
Diese Entscheidungsstruktur sichert die Stimmigkeit der IT-Landschaft und verhindert das unkontrollierte Entstehen von Schatten-IT oder inkompatibler Cloud-Infrastruktur in einzelnen Sparten.