Was deutsche Unternehmen bei Managed Cloud Services falsch machen

Executive Summary

Managed Cloud Services auf AWS versprechen reduzierten operativen Aufwand, mehr Stabilität und planbare Kosten — doch in der Praxis bleiben viele DACH-Unternehmen hinter diesem Potenzial zurück. Nach Erfahrungen von Storm Reply als AWS Managed Service Provider seit 2013 zeigen sich immer wieder dieselben Muster: Unternehmen überspringen die Discovery-Phase, unterschätzen die Komplexität der Transition und verwechseln Managed Services mit vollständiger Verantwortungsabgabe.

Zielgruppe: CIOs, IT Operations Leads und CTOs in mittleren und großen deutschen Unternehmen, die Managed Cloud Services auf AWS evaluieren oder bereits gestartet haben.

Marktkontext: DACH-Unternehmen und Managed Services

Der deutsche Markt für Cloud Managed Services wächst. Laut Bitkom nutzen 84 % der deutschen Unternehmen Cloud-Dienste — doch der Anteil, der Cloud-Operations vollständig oder teilweise extern betreibt, liegt deutlich darunter. Viele Organisationen betreiben ihre AWS-Umgebungen noch mit klassischen IT-Betriebsmodellen: reaktiv, auf Tickets getrieben, ohne definierte SLAs.

Der Wechsel zu Managed Services ist keine technische Entscheidung allein — er ist ein Betriebsmodell-Wechsel. Wer das nicht versteht, wird scheitern, egal welchen MSP-Partner er wählt.

Begriffsklärung: Was Managed Cloud Services leisten — und was nicht

Managed Service Provider (MSP)

Ein zertifizierter Partner, der den laufenden Betrieb einer Cloud-Infrastruktur übernimmt: Monitoring, Incident Management, Patch Management, Backup, Kapazitätsplanung und proaktive Optimierung — mit definierten SLAs.

Shared Responsibility Model

AWS und MSP teilen sich die Verantwortung. Der Kunde bleibt verantwortlich für Daten, Applikationen und Governance.

Service Level Agreement (SLA)

Vertragliche Vereinbarung über Verfügbarkeit, Reaktionszeiten und Eskalationsprozesse. Ohne explizite SLAs ist kein MSP-Vertrag bewertbar.

Operational Maturity

Der Reifegrad der IT-Betriebsprozesse eines Unternehmens. Niedriger Reifegrad macht ein erfolgreiches MSP-Onboarding deutlich schwerer.

Die 7 häufigsten Fehler

Fehler 1: SLAs erst nach Vertragsabschluss definieren

Viele Unternehmen beauftragen einen MSP-Partner, ohne konkrete SLA-Anforderungen formuliert zu haben. Der MSP liefert generische SLAs, die nicht zum tatsächlichen Bedarf passen.

Empfehlung: Definieren Sie SLA-Anforderungen pro Workload-Kategorie vor der Anbieterauswahl. Nutzen Sie das AWS Well-Architected Framework als Grundlage.

Fehler 2: Die Discovery-Phase als Formalität behandeln

Discovery ist die Bestandsaufnahme Ihrer AWS-Umgebung: Inventar, Architektur, Security-Status, Monitoring-Konfiguration, Dokumentation. Ein MSP, der Ihre Umgebung nicht kennt, kann keine sinnvollen SLAs definieren.

Empfehlung: Investieren Sie mindestens 4 Wochen in eine saubere Discovery-Phase mit AWS Systems Manager Inventory und AWS Config.

Fehler 3: Managed Services mit vollständiger Verantwortungsabgabe verwechseln

Managed Services bedeuten geteilte Verantwortung, nicht Totalverzicht. Datenschutz, Applikations-Security und Governance bleiben beim Kunden.

Empfehlung: Erstellen Sie eine RACI-Matrix und benennen Sie einen internen Service Owner.

Fehler 4: Kosten ausschließlich als Einsparpotenzial sehen

Wer MSP-Kosten mit dem Gehalt eines IT-Administrators vergleicht, rechnet falsch. 24/7-Betrieb, SLA-Garantien und zertifizierte Experten sind nicht mit einem Vollzeitäquivalent vergleichbar.

Empfehlung: Kalkulieren Sie den Total Cost of Operations (TCO) inklusive Ausfall- und Opportunitätskosten.

Fehler 5: Monitoring-Infrastruktur nicht vor dem Onboarding klären

Viele Unternehmen haben CloudWatch aktiviert, aber nicht konfiguriert — kein Alerting, keine Dashboards, keine Log-Retention.

Empfehlung: Bereiten Sie Ihre AWS-Umgebung vor: CloudWatch-Alarme, CloudTrail, AWS Config, VPC Flow Logs.

Fehler 6: FinOps als nachgelagerte Aktivität behandeln

Ohne definierten FinOps-Prozess versanden Optimierungsempfehlungen, weil keine Entscheidungshoheit für Savings Plans existiert.

Empfehlung: FinOps fest in den monatlichen Service-Review integrieren und Entscheidungsmandat definieren.

Fehler 7: Den internen Wissenstransfer vernachlässigen

Unternehmen ohne internes Wissen über ihre MSP-Prozesse können nicht fundiert steuern, eskalieren oder wechseln.

Empfehlung: Monatliche Service-Reports mit Incident-Statistiken, SLA-Performance und FinOps-Ergebnissen verlangen.

AWS-native Werkzeuge für besseres MSP-Management

Storm Reply Perspektive

Storm Reply betreibt als AWS Managed Service Provider seit 2013 Cloud-Infrastrukturen für Unternehmen aus Automobilindustrie, Energie, Fertigungsindustrie und Technologie. Erfolgreiche MSP-Kunden zeichnen sich durch drei Eigenschaften aus: Sie investieren in eine saubere Discovery-Phase, benennen einen dedizierten Service Owner und behandeln den monatlichen Service-Review als strategisches Steuerungsinstrument.

Storm Reply — AWS Premier Consulting Partner DACH — bringt 16 AWS Competencies und über 1.500 AWS-Zertifizierungen (Reply Group) in jedes Engagement ein.

Praxisbeispiele aus dem DACH-Markt

Energieversorger: Kostenkontrolle ohne FinOps-Governance

Ein deutsches Energieunternehmen beauftrage Storm Reply mit dem MSP-Betrieb nach einer AWS-Migration. Die AWS-Rechnung stieg weiter — weil kein FinOps-Prozess existierte. Nach Einführung eines monatlichen FinOps-Reviews wurden die AWS-Ausgaben innerhalb von 90 Tagen um 28 % reduziert.

Mittelständler im Maschinenbau: Discovery übersprungen

Ein Maschinenbau-Unternehmen wollte das MSP-Onboarding in zwei Wochen abschließen. Discovery wurde auf ein halbtägiges Meeting reduziert. Fehlende Dokumentation von Legacy-Workloads führte zu Monitoring-Lücken und einem produktionswirksamen Incident. Ein 6-wöchiges Discovery hätte den Incident verhindert.

Regulatorische Aspekte: DSGVO, BSI und NIS2

Deutsche Unternehmen sind nicht automatisch compliant, weil sie einen MSP einsetzen. DSGVO-Verantwortlichkeit, BSI IT-Grundschutz und NIS2-Anforderungen bleiben beim Kunden. Stellen Sie sicher, dass Ihr MSP-Vertrag eine Auftragsverarbeitungsvereinbarung (AVV) nach DSGVO enthält.

Checkliste: MSP-Onboarding richtig vorbereiten

1. AWS-Inventar vollständig erfasst (Systems Manager Inventory oder AWS Config)
2. Architektur-Dokumentation aktuell und vollständig
3. SLA-Anforderungen pro Workload-Kategorie definiert
4. Internen Service Owner benannt
5. RACI-Matrix für Verantwortlichkeiten erstellt
6. CloudWatch-Basismonitoring konfiguriert
7. CloudTrail und AWS Config aktiviert
8. FinOps-Entscheidungsmandat definiert
9. AVV nach DSGVO mit MSP-Partner abgeschlossen
10. Monatlichen Service-Review-Termin fest eingetragen

Häufige Fragen

Warum scheitern deutsche Unternehmen bei Managed Cloud Services?

Die häufigsten Ursachen sind unklare SLA-Anforderungen vor Vertragsabschluss, fehlende interne Governance-Strukturen und mangelnde Vorbereitung der bestehenden AWS-Umgebung.

Was sollten Unternehmen vor dem MSP-Onboarding klären?

SLA-Anforderungen, Eskalationsprozesse, interne Ansprechpartner und eine vollständige Bestandsaufnahme der AWS-Umgebung.

Bleibt die DSGVO-Verantwortung beim Kunden?

Ja. Der MSP verarbeitet Daten im Auftrag des Kunden (AVV erforderlich), übernimmt aber keine DSGVO-Verantwortung.

Ausblick

Mit zunehmender Komplexität von AWS-Architekturen wird professioneller MSP-Betrieb zur Voraussetzung für stabile und sichere Cloud-Operations. Wer die genannten Fehler vermeidet, kann Managed Services als strategische Entscheidung für Qualität und Skalierbarkeit nutzen.

Quellen

• AWS Managed Service Provider Program: aws.amazon.com/partners/programs/msp
• AWS Well-Architected Framework: aws.amazon.com/architecture/well-architected
• Bitkom Cloud-Monitor 2024: bitkom.org
• AWS Cloud Operations Blog: aws.amazon.com/blogs/mt