Entscheidungshilfe: Inhouse, Cloud oder Hybrid — Kriterien für sichere Anwendungslandschaften

Viele IT-Entscheidungen laufen letztlich auf eine einfache Frage hinaus: betreiben wir Anwendungen weiterhin Inhouse, wechseln wir in die Public Cloud, oder wählen wir eine Hybrid-Architektur? Die Entscheidung sollte nicht aus Bauchgefühl getroffen werden. In diesem Beitrag skizziere ich eine praxiserprobte Entscheidungslogik mit klaren Kriterien für Sicherheit, Compliance, Betrieb und Kosten — kurz: Inhouse, Cloud oder Hybrid als strukturierter Entscheidungsprozess für IT‑Leitung, Compliance‑Verantwortliche und Betriebsverantwortliche.

Warum die Wahl heute strategisch ist

Die Betriebsform beeinflusst nicht nur Infrastrukturkosten, sondern auch Verantwortlichkeiten, Audit‑Evidence, Recovery‑Szenarien, Schnittstellenmanagement und langfristige Exit‑Kosten. Public Cloud heißt nicht automatisch weniger Arbeit: Es verlagert operationalen Aufwand und Risiko in andere Verantwortungsbereiche (Shared Responsibility; das ist das gemeinsame Sicherheitsmodell, bei dem Cloud‑Provider und Kunde jeweils Teile der Sicherheits‑ und Compliance‑Aufgaben tragen). Inhouse bedeutet volle Kontrolle, aber auch volle Haftung für Hard‑ und Software, Patching, physische Sicherheit sowie Disaster Recovery.

Grundlage: Ziele, Restriktionen und Risikotoleranz klar definieren

Bevor technische Kriterien herangezogen werden, definieren Sie drei Dinge verbindlich:

• Businessziele: Welche SLAs benötigt die Anwendung? Welche Geschäftsprozesse hängen direkt davon ab?
• Regulatorische Restriktionen: Gibt es Datenlokalitätspflichten, Branchenstandards (z. B. BaFin, HIPAA-Äquivalente) oder spezielle Audit‑Anforderungen?
• Risikotoleranz: Wie hoch ist die akzeptable Ausfallwahrscheinlichkeit, das potenzielle Reputationsrisiko und die maximale Downtime?

Diese drei Leitplanken steuern Gewichtung von Sicherheit, Kosten und Agilität in der finalen Entscheidung.

Entscheidungsrahmen: Die 10 entscheidenden Kriterien

Praktische Entscheidungen entstehen aus gewichteten Kriterien. Die folgenden zehn Punkte sind in Projekten wiederholt als Trennschärfe erwiesen:

1. Datensouveränität & Compliance: Gesetzliche Vorgaben zu Datenhaltung oder Branchenstandards. Wenn strikte lokale Speicherung, Audit‑Logs oder Prüfnachweise erforderlich sind, verschiebt das die Waage Richtung Inhouse oder Private Cloud.
2. Sicherheitskontrollen & Härtung: Können Sie die erforderlichen Kontrollen (Netzwerksegmentierung, HSM, Key‑Management, dedizierte IDS/IPS) in der Cloud mit der nötigen Garantie betreiben, oder ist Inhouse die sicherere Wahl?
3. Verfügbarkeit & Latenz: Anwendungen mit harten Latenzgrenzen oder deterministic I/O (z. B. Fertigungssteuerung) profitieren oft von naher, lokaler Infrastruktur.
4. Betriebsreife der Organisation: Verfügt Ihr Team über Cloud‑Betriebsprozesse (Cost Monitoring, IaC, Security Automation)? Wenn nicht, steigt das Risiko der Cloud‑Nutzung.
5. Kostenstruktur und TCO: CapEx vs. OpEx, Laufzeitbindung, variable Last, langfristige Skalierung und Exit‑Kosten (Datenexport, Bandbreitenkosten).
6. Integrationsbedarf: Enge Kopplung zu internen Systemen, low‑level Integrationen oder Legacy‑Schnittstellen können Hybrid‑ oder Inhouse‑Betrieb begünstigen.
7. Backup, Restore & Disaster Recovery: Prüfen Sie Wiederanlaufzeiten (RTO) und Wiederherstellungspunkte (RPO) unter realistischen Lastszenarien. Cloud bietet Managed-DR, aber Exit/Restore kann komplex sein.
8. Vendor‑Lock‑in & Exit‑Strategie: Wie einfach lassen sich Daten und Workloads zurückholen? Nutzt die Lösung proprietäre Managed‑Services, die den Exit verkomplizieren?
9. Auditierbarkeit und Evidence: Können Sie notwendige Nachweise (Logs, Konfigurationsstände, Änderungsnachweise) dauerhaft und audittauglich bereitstellen?
10. Organisatorische Geschwindigkeit: Bedarf an schneller Skalierung, Time‑to‑Market und Entwicklungszyklus. Public Cloud kann hier klare Vorteile bringen.

Gewichtung und Scorecard

Jedes Kriterium sollte für die jeweilige Anwendung mit Punkten gewichtet werden (z. B. 1–5). Die Summe ergibt eine Entscheidungsrichtung: klar inhouse, klar Cloud oder hybrid als Kompromiss. Die Scorecard ist zugleich Governance‑Artefakt für Audits.

Security und Compliance detailliert betrachten

Security ist kein Einzelkriterium; es spiegelt sich in Architektur, Betrieb und Prozessen wider. Wichtige Aspekte:

• Identity & Access Management (IAM): Zentralisierte Rollen, Least Privilege, MFA, und automatisierte Provisionierung/Deprovisionierung sind Pflicht. In Cloud‑Umgebungen nutzt man IAM‑Features des Providers, muss aber deren Audit‑Trails und Rollenmodell verstehen.
• Key Management und Verschlüsselung: Private Keys idealerweise in Hardware Security Modules (HSM). Cloud‑Provider bieten managed HSM/Key Vaults, die Compliance‑Anforderungen erleichtern. Prüfen Sie KMS‑Key‑Ownership und Rotation.
• Netzwerksegmentierung und Zero Trust: Microsegmentation, interne Firewalls und klare Egress‑Kontrollen. Hybrid‑Szenarien erfordern sichere Transit‑Verbindungen (VPN, Direct Connect) und klar definierte Trust‑Grenzen.
• Logging, Monitoring und SIEM: Zentralisiertes Log‑Management mit Nachweisdauer passend zu regulatorischen Vorgaben. SIEM kann On‑Premise oder in der Cloud betreiben werden, wichtig ist Integritätsnachweis der Logs.

Audit‑Evidence: Was Prüfer sehen wollen

Audits verlangen nachvollziehbare Evidence wie:

• Konfigurationssnapshots (Infrastructure as Code) mit Hash und Versionierung;
• Access‑Logs mit Zeitsynchronisation und Prüfsummen;
• Patch‑und Change‑Records mit Verantwortlichkeit;
• Backup‑Testprotokolle und Restore‑Reports;
• Key‑Rotation‑Logs und KMS‑Policy‑Dokumente.

Notieren Sie in Ihrer Entscheidungsdokumentation, wie und wo diese Artefakte erzeugt und langfristig aufbewahrt werden.

Operative Folgen: Betrieb, Skills und Liefermodelle

Die Wahl hat direkte Konsequenzen für den Betrieb:

• Inhouse: Höherer Aufwand für Hardware‑Lifecycle, Patchmanagement, physische Sicherheit, aber maximale Kontrolle.
• Public Cloud: Tieferer Hardwareaufwand, aber höhere Anforderungen an Cloud‑Betriebsprozesse, Kostenüberwachung und IAM‑Disziplin.
• Hybrid: Kombination aus beidem; erfordert robuste Netzwerkarchitektur, Daten‑Sync‑Strategien und klare Verantwortungsgrenzen.

Skillset und Organisationsstruktur

Prüfen Sie, ob Ihre Teams Erfahrung mit Cloud‑Kostenoptimierung, IaC (Infrastructure as Code), CI/CD, Observability und Cloud‑Sicherheitsmodellen haben. Fehlt Know‑how, planen Sie Trainings, Managed‑Services oder dedizierte Cloud‑Ops‑Rollen ein.

Kalkulation: TCO, Kostenmodelle und versteckte Kosten

Kalkulationstipps:

• Berechnen Sie total cost of ownership über 3–5 Jahre inklusive Personalkosten für Betrieb, Monitoring, Compliance‑Aufwand und Ausfallkosten.
• Achten Sie auf variable Cloud‑Kosten: Datentransfer (egress), Snapshot‑Speicher, IOPS‑Tarife, Management‑Addons.
• Berücksichtigen Sie Exit‑Kosten: Datenexport, Neuinstallation in Zielumgebung, Testaufwand und eventuell Lizenzkosten.

Praktisches Beispiel: Bandbreiten‑ und Egress‑Kosten

Eine stark datentransferintensive Integration zwischen On‑Premise‑Systemen und Public Cloud kann monatliche Egress‑Kosten verursachen, die das Cloud‑Modell unwirtschaftlich machen. Modellieren Sie Lastprofile und simulieren Sie Kosten mit realen Nutzungsdaten.

Integrations- und Migrationsaspekte

Bei bestehender Legacy‑Anwendungslandschaft sind Faktoren wichtig:

• Datenkonsistenz: Migrationsstrategien über Replikation, Hybridsynchronisation oder temporäre Gateways.
• Schnittstellen: APIs sollten stabil, versioniert und dokumentiert sein. Proprietäre Schnittstellen erschweren Cloud‑Move.
• Testbarkeit: Infrastruktur für automatisierte Tests und Staging‑Umgebungen planen — in Cloud meist leichter skalierbar.

Beispiel‑Snippet: Basiseintrag für eine Migrations-Policy (Vorlage)

# migration_policy.yaml
migration_policy:
  scope: "Anwendung X"
  owner: "IT-Betrieb / Applikationsverantwortlicher"
  phases:
    - assessment
    - pilot
    - staged-migration
    - cutover
    - validation
  success_criteria:
    rto: 60 # Minuten
    rpo: 15 # Minuten
    data_consistency: true
    perf_thresholds:
      p95_response_ms: 500
  rollback_plan: true
  audit_evidence_required:
    - iactemplate_hash
    - access_log_snapshot
    - backup_restore_report

Hybrid: Wann ist es die richtige Antwort?

Hybrid ist dann sinnvoll, wenn unterschiedliche Anwendungen widersprüchliche Anforderungen haben: Einige Module benötigen niedrige Latenz oder spezielle Hardware, andere profitieren von Cloud‑Skalierung und Managed‑Services. Hybrid sollte nicht Default sein — es erhöht Komplexität erheblich und verlangt klare Netzwerk- und Daten‑Governance.

Architekturprinzipien für Hybrid

• Klare Zonen: Trennen Sie On‑Premise, Private Cloud und Public Cloud logisch und mittels Transit‑Gateways.
• Data Gravity beachten: Daten tendieren dazu, dort zu bleiben, wo sie groß und frequent genutzt werden. Verlegen Sie Rechenprozesse dorthin, wo die Daten sind.
• Synchronisationsmuster definieren: Asynchrone Replikation, Event‑Streaming oder API‑Gateways mit Circuit‑Breaker.

Governance, Verantwortlichkeiten und Audit

Ein Governance‑Rahmen reduziert Entscheidungs‑ und Betriebsrisiken. Elemente:

• Verantwortlichkeiten (RACI) für Architektur, Betrieb, Sicherheit und Compliance.
• Change‑Management mit audittauglichen Evidence‑Artefakten.
• Regelmäßige Reviews: Kosten, Sicherheitslage, Vendor‑Performance, Exit‑Readiness.

Kurzvorlage: RACI für Cloud‑Entscheidungen

R: IT-Betrieb (Implementierung)
A: CIO/IT-Leitung (Entscheidung)
C: Compliance, Security, Fachabteilung (Beratung)
I: Geschäftsführung, Finanzen (Information)

Konkrete Checkliste vor der Entscheidung

Vor dem finalen Go/No‑Go prüfen Sie diese Punkte systematisch:

• Ist die regulatorische Lage geprüft und dokumentiert?
• Liegt eine vollständige TCO‑Berechnung mit realen Lastdaten vor?
• Sind Exit‑Szenarien inklusive Datenrückführung dokumentiert und getestet?
• Gibt es eine Klarheit über Audit‑Evidence, Retention und Owner?
• Verfügt das Team über notwendige Skills oder sind Partner/Services eingeplant?
• Existieren definierte SLAs, RTO/RPO und messbare KPIs?

Beispiel: Entscheidungs‑Matrix (vereinfachtes Modell)

Nutzen Sie eine Matrix mit den zehn Kriterien (je 1–5 Punkte) und zwei Schwellen:

• Gesamtpunktzahl > 40: klare Cloud‑Eignung
• Gesamtpunktzahl 20–40: Hybrid in Erwägung ziehen mit klarer Zone‑Definition
• Gesamtpunktzahl < 20: Inhouse bevorzugt

Die Schwellenwerte sind anpassbar; wichtig ist Transparenz und Nachvollziehbarkeit beim Audit.

Praktische Umsetzung: Pilotprojekt und Governance‑Gate

Führen Sie Migration oder Neubau über einen Pilot mit klaren Exit‑Gates durch: technische Validierung, Sicherheitsprüfung, Kosten‑Validierung, und Geschäftsabnahme. Nur wenn alle Gates grün sind, folgt erweiterte Migration.

Inhouse, Cloud oder Hybrid: Entscheidungskriterien praktisch anwenden

Das Fokus‑Keyword im Kopf zu haben hilft, die Diskussion zu fokussieren: Inhouse, Cloud oder Hybrid heißt konkret: welche Teile einer Anwendung bleiben lokal, welche gehen in Managed‑Services und welche verteilen sich zwischen Zonen? Beginnen Sie mit einem Modul‑Level‑Assessment statt gesamter Monolithen. Modularisierung macht Entscheidungen reversibel.

Module, Datenklassifizierung und minimale Zone

Führen Sie eine Klassifizierung auf Modul‑ und Datensatzebene ein:

• Schutzbedarf hoch: Bleibt on‑premise oder in einer zertifizierten Private Cloud.
• Schutzbedarf mittel: Kann in vertraglich gesicherten Cloud‑Zonen mit Verschlüsselung und kontrolliertem KMS liegen.
• Schutzbedarf niedrig: Geeignet für Public Cloud‑Services oder SaaS.

Diese Klassifikation ist handhabbar und reduziert Komplexität bei Entscheidungen.

Operational Runbooks und Playbooks

Für jede gewählte Betriebsform brauchen Sie betriebliche Anweisungen (Runbooks) und Notfall‑Playbooks. Ein Runbook beschreibt Schritt für Schritt den normalen Betrieb, ein Playbook die Reaktion auf Störungen. Beide Dokumente sind Auditelemente und sollten versioniert sein.

# Beispiel: Minimaler Backup-Verify-Check (Bash)
set -euo pipefail
BACKUP=/srv/backups/appx/latest.tar.gz
RESTORE_DIR=/tmp/restore_check
mkdir -p "$RESTORE_DIR"
tar -xzf "$BACKUP" -C "$RESTORE_DIR"
# Existenzprüfung wichtiger Dateien
if [ ! -f "$RESTORE_DIR/etc/appx/config.yaml" ]; then
  echo "Restore verification failed: config missing" >&2
  exit 2
fi
# Cleanup
rm -rf "$RESTORE_DIR"
echo "Backup verification succeeded"

Exit‑ und Recovery‑Runbook

Ein Exit‑Runbook beschreibt die Schritte, Artefakte und Verantwortlichkeiten für Datenexport, Konfigurationsbezug und Wiederaufbau in einer alternativen Umgebung. Es sollte regelmäßig geübt werden. Bestandteile:

• Exportpfade und Formate (z. B. SQL‑Dumps, object storage export);
• Konfigurations‑ und IaC‑Schnappschüsse mit Hashes;
• Test Restore‑Szenario mit definierten Erfolgskriterien;
• Verantwortlichkeiten und Zeitleisten.

Messbare KPIs und Reporting

Definieren Sie KPIs, die Governance und Betrieb objektiv messen:

• Kosten‑KPI: Cloud‑Spend pro Anwendung, Egress‑Kosten, Storage‑Growth;
• Security‑KPI: Anzahl kritischer Findings, Zeit bis Patch, MFA‑Coverage;
• Recovery‑KPI: Durchschnittliche RTO, RPO‑Erreichungsrate in Tests;
• Compliance‑KPI: Anteil audittauglicher Artefakte innerhalb definierter Fristen.

Regelmäßige Dashboards und Drilldown‑Reports sind Voraussetzung, damit Entscheider faktenbasiert steuern können.

Vertragsklauseln und rechtliche Prüfungen

Bei Cloud‑Verträgen legen Sie besonderes Gewicht auf:

• Auditrechte und Nachweiszugänge;
• Data Processing Agreements (DPA) und Sub‑Processor‑Transparenz;
• Exit‑Klauseln mit Datenexportzeiten und -formaten;
• SLAs mit messbaren Performance‑ und Wiederherstellungszielen;
• Haftungsfragen und Compliance‑Zertifikate, die Sie technisch verifizieren sollten.

Praxis-Checkliste für Pilot‑Gates

Vor jedem Gate prüfen und dokumentieren:

• Technische Validierung: Funktion, Performance, Integration;
• Sicherheit: Penetrationstest, Konfigurationsaudit, IAM‑Review;
• Kostencheck: Prognose vs. tatsächlich gemessene Werte im Pilot;
• Audit‑Artefakte: IaC‑Hashes, Log‑Snapshots, Backup‑Reports;
• Business‑Abnahme: Fachabteilung bestätigt RTO/RPO.

Fazit: Entscheidung braucht Struktur, nicht Sentimentalität

Die Frage „Inhouse, Cloud oder Hybrid“ ist keine technologische Modefrage, sondern eine strategische Abwägung zwischen Kontrolle, Agilität, Kosten und Compliance. Verwenden Sie ein gewichtetes Kriterienmodell, dokumentieren Sie Governance, planen Sie Exit‑Szenarien und testen Sie praktisch mit einem Pilot. Das reduziert Risiko, liefert audittaugliche Evidence und macht die Entscheidung für Betriebs‑ und Geschäftsführung nachvollziehbar. Entscheiden Sie modular, messen Sie die Ergebnisse und behalten Sie Exit‑Readiness als fortlaufendes Betriebsziel.

Weiterführende Schritte und Vorlagen

Nutzen Sie die oben genannten Vorlagen (Migrations‑Policy, RACI, Scorecard) als Ausgangspunkt für Ihr Entscheidungsboard. Ergänzen Sie diese um eine standardisierte Audit‑Checkliste und ein Reporting‑Dashboard für Kosten und Security‑KPI.

FAQ

Untenstehend finden Sie kurze Antworten auf häufige Fragen; diese sollten Sie in Ihre Entscheidungsdokumentation aufnehmen.

Welche Daten sollten niemals ohne Prüfung in die Public Cloud verschoben werden?

Daten mit gesetzlichen Lokalitätsvorgaben, personenbezogene Daten mit restriktiven Auflagen oder sicherheitskritische Konfigurationsdaten (z. B. private Keys) sollten vor einer Cloud‑Migration rechtlich und technisch geprüft werden. Prüfen Sie Aufbewahrungspflichten, Verschlüsselungsanforderungen und Auditierbarkeit; wenn nötig, bleiben solche Daten in einer kontrollierten On‑Premise‑Zone oder in einer Private Cloud.

Wie messe ich, ob ein Hybrid‑Betrieb sinnvoller ist als ein kompletter Cloud‑Move?

Erstellen Sie eine Scorecard mit gewichteten Kriterien (Compliance, Latenz, Kosten, Integrationsbedarf etc.). Führen Sie Pilotmigrationen mit echten Lastprofilen durch und vergleichen Sie TCO, RTO/RPO sowie operative Aufwände. Hybrid lohnt, wenn bestimmte Kriterien (z. B. Latenz oder Datensouveränität) hohe Punktzahlen erhalten, während andere Module Cloud‑Vorteile haben.

Was sind die größten versteckten Kosten bei Cloud‑Migrationen?

Häufige Kostenfallen sind Egress‑Gebühren für Datentransfer, hohe IOPS‑/Speicherkosten durch ungeeignete Speicherklassen, Management‑Addons und Mitarbeiternachschulungen. Exit‑Kosten und Anpassungen proprietärer Managed Services können zusätzliche Aufwände verursachen.

Welche Audit‑Artefakte müssen in der Entscheidungsdokumentation enthalten sein?

Mindestens: IaC‑Templates mit Hashes, Access‑ und Change‑Logs, Backup‑ und Restore‑Reports, Key‑Management‑Logs, Patch‑ und Vulnerability‑Reports sowie die Migrations‑Policy mit Success‑Criteria. Diese Artefakte sind Prüfnachweise für Compliance und sollten versioniert und gesichert bereitstehen.

Wann ist ein Managed Service Provider (MSP) eine sinnvolle Option?

Ein MSP ist sinnvoll, wenn intern Skills fehlen, das Risiko geringere direkte Kontrolle erfordert, oder wenn Time‑to‑Market wichtig ist. Stellen Sie sicher, dass Verträge audittaugliche SLAs, Verantwortlichkeitszuweisungen (RACI) und Exit‑Klauseln enthalten sowie regelmäßige Sicherheits‑ und Kostenreviews vorsehen.

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