Cloud oder On-Prem? Entscheidungsleitfaden mit Betriebskosten, Compliance und Skill-Lage

Leserfrage: „Wir sollen im Lenkungskreis festlegen: Cloud oder On-Prem – was ist für unsere Business-Software, Datenbanken und Schnittstellenlandschaft sinnvoll, wenn wir Betriebskosten, Compliance und die aktuelle Skill-Lage ehrlich betrachten?“

Vorläufige Antwort: In vielen Unternehmen ist weder „alles Cloud“ noch „alles On-Prem“ die beste erste Entscheidung. Tragfähig wird es, wenn Sie pro Workload (klar abgegrenzter Systemteil mit eigenem Daten- und Risikoprofil) ein belastbares Betriebsversprechen definieren: Zuständigkeiten, Nachweise, Kostenmechanik und Exit – und erst dann die Plattform wählen.

Wer zu früh über „die Cloud“ spricht, übersieht die Fragen, die später wirklich zählen: Wer wird nachts alarmiert? Wer kann im Audit erklären, wo Daten liegen und wer Zugriff hat? Wer verhindert, dass Testumgebungen monatelang weiterlaufen? An diesen Punkten trennt sich „Entscheidung getroffen“ von „Entscheidung betrieben“.

Warum „Cloud oder On-Prem?“ selten eine reine Infrastrukturfrage ist

„Wo läuft das System?“ ist eine zu kleine Frage. In der Praxis entscheiden drei Dinge über Stabilität und Planungssicherheit: Betrieb (Monitoring, Backup/Restore, Runbooks), Governance (Verträge, Prüf-/Zugriffsrechte, Rollen) und Skills (wer erledigt welche Aufgaben im Tagesgeschäft). Diese Lücken werden nicht im Kickoff sichtbar, sondern beim ersten größeren Incident, im Audit oder beim ersten Release unter Zeitdruck.

Ein hilfreicher Perspektivwechsel: Entscheiden Sie nicht „Cloud vs. Rechenzentrum“, sondern „welches Betriebsversprechen geben wir den Fachbereichen“. Das umfasst Verfügbarkeit, Wiederanlauf (RTO/RPO: maximale Ausfallzeit und maximaler Datenverlust), Change-Geschwindigkeit, Nachvollziehbarkeit von Zugriffen und eine klare Antwort auf die Frage: Wer trägt welche Verantwortung?

Shared Responsibility: Cloud heißt nicht „aus der Verantwortung“

Der verbreitetste Irrtum lautet: „Beim Cloud-Anbieter ist Sicherheit und Betrieb erledigt.“ In Wirklichkeit gilt ein geteiltes Verantwortungsmodell: Provider und Kunde teilen sich Sicherheits- und Betriebsaufgaben, abhängig vom Service-Modell (SaaS, PaaS, IaaS). NIST beschreibt diese Aufteilung ausdrücklich und macht klar, dass die Verantwortungsgrenzen je Modell unterschiedlich ausfallen.^[Quelle]

Für die Praxis heißt das:

• SaaS: Der Anbieter betreibt die Anwendung. Ihr Anteil liegt stark bei Identitäten, Berechtigungen, Daten, Prozessregeln, Export/Löschung und der Frage, wie Sie Nachweise erhalten.
• PaaS: Der Anbieter betreibt Plattformkomponenten (z. B. Datenbankdienst). Sie bleiben verantwortlich für Konfiguration, Zugriff, Datenflüsse, Schlüssel/Secrets sowie die Betriebsintegration (Monitoring, Alarmierung, Incident-Prozess).
• IaaS: Sie erhalten virtuelle Infrastruktur. Damit kommen klassische Pflichten zurück: Netzwerkregeln, Systemhärtung (Hardening), Patch-Entscheidungen, Logging, Backup-Design – nur in der Cloud-Konsole statt im eigenen Virtualisierungstool.

Praktische Folgerung: Wenn Sie Cloud wählen, müssen Sie den „Kundenanteil“ als Rollen, Rechtekonzept, Runbooks und Bereitschaft abbilden. Sonst entsteht eine Zuständigkeitslücke: Aufgaben existieren, aber niemand besitzt sie.

Betriebskosten realistisch vergleichen: TCO reicht nicht, Sie brauchen die Kostenmechanik

Viele Diskussionen starten bei CAPEX vs. OPEX (Investitionen vs. laufende Kosten). Das ordnet Budgets, ersetzt aber nicht die Alltagsrechnung. Für digitale Unternehmenslösungen zählt die Kostenmechanik: Was kostet Wachstum? Was kostet „mehr Nachweis“? Was kostet „24/7 statt Bürozeiten“?

Cloud: Kostentreiber, die frühe Kalkulationen oft übersehen

• Dauerläufer und vergessene Umgebungen: Test, Staging, Schulung, temporäre Projekte. In der Cloud kostet jedes „läuft halt weiter“ – und zwar jeden Tag.
• Datenbewegung und Integrationsverkehr: Datenpfade sind nicht nur technisch, sondern können laufende Gebühren auslösen (z. B. beim Herausführen großer Datenmengen oder beim dauerhaften Cross-Region-Verkehr).
• Logging, Security-Telemetrie und Aufbewahrung: Incident-Aufklärung und Auditfähigkeit bedeuten oft: mehr Logs, längere Aufbewahrung, mehr Auswertung.
• Metrikmodelle und Lizenzen: Manche Kosten skalieren pro Nutzer, manche pro Request/CPU/Throughput. Das kann Planbarkeit verbessern oder verschlechtern.
• Organisationsaufwand: Provider-Management, Nachweise, Kostensteuerung (FinOps) sind wiederkehrend und brauchen feste Owner.

On-Prem: Kostentreiber, die im Alltag gern unterschätzt werden

• Lifecycle/Erneuerung: Hardware, Storage, Virtualisierung, Betriebssysteme, Datenbanken: alles hat Upgrade-Zyklen, Wartungsfenster und Risiken.
• Resilienz kostet doppelt: Hochverfügbarkeit, zweiter Standort, Backup/Restore-Tests, Notfallübungen – technisch und personell.
• Schlüsselpersonenrisiko: Wenn Betrieb an wenigen Admins hängt, werden Ausfall oder Fluktuation zu einem echten Kosten- und Verfügbarkeitsrisiko.
• Langsame Änderungen werden teuer: Viele manuelle Schritte, fehlende Standardisierung, lange Freigaben erzeugen Daueraufwand und erhöhen das Betriebsrisiko bei Releases.

Wichtig: Es gibt keine belastbare Allgemeinformel „Cloud ist immer günstiger“. Der saubere Weg ist: Sie definieren pro Workload das Betriebsziel (inkl. Nachweise) und rechnen dann die Mechanik über 3–5 Jahre gegen – inklusive Personalzeit, nicht nur Infrastruktur.

Vergleichstabelle: Cloud, On-Prem und Hybrid im Betriebsalltag

Compliance: Cloud-Outsourcing ist Governance, nicht nur DSGVO

Compliance wird in Projekten gern auf „personenbezogene Daten“ reduziert. In der Praxis ist Cloud aber häufig eine Outsourcing- und Governance-Frage: Welche Kontrollrechte haben Sie? Welche Subdienstleister sind beteiligt? Was passiert bei Störungen oder Providerwechsel? Können Sie Prüfungen ermöglichen, ohne im Betrieb zu improvisieren?

Die EBA-Leitlinien zu Auslagerungen betonen risikobasiertes Vorgehen, vertragliche Regelungen, Auditierbarkeit/Prüfrechte und Exit-Planung.^[Quelle] Auch wenn Ihr Unternehmen nicht der Bankenaufsicht unterliegt: Als Messlatte hilft diese Logik, weil sie typische Schwachstellen sichtbar macht. Der Nachteil ist ebenso klar: Governance erzeugt Aufwand, und zwar früh im Projekt.

DSGVO-Rollenklärung: Verantwortlicher und Auftragsverarbeiter praktisch übersetzen

Für Cloud-Setups ist die Rollenklärung nach DSGVO zentral: Wer ist Verantwortlicher (Controller), wer Auftragsverarbeiter (Processor), wer bestimmt Zweck und Mittel der Verarbeitung, und wer darf Subprozessoren einsetzen? Die EDPB-Leitlinien machen deutlich, dass diese Rollen reale Pflichten und Grenzen definieren – und damit direkt auf AV-Vertrag (Auftragsverarbeitung), Kontrollrechte und technische/organisatorische Maßnahmen wirken.^[Quelle]

Konsequenz für Projekte: „AVV unterschrieben“ ist kein Abschluss. Sie brauchen eine technische Landkarte der Datenflüsse (welche Daten, wohin, mit welchem Zweck) plus eine Betriebsdefinition (wer sieht Logs, wie wird gelöscht, wie wird exportiert, wer bestätigt). Erst dann ist die Rollenklärung belastbar.

BSI C5 als Anforderungskatalog: hilfreich, aber Scope und Version festnageln

In Deutschland dient BSI C5 (Cloud Computing Compliance Controls Catalogue) häufig als Kriterienkatalog, um Sicherheits- und Compliance-Anforderungen an Cloud-Anbieter strukturiert abzufragen und Nachweise vergleichbar zu machen.^[Quelle] Der Nutzen im Entscheidungsprozess: Aus „wir brauchen Sicherheit“ werden konkret prüfbare Kontrollbereiche, etwa Identitäten, Kryptografie, Betrieb, Incident-Prozesse und Lieferkette.

Die Grenze bleibt: C5 ersetzt weder Ihr Risikomodell noch Ihre Architekturentscheidungen. Und Kataloge entwickeln sich weiter. Für Ihren Prozess heißt das pragmatisch: Dokumentieren Sie, welche C5-Version und welcher Nachweisumfang für Ihre Auswahl gilt. Sonst vergleichen Sie Anbieter nach unterschiedlichen Maßstäben.

Skill-Lage: Was sich durch Cloud wirklich verschiebt

Cloud reduziert typischerweise den Aufwand für physische Infrastruktur. Gleichzeitig entstehen Anforderungen, die in klassischen Betriebsmodellen leicht unterbesetzt sind. Das ist keine Wertung, sondern eine Verschiebung: weniger Hardwarebetrieb, mehr Steuerung, Automatisierung und Nachweisführung.

• Identity & Access Management (IAM): Rollen, Gruppen, Föderation (z. B. SAML/OIDC: Standards zur Anbindung an ein zentrales Login) und saubere Prozesse für Ein-/Austritte.
• Netz- und Zugriffsdesign: Segmentierung, Übergänge zu On-Prem, Admin-Zugänge, private Endpunkte.
• Automatisierung: Infrastructure as Code (IaC: deklarative Bereitstellung von Ressourcen), um Wildwuchs zu verhindern und Umgebungen reproduzierbar zu halten.
• Security-Konfiguration: Schlüssel, Secrets, Baselines, kontinuierliche Prüfung auf Fehlkonfigurationen.
• Provider-Management: SLA-/Supportwege, Subdienstleister, Change-Kommunikation, Incident-Handling.
• Kostensteuerung: Regeltermine, Verantwortliche, Budgets und klare Regeln für „wer darf was starten“.

On-Prem wirkt vielen Teams vertrauter, ist aber nicht automatisch leichter: Patch-Routinen, Backup/Restore-Drills, Kapazitätsplanung, Monitoring, Dokumentation und Rufbereitschaft sind auch dort Pflicht. Der Unterschied ist oft die Sichtbarkeit: On-Prem-Schulden bleiben länger „unsichtbar“, Cloud-Schulden werden schneller teuer oder auditrelevant.

Cloud oder On-Prem entlang von Workloads entscheiden: ein Leitfaden, der im Betrieb standhält

Statt „Cloud oder On-Prem“ pauschal zu entscheiden, schneiden Sie die Landschaft in Workloads. Ein Workload ist hier ein abgegrenzter Teil Ihrer Systemlandschaft mit eigener Datenhoheit, eigenem Lastprofil und eigenem Risikobild (z. B. Kundenportal, Integrationsschicht/API, Reporting/Batch, Dokumentenerzeugung, Kern-DB).

Die Schrittfolge ist bewusst so formuliert, dass IT-Leitung, Administration, Datenschutz/Compliance und Projektleitung gemeinsam daran arbeiten können, ohne in Framework-Diskussionen abzurutschen:

1. Workloads schneiden und benennen: 6–12 Workloads reichen. Pro Workload: Nutzergruppen, Kernprozesse, Datenquellen, Schnittstellen.
2. Schutzbedarf und Betriebsziele festlegen: Verfügbarkeit, RTO/RPO, Audit-Anforderungen, Peak-Last, Latenzempfindlichkeit, Wartungsfenster.
3. Operating Model definieren: Owner, Betrieb/On-Call, Change-Freigaben, Incident-Prozess, Zuständigkeit für Nachweise.
4. Abhängigkeiten sichtbar machen: Datenflüsse, Authentifizierung, Netzwerkwege, Batch-Ketten, Partneranbindungen.
5. Zielplattform bewerten: Cloud, On-Prem oder Hybrid – begründet anhand Ihrer Kriterien (nicht anhand von Gewohnheit).
6. Exit und Migration mitdenken: Datenportabilität, Vertragslaufzeiten, Rückfalloptionen, Parallelbetrieb, Test- und Rollback-Plan.
7. Pilot als „Proof of Operability“: Nachweis von Monitoring, Restore-Test, Kostenkontrolle, Berechtigungsmodell und Betriebsübergabe.

Hybrid ist keine Ausrede: Ohne saubere Grenzen wird es im Betrieb unklar

Viele Unternehmen landen pragmatisch bei Hybrid Cloud: stabile Kernsysteme On-Prem, Portale/APIs/Analyse in der Cloud. Das kann sehr vernünftig sein. Hybrid kippt aber, wenn Grenzen nicht sauber gezogen werden. Dann haben Sie zwei Betriebswelten, aber keinen durchgängigen Blick auf Prozesse.

Typische Hybrid-Fallstricke, die später Zeit fressen

• Identity-Spaghetti: mehrere Benutzerverzeichnisse, uneinheitliche MFA-Regeln, doppelte Rollenmodelle.
• Unklare Datenkonsistenz: Fachbereiche erwarten „Echtzeit“, die Architektur liefert Batch – das wird zum Supportthema statt zur bewussten Designentscheidung.
• Monitoring ohne Ende-zu-Ende-Sicht: Einzeltools zeigen Teilaspekte, niemand sieht den Gesamtpfad eines Vorgangs.
• Unkoordinierte Changes: Cloud-Komponenten ändern sich schneller; On-Prem-Freigaben dauern länger. Ohne Release-Regeln entstehen Reibungen.

Praktische Folgerung: Wenn Hybrid gesetzt ist, investieren Sie früh in eine Integrationslandkarte (Service-zu-Service, Identitäten, Protokolle, Datenrichtung) und in Betriebs-Schnittstellen: Alarmierung, Eskalation, Ownership, Wartungsfenster und Abnahmekriterien. Das ist weniger „Dokumentation“, mehr Betriebssicherheit.

Security und Auditierbarkeit: drei Fragen, die in beiden Welten schützen

„Cloud ist sicher“ oder „On-Prem ist sicherer“ sind bequeme Sätze, aber im Betrieb wertlos. Sicherheit ist das Ergebnis von Kontrollen, Zuständigkeiten und Wiederholbarkeit. Drei Fragen helfen, unabhängig von der Plattform:

• Wie werden Identitäten verwaltet? SSO, MFA, Rollen, Rezertifizierung (regelmäßige Berechtigungsprüfung) und ein sauberer Joiner/Mover/Leaver-Prozess.
• Wie werden Änderungen gemacht? Change-Prozess, Freigaben, Rollback-Plan, getrennte Umgebungen, nachvollziehbare Deployments.
• Wie wird nachgewiesen? Logs, Konfigurationshistorie, Admin-Aktionen, Datenzugriffe, Aufbewahrung und Auswertung.

Bei Cloud-Outsourcing kommt eine zusätzliche Realität dazu: Audit- und Zugriffsrechte sowie Exit-Optionen müssen nicht nur „vertraglich möglich“, sondern operativ leistbar sein. Wenn Datenexporte im Ernstfall Wochen dauern oder Nachweise nur mit Ad-hoc-Skripten entstehen, ist das kein Detail, sondern ein Plattformrisiko.

Exit-Strategie: Der schnellste Realitätstest für Cloud-Entscheidungen

Exit klingt nach „später“. In der Entscheidungsvorbereitung ist Exit ein nützlicher Zwang zur Klarheit: Wo liegen Daten, in welchem Format, mit welchen Schlüsseln? Wie schnell bekommen Sie einen vollständigen Export? Was passiert mit Logs, Backups und Löschbestätigungen? Welche Teile sind an proprietäre Dienste gebunden?

Eine Exit-Strategie ist kein Misstrauensvotum, sondern Risikomanagement. Prozessnahe Softwarelösungen laufen lange. Wenn Exit nicht mitgedacht wird, tauschen Sie technische Freiheit gegen Vertrags- und Plattformabhängigkeit, ohne es sauber zu bilanzieren.

Wann Cloud die richtige erste Wahl ist

Cloud ist besonders plausibel, wenn mehrere der folgenden Bedingungen zutreffen:

• Variable Last ist real (z. B. saisonale Peaks, viele externe Nutzer, Lastspitzen bei Imports/Exports).
• Umgebungen sind ein Engpass (Test/Staging/Schulung, temporäre Projekte) und sollen reproduzierbar bereitstehen.
• Standard-Services decken einen großen Teil ab (z. B. Managed Database, Identity, Monitoring), ohne überall Sonderwege zu erzwingen.
• IAM, Automatisierung und Governance sind organisatorisch abbildbar oder werden gezielt aufgebaut.
• Compliance ist konkret geklärt: Nachweise, Datenstandorte, Audit- und Exit-Regeln sind vertraglich und technisch umsetzbar.

Die Kehrseite bleibt: Cloud ohne Disziplin (Kosten, Konfiguration, Berechtigungen) wird schnell teurer und unübersichtlicher als geplant. Das ist fast immer ein Operating-Model-Thema.

Wann On-Prem (vorerst) die bessere Wahl ist

On-Prem ist oft die bessere erste Wahl, wenn diese Punkte dominieren:

• Sehr stabile Auslastung und vorhandene Infrastruktur, die gut genutzt und konsequent gepflegt wird.
• Strenge Standort- oder Latenzanforderungen, die sich nicht sinnvoll in Cloud-Regionen abbilden lassen.
• Hohe Integrationsdichte mit lokalen Systemen, bei denen zusätzliche Netz- und Datenpfade unnötig komplex würden.
• Teamstärke im klassischen Betrieb ist vorhanden (Patch-/Backup-Routinen, Monitoring, Notfallübungen).
• Compliance-Organisation ist auf internen Betrieb ausgelegt und Cloud-Outsourcing würde kurzfristig unverhältnismäßig viel Governance- und Vertragsarbeit erzeugen.

Der entscheidende Nachteil: On-Prem wird riskant, wenn Lifecycle dauerhaft vertagt wird. Dann wächst technische Schuld im Betrieb: Updates werden vermieden, Abhängigkeiten veralten, Änderungen werden gefährlich und teuer. On-Prem funktioniert nur mit aktivem Plattformmanagement.

Die umsetzbare Priorität: Was Sie in den nächsten 30 Tagen festzurren sollten

Wenn Sie aus „Cloud oder On-Prem?“ eine belastbare Entscheidung machen wollen, starten Sie nicht mit dem Providervergleich. Starten Sie mit einem kleinen, harten Paket, das Betrieb, Compliance und Skills sichtbar macht:

1. Workload-Liste (max. 12) erstellen: pro Workload Datenarten, Schnittstellen, Nutzergruppen, Betriebsziele.
2. Für die Top-3 kritischen Workloads ein Betriebs-Minimum definieren: Ownership, Support/On-Call, Logging/Audit, Backup/Restore-Test, Change-/Release-Regeln.
3. Compliance als Nachweis- und Vertragsanforderung prüfen: Auditrecht, Exit, Subdienstleister, Datenstandorte, DSGVO-Rollen und Weisungskette.
4. Proof of Operability pilotieren: ein kleiner Pilot, der Kosten, Monitoring, Restore und Zuständigkeiten nachweisbar macht.

Diese vier Punkte liefern keine Hochglanzstrategie, aber eine Entscheidung, die im Betrieb hält: Was ist kurzfristig betreibbar, wo fehlt Skill-Aufbau, und welche Workloads sollten bewusst (noch) nicht in die Cloud.

Für dieses Thema sind auch Cloud Vs On-Prem und Betriebskosten Tco wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.