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
| AWS Service | Anwendungsfall im MSP-Kontext | Empfehlung |
|---|---|---|
| AWS Cost Explorer | Kostentransparenz, Trend-Analyse, Anomalie-Erkennung | Wöchentlich nutzen, Cost Anomaly Alerts aktivieren |
| Amazon CloudWatch | Monitoring, Alerting, Service-Health-Dashboards | Dashboards mit Kunden-Zugriff als SLA-Nachweis |
| AWS Config | Compliance-Status, Konfigurationshistorie, Drift-Erkennung | Config Rules für kritische Compliance-Anforderungen |
| AWS Systems Manager | Patch-Status, Inventory, Run-Command, Change Manager | Change-Management-Prozesse über SSM Change Manager |
| AWS Trusted Advisor | Best-Practice-Empfehlungen, Cost-Optimization-Checks | Monatliche Review-Agenda auf Trusted-Advisor-Findings basieren |
| AWS Security Hub | Zentrales Security-Dashboard, Compliance-Standards | CIS AWS Foundations Benchmark als Baseline aktivieren |
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
- AWS-Inventar vollständig erfasst (Systems Manager Inventory oder AWS Config)
- Architektur-Dokumentation aktuell und vollständig
- SLA-Anforderungen pro Workload-Kategorie definiert
- Internen Service Owner benannt
- RACI-Matrix für Verantwortlichkeiten erstellt
- CloudWatch-Basismonitoring konfiguriert
- CloudTrail und AWS Config aktiviert
- FinOps-Entscheidungsmandat definiert
- AVV nach DSGVO mit MSP-Partner abgeschlossen
- 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