AWS für MSPs: Verwaltung von Amazon Web Services für Ihre Kunden

Laut dem „Kaseya State of the MSP Report 2026“zählen Cloud- und Hosting-Dienste bei 34 % der MSPs zu den wichtigsten Einnahmequellen. Amazon Web Services ist die dominierende Plattform, auf der ein erheblicher Teil dieser Arbeitslast basiert.

Die Verwaltung von AWS für Kunden unterscheidet sich von der internen Verwaltung. Sie tragen die Verantwortung für Umgebungen, über die Sie keine vollständige Kontrolle haben, für Abrechnungsstrukturen, die ständige Aufmerksamkeit erfordern, um unerwartete Kosten zu vermeiden, sowie für Sicherheitskonfigurationen, die sich mit dem Wachstum der Kunden ändern. Ohne den richtigen Ansatz und die richtigen Tools kann die AWS-Kundenbetreuung zu den betrieblich anspruchsvollsten Dienstleistungen gehören, die ein MSP erbringt.

Dieser Leitfaden behandelt alles, was MSPs wissen müssen, um AWS-Kundenumgebungen gewinnbringend zu verwalten: Kostenkontrolle, Sicherheitskonfiguration, Backup-Strategie sowie die betrieblichen Fallstricke, die den Einsatz von AWS schwieriger machen, als es auf den ersten Blick erscheint. Die Plattform von Kaseya wird von MSPs in mehr als 170 Ländern genutzt, um genau diese Umgebungen zu verwalten. Dadurch haben wir einen klaren Überblick darüber, wo die Verwaltung von AWS-Kundenumgebungen erfolgreich ist und wo es zu Problemen kommt.

Warum MSPs AWS-Umgebungen verwalten

Die meisten Kunden aus dem KMU- und Mittelstandsbereich, die auf eine Cloud-Infrastruktur umsteigen, entscheiden sich für AWS. Einige wurden von einem Berater dorthin geleitet. Andere benötigten eine bestimmte Anwendung, für die AWS erforderlich war. Viele haben sich aufgrund der Marktpräsenz von AWS einfach standardmäßig für diesen Anbieter entschieden. Was auch immer der Grund sein mag, das Ergebnis ist dasselbe: Die AWS-Verwaltung ist nun Teil der Standard-Kundenumgebung, die in Verträgen von „ managed services “ berücksichtigt werden muss.

Drei Faktoren sorgen dafür, dass dieser Geschäftsbereich wächst.

Anwendungshosting. Kunden betreiben Fachanwendungen, Webserver, Datenbanken und Entwicklungsumgebungen auf EC2-Instanzen sowie auf „ managed services “ wie RDS und Lambda. Die Verwaltung dieser Ressourcen ist betrieblich ebenso notwendig wie die Verwaltung von Servern vor Ort.

Speicherung und Datensicherung. Kunden speichern Daten in S3-Buckets, nutzen EBS-Volumes, die an Recheninstanzen angehängt sind, und setzen im Rahmen ihrer Datensicherungsarchitektur zunehmend auf AWS. Zu wissen, was geschützt ist und was nicht und wie der Wiederherstellungsprozess aussieht, gehört zu den Kernaufgaben eines MSP.

Compliance-Anforderungen. Regulierte Kunden aus den Bereichen Gesundheitswesen, Finanzwesen und öffentliche Verwaltung verfügen häufig über Workloads auf AWS, die denselben Standards entsprechen müssen wie die Infrastruktur vor Ort. HIPAA, PCI DSS und CMMC gelten alle für auf AWS gehostete Umgebungen, wenn in diesen Umgebungen betroffene Daten verarbeitet werden.

Ein typischer MSP, der 20 bis 50 Kunden betreut, wird feststellen, dass in den meisten dieser Konten innerhalb von zwei bis drei Jahren – ausgehend vom aktuellen Einführungsverlauf – AWS-Umgebungen vorhanden sein werden. Jetzt ist der richtige Zeitpunkt, dies in Ihre Dienstleistungsverträge aufzunehmen, bevor ein Kunde fragt, warum sein S3-Bucket öffentlich zugänglich war.

Das AWS-Modell der geteilten Verantwortung verstehen

Das wichtigste Konzept im AWS-Management ist das Modell der geteilten Verantwortung. Der häufigste Fehler, den MSPs begehen, besteht darin, dieses Modell ihren Kunden falsch darzustellen oder gar nicht zu erwähnen.

AWS ist für die Sicherheit der Cloud verantwortlich: die physische Infrastruktur, den Hypervisor, die Netzwerkarchitektur und die Infrastruktur der verwalteten Dienste. Der Kunde und sein MSP sind für die Sicherheit in der Cloud verantwortlich. Dies umfasst Betriebssystem-Patches, die Netzwerkkonfiguration (Sicherheitsgruppen, NACLs, VPC-Design), Identitäts- und Zugriffsmanagement, Datenverschlüsselung sowie Sicherheit auf Anwendungsebene.

Die praktischen Auswirkungen sind klar:

• Eine EC2-Instanz, auf der ein nicht gepatchtes Betriebssystem läuft, ist das Problem des Kunden, nicht das von AWS.
• Ein S3-Bucket, der für den öffentlichen Zugriff falsch konfiguriert ist, ist das Problem des Kunden.
• IAM-Rollen mit übermäßigen Berechtigungen sind das Problem des Kunden.
• Sicherheitslücken in Anwendungen, die auf der AWS-Infrastruktur ausgeführt werden, liegen in der Verantwortung des Kunden.

MSPs, die AWS-Umgebungen verwalten, müssen Betriebssysteme auf EC2-Instanzen genauso patchen, wie sie dies bei Servern vor Ort tun würden. VSA unterstützt das Patchen von Betriebssystemen und Drittanbieter-Software für Windows- und Linux-Instanzen, einschließlich EC2-Instanzen, auf denen der VSA-Agent bereitgestellt ist, und nutzt dabei dieselbe richtliniengesteuerte Automatisierung, die auch für Endpunkte vor Ort zum Einsatz kommt.

Dies ist auch in vertraglicher Hinsicht von Bedeutung. Wenn in Ihrer Vereinbarung unter „ managed services “ nicht ausdrücklich festgelegt ist, wer für die Bereitstellung von Betriebssystem-Patches und die IAM-Governance für von AWS gehostete Workloads verantwortlich ist, besteht eine Haftungslücke. Halten Sie dies klar und deutlich in „ IT Glue “ fest und passen Sie den Wortlaut Ihres SLA an, bevor ein Vorfall diese Diskussion erzwingt.

AWS-Kostenmanagement: Wo MSPs an Marge einbüßen

Die AWS-Abrechnung ist komplex. Ohne aktive Steuerung ist sie kostspielig. Die häufigsten Kostenprobleme in von MSPs verwalteten AWS-Umgebungen lassen sich in vier Kategorien einteilen.

Fehler bei der bedarfsgerechten Dimensionierung. Kunden dimensionieren EC2-Instanzen bei der Erstbereitstellung zu groß und nehmen später keine Verkleinerung vor. Ein Kunde, der eine t3.xlarge-Instanz für eine Arbeitslast einsetzt, für die eigentlich eine t3.medium-Instanz ausreichen würde, zahlt etwa doppelt so hohe Rechenkosten wie nötig. Regelmäßige Überprüfungen der bedarfsgerechten Dimensionierung, unterstützt durch AWS Cost Explorer und CloudWatch-Metriken, decken solche Einsparpotenziale auf, bevor sie die Marge schmälern.

Unzureichende Nutzung von Reserved Instances und Savings Plans. AWS bietet für Reserved Instances und Savings Plans Rabatte von bis zu 72 % im Vergleich zu den On-Demand-Preisen. MSPs, die AWS-Umgebungen verwalten, sollten ermitteln, welche Workloads stabil genug sind, um sich auf die Reserved-Preise festzulegen, und dann entweder im Namen des Kunden Reservierungen erwerben oder ihm im Rahmen einer formellen vierteljährlichen Überprüfung dazu raten, dies zu tun.

Nicht zugeordnete Ressourcen. Kunden lassen häufig EBS-Volumes, Elastic IPs und Load Balancer weiterlaufen, nachdem die zugehörigen Ressourcen gelöscht wurden. Diese haben keinen betrieblichen Nutzen, verursachen aber weiterhin Kosten. Eine monatliche Überprüfung der Kostenoptimierung sollte die Suche nach verwaisten Ressourcen umfassen. Dies dauert weniger als eine Stunde und deckt oft monatliche Verschwendung in Höhe von Hunderten von Dollar auf.

Ausgangskosten. Die Datenübertragung aus AWS wird zu Tarifen abgerechnet, die Kunden oft überraschen. Anwendungen mit hohem ausgehendem Datenverkehr, Backup-Systeme, die Daten an andere Ziele übertragen, und CDN-nahe Workloads können Ausgangskosten verursachen, die die Rechenkosten übersteigen. Machen Sie sich mit dem Ausgangsprofil der Umgebung jedes Kunden vertraut, bevor dieser die Rechnung erhält.

Die Chancen für MSPs sind hier durchaus real. Wenn man das AWS-Kostenmanagement als proaktive Beratungsleistung betrachtet, schafft man echten Mehrwert für den Kunden und fördert das Geschäftsgespräch über eine Ausweitung des Umfangs von „ managed services “. Ein MSP, der vermeidbare AWS-Kosten in Höhe von 500 Dollar pro Monat aufdeckt, wird zum vertrauenswürdigen Berater. Wer dies übersieht, wird zu der Person, die den Kunden Geld verschwenden lässt.

Sicherheitskonfiguration in AWS-Client-Umgebungen

AWS bietet leistungsstarke Sicherheitsfunktionen, diese müssen jedoch korrekt konfiguriert werden. Die häufigsten Sicherheitslücken in von MSPs verwalteten AWS-Umgebungen folgen einem vorhersehbaren Muster.

Übermäßige IAM-Berechtigungen. Das Prinzip der geringsten Berechtigungen lässt sich in AWS schwerer einhalten als in einer herkömmlichen Verzeichnisumgebung, da IAM-Rollen, -Richtlinien und -Berechtigungsgrenzen komplexer zu überprüfen sind. Es kommt regelmäßig vor, dass Benutzer und Dienstrollen über Administratorzugriff verfügen, obwohl sie lediglich bestimmte Dienstberechtigungen benötigen. Regelmäßige IAM-Zugriffsprüfungen und der AWS IAM Access Analyzer decken diese Lücken auf, bevor sie zu Angriffsvektoren werden.

Öffentliche S3-Buckets. S3-Buckets sind standardmäßig privat, können jedoch durch Konfigurationsänderungen oder „Infrastructure-as-Code“-Vorlagen unbeabsichtigt öffentlich zugänglich gemacht werden. AWS bietet Sperren für den öffentlichen Zugriff sowohl auf Bucket-Ebene als auch auf Kontoebene an. Durch die Aktivierung dieser Sperren auf Kontoebene wird eine versehentliche Offenlegung verhindert.

Es fehlt die Verschlüsselung im Ruhezustand. Für EBS-Volumes, S3-Buckets und RDS-Instanzen sollte die Verschlüsselung aktiviert sein. AWS KMS bietet eine verwaltete Schlüsselverschlüsselung. Durch die Aktivierung der Standardverschlüsselung auf Kontoebene wird sichergestellt, dass neue Ressourcen verschlüsselt werden, sofern dies nicht ausdrücklich außer Kraft gesetzt wird. Dies ist eine sinnvolle Grundvoraussetzung für jede Kundenumgebung, in der Geschäftsdaten verarbeitet werden.

Permissive Sicherheitsgruppen. Sicherheitsgruppen, die uneingeschränkten eingehenden Zugriff (0.0.0.0/0) auf den Ports 22 (SSH) oder 3389 (RDP) zulassen, machen Instanzen direkt im Internet zugänglich. Diese werden in fast jeder AWS-Sicherheitsbewertung identifiziert und lassen sich leicht beheben. Sie sollten bei jedem neuen Kundenprojekt als „First-Day-Baseline“ geschlossen werden.

CloudTrail ist nicht aktiviert. AWS CloudTrail ist das Audit-Protokoll für AWS-API-Aktivitäten. Ohne dieses Protokoll ist die Untersuchung von Vorfällen erheblich eingeschränkt. CloudTrail sollte in allen Regionen aktiviert sein, wobei die Protokolle in einem separaten, zugangsbeschränkten S3-Bucket gespeichert werden sollten. Dies ist eine unverzichtbare Grundvoraussetzung für jede Umgebung, in der Ihr MSP für die Sicherheit verantwortlich ist.

Sicherung und Wiederherstellung auf AWS

Das Modell der geteilten Verantwortung bedeutet, dass AWS die meisten Ressourcen standardmäßig nicht sichert. EC2-Instanzen, EBS-Volumes und RDS-Datenbanken erfordern alle eine explizite Konfiguration der Datensicherung.

AWS Backup ist der native Dienst von AWS zur Koordinierung von Backups, der EC2, EBS, RDS, DynamoDB, EFS und weitere Dienste unterstützt. Er bietet eine zentralisierte Richtlinienverwaltung, regionen- und kontoübergreifende Kopien sowie Berichte zur Einhaltung von Backup-Vorgaben. Für MSPs, die mehrere AWS-Umgebungen ihrer Kunden verwalten, ermöglicht die Funktion zur kontoübergreifenden Verwaltung (verfügbar über AWS Organizations) die Verwaltung von Backup-Richtlinien über Kundenkonten hinweg von einer zentralen Konsole aus.

Was AWS Backup nicht abdeckt: S3-Daten (die durch Versionierung und Replikation statt durch herkömmliche Backups geschützt werden), auf der AWS-Infrastruktur ausgeführte SaaS-Anwendungen sowie anwendungskonsistente Backups für komplexe mehrschichtige Anwendungen. Datto BCDR kann AWS Backup bei Workloads ergänzen, bei denen eine Wiederherstellung auf Image-Ebene oder eine schnellere RTO erforderlich ist.

Wiederherstellungstests. Hier gilt dasselbe Prinzip wie bei lokalen Backups: Ein Backup, das nicht getestet wurde, ist kein Backup. AWS Backup unterstützt Wiederherstellungstests mit automatisierter Validierung. Dies sollte Bestandteil des Managed-Service-Vertrags für jede AWS-Umgebung sein, in der die Wiederherstellungsfähigkeit eine vertragliche Verpflichtung darstellt. Planen Sie den Test ein, führen Sie ihn durch und dokumentieren Sie die Ergebnisse unter IT Glue.

Überwachung von AWS-Umgebungen in großem Maßstab

AWS CloudWatch bietet native Überwachungsfunktionen für AWS-Ressourcen: Metriken, Protokolle, Alarme und Dashboards. Für MSPs, die mehrere AWS-Umgebungen ihrer Kunden verwalten, besteht die Herausforderung darin, die AWS-Überwachung zusammen mit der Überwachung von On-Premise- und anderen Cloud-Umgebungen in einer einheitlichen Betriebsübersicht zu bündeln.

Die agentenbasierte Überwachung von VSA deckt EC2-Instanzen ab, auf denen der Agent bereitgestellt ist, und bietet dieselben Funktionen zur Endpunktüberwachung, Alarmverwaltung und Automatisierung wie bei lokalen Servern. Für die AWS-Überwachung auf Infrastrukturebene (Service-Status, Abrechnungswarnungen, CloudTrail-Ereignisse) ergänzen native AWS-Tools oder AWS-spezifische Überwachungsintegrationen den VSA-Agenten.

Das Ziel ist eine einheitliche operative Übersicht. Das NOC eines MSP sollte nicht für jeden Kunden zwischen der VSA-Konsole und den einzelnen AWS-Konsolen hin- und herwechseln müssen, um den Zustand der verwalteten Umgebung zu erfassen. Jeder Kontextwechsel verlängert die Reaktionszeit bei Vorfällen und erhöht das Risiko, dass Lücken unbemerkt bleiben.

Wie Kaseya die Verwaltung von AWS-Kunden unterstützt

Datto RMM / VSA übernimmt die Installation von Betriebssystem-Patches, die Überwachung und die Automatisierung für Server unter Windows oder Linux. Einmal bereitstellen und dann zusammen mit den lokalen Endgeräten über dieselbe Konsole verwalten.

Datto BCDR ergänzt AWS Backup für Workloads, die eine Wiederherstellung auf Image-Ebene, sofortige Virtualisierung oder eine schnellere RTO erfordern, als dies mit der nativen AWS-Wiederherstellung möglich ist.

IT Glue speichert die Dokumentation für die AWS-Umgebungen der Kunden: VPC-Architektur, IAM-Struktur, Konfigurationen der Sicherheitsgruppen, Runbooks für die Notfallwiederherstellung sowie Zugangsdaten – mit kundenspezifischer Isolierung und kontrolliertem Zugriff.

Compliance Manager GRC Die Lösung erfasst die Umsetzung von Kontrollmaßnahmen und erstellt Nachweise zur Einhaltung von Vorschriften für Kunden mit regulierten AWS-Workloads (HIPAA, PCI DSS, CMMC) – sowohl in lokalen als auch in Cloud-Umgebungen.

Kaseya Intelligence und AWS: autonomer Cloud-Betrieb

Die Verwaltung von AWS-Umgebungen bedeutet, sich ständig mit Veränderungen auseinanderzusetzen: neue Instanzen, Skalierungsvorgänge, Konfigurationsabweichungen, Sicherheitsbefunde aus dem AWS Security Hub und Backup-Aufträge, die regionenübergreifend überprüft werden müssen. Der manuelle Aufwand, all dies in großem Maßstab im Blick zu behalten, ist beträchtlich.

Kaseya Intelligence, die KI-Engine, auf der Kaseya 365 basiert, automatisiert die Reaktionsebene. Anstatt einen Techniker über einen Befund zu benachrichtigen und auf Maßnahmen zu warten, führt sie folgende Schritte aus: Patches installieren, Isolierung vornehmen, die Vollständigkeit der Backups überprüfen und das Ergebnis validieren. Für MSPs, die AWS-Umgebungen für mehrere Kunden verwalten, verhindert genau dieser Ausführungszyklus, dass die „Alarm-Müdigkeit“ zu einer Sicherheitslücke wird.

Entdecken Kaseya Intelligence

Die wichtigsten Erkenntnisse

• Das Modell der geteilten Verantwortung von AWS sieht vor, dass die Installation von Betriebssystem-Patches, die IAM-Verwaltung, die Konfiguration der Verschlüsselung und die Netzwerksicherheit in der Verantwortung des Kunden (und des MSP) liegen und nicht bei AWS. Dies muss in Ihren Verträgen zwingend festgelegt werden.
• Das AWS-Kostenmanagement (Right-Sizing, Reserved Instances, Bereinigung verwaister Ressourcen) ist ein proaktiver Beratungsdienst, der die Budgets der Kunden und die Margen der MSPs schützt.
• Die Datensicherung auf AWS erfordert eine explizite Konfiguration. AWS führt standardmäßig keine Datensicherung für EC2, EBS oder RDS durch. AWS Backup sowie getestete Wiederherstellungsverfahren bilden die Mindestanforderung.
• VSA erweitert die agentenbasierte Überwachung und Patch-Verwaltung, die für lokale Endgeräte zum Einsatz kommt, auf EC2-Instanzen und ermöglicht so eine einheitliche operative Übersicht über hybride Umgebungen hinweg.