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 nicht die volle 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 operativen 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 sie an ihre Grenzen stößt.

Warum MSPs AWS-Umgebungen verwalten

Die meisten KMU- und Mittelstandskunden, die auf eine Cloud-Infrastruktur umsteigen, entscheiden sich für AWS. Einige wurden von einem Berater dorthin geleitet. Andere benötigten eine bestimmte Anwendung, die dies erforderte. Viele entschieden sich einfach aufgrund der Marktpräsenz von AWS für diesen Anbieter. Was auch immer der Grund sein mag, das Ergebnis ist dasselbe: Die Verwaltung von AWS ist nun Teil der Standard-Kundenumgebung, die in managed services berücksichtigt werden muss.

Drei Faktoren sorgen für ein wachsendes Dienstleistungsangebot.

Anwendungshosting. Kunden betreiben Fachanwendungen, Webserver, Datenbanken und Entwicklungsumgebungen auf EC2-Instanzen und managed services 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, ist eine zentrale Aufgabe von MSPs.

Compliance-Anforderungen. Regulierte Kunden aus den Bereichen Gesundheitswesen, Finanzwesen und öffentliche Verwaltung betreiben auf AWS häufig Workloads, die denselben Standards genügen müssen wie lokale Infrastrukturen. HIPAA, PCI DSS und CMMC gelten für auf AWS gehostete Umgebungen, sofern diese Umgebungen betroffene Daten verarbeiten.

Ein typischer MSP, der 20 bis 50 Kunden betreut, wird feststellen, dass in den meisten dieser Konten innerhalb von zwei bis drei Jahren nach der heutigen Einführung AWS-Umgebungen vorhanden sein werden. Jetzt ist der richtige Zeitpunkt, dies in Ihre Serviceverträge aufzunehmen – noch 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 die 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älschlicherweise für den öffentlichen Zugriff konfiguriert wurde, 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 laufen, liegen in der Verantwortung des Kunden.

MSPs, die AWS-Umgebungen verwalten, müssen Betriebssysteme auf EC2-Instanzen genauso patchen, wie sie dies bei lokalen Servern tun würden. VSA unterstützt das Patchen von Betriebssystemen und Drittanbietersoftware für Windows- und Linux-Instanzen, einschließlich EC2-Instanzen, auf denen der VSA-Agent installiert ist, und nutzt dabei dieselbe richtliniengesteuerte Automatisierung, die auch für lokale Endgeräte verwendet wird.

Dies ist auch in vertraglicher Hinsicht von Bedeutung. Wenn in Ihrem managed services nicht ausdrücklich festgelegt ist, wer für die OS-Patches und die IAM-Governance bei AWS-gehosteten Workloads verantwortlich ist, besteht eine Haftungslücke. Halten Sie dies in IT Glue klar fest IT Glue passen Sie Ihre SLA-Formulierungen 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 Workload 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 Gewinnmarge schmälern.

Unzureichende Nutzung von Reserved Instances und Savings Plans. AWS bietet für Reserved Instances und Savings Plans Preisnachlässe 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 reservierten Preise festzulegen, und dann entweder im Namen des Kunden Reservierungen erwerben oder diesen im Rahmen einer formellen vierteljährlichen Überprüfung dazu raten.

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.

Ausgangsdatenkosten. 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 Ausgangsdatenkosten verursachen, die die Rechenkosten übersteigen. Machen Sie sich mit dem Ausgangsdatenprofil der Umgebung jedes Kunden vertraut, bevor dieser die Rechnung erhält.

Die Chancen für MSPs sind hier real. Wenn man das AWS-Kostenmanagement als proaktive Beratungsdienstleistung betrachtet, schafft man echten Mehrwert für den Kunden und fördert das Geschäftsgespräch über die Ausweitung 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 demjenigen, der 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 Privilegien lässt sich in AWS schwerer durchsetzen 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, doch können Konfigurationsänderungen oder „Infrastructure-as-Code“-Vorlagen dazu führen, dass Buckets unbeabsichtigt öffentlich zugänglich werden. AWS bietet Sperren für den öffentlichen Zugriff auf Bucket- und 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-Sicherheitsüberprüfung festgestellt und lassen sich leicht beheben. Sie sollten bei jedem neuen Kundenprojekt als grundlegende Maßnahme am ersten Tag 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 stark 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 Backup-Orchestrierungsdienst von AWS, der EC2, EBS, RDS, DynamoDB, EFS und weitere Dienste unterstützt. Er bietet eine zentralisierte Richtlinienverwaltung, regionen- und kontoübergreifende Kopierfunktionen sowie Berichte zur Einhaltung von Backup-Vorgaben. Für MSPs, die mehrere AWS-Umgebungen von 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 vertraglich zugesichert ist. Planen Sie den Test ein, führen Sie ihn durch und dokumentieren Sie die Ergebnisse in 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 lokaler und anderer Cloud-Umgebungen in einer einheitlichen Betriebsübersicht zu bündeln.

Die agentenbasierte Überwachung von VSA deckt EC2-Instanzen ab, auf denen der Agent installiert ist, und bietet dieselben Funktionen für Endpunktüberwachung, Alarmmanagement und Automatisierung wie bei lokalen Servern. Für die AWS-Überwachung auf Infrastrukturebene (Systemzustand, Abrechnungsalarme, 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 verlangsamt die Reaktion auf Vorfälle und erhöht das Risiko, dass Probleme 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 Wiederherstellungszeit (RTO) erfordern, als dies mit der nativen AWS-Wiederherstellung möglich ist.

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

Compliance Manager GRC überwacht die Umsetzung von Kontrollmaßnahmen und erstellt Compliance-Nachweise für Kunden mit regulierten AWS-Workloads (HIPAA, PCI DSS, CMMC) sowohl in lokalen als auch in Cloud-Umgebungen.

Kaseya Intelligence 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, 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 Reaktionsphase. Anstatt einen Techniker über einen Befund zu benachrichtigen und auf Maßnahmen zu warten, führt sie folgende Schritte aus: Patches installieren, Systeme isolieren, die Vollständigkeit der Backups überprüfen und das Ergebnis validieren. Für MSPs, die AWS-Umgebungen für mehrere Kunden verwalten, verhindert dieser Ausführungszyklus, dass die Alarmmüdigkeit zu einer Sicherheitslücke wird.

Entdecken Sie Kaseya Intelligence