Cloud-nativ oder nur „Cloud-Washing“ beim Backup?

Nahezu jeder Backup-Anbieter wirbt heute mit Multi-Cloud-Fähigkeit. Hinter ähnlich klingenden Versprechen verbergen sich jedoch grundverschiedene Architekturen. Besonders problematisch sind Lösungen, bei denen Kunden virtuelle Appliances in Amazon Web Services (AWS) oder Microsoft Azure bereitstellen, Kapazitäten vorab dimensionieren und auch ungenutzte Ressourcen bezahlen. HYCU bezeichnet dieses Modell als „Cloud-Washing“: Nicht das Produkt wurde grundlegend modernisiert, sondern vor allem seine Vermarktung.

Fünf Merkmale einer Cloud-nativen Architektur

Cloud-Nativität beschreibt keine Hosting-Variante, sondern die technische Konstruktion einer Lösung. Sie beeinflusst Skalierbarkeit, Betriebskosten und die Fähigkeit, Daten nach einem Ausfall tatsächlich wiederherzustellen. HYCU nennt fünf zentrale Merkmale:

• Elastische Skalierung: Neue virtuelle Maschinen (VM) werden über Programmierschnittstellen (API) automatisch erkannt und geschützt. Stillgelegte Systeme verursachen keine weitere Backup-Last. Feste Kapazitätsgrenzen und erneute Beschaffungszyklen entfallen.
• Nutzung nativer Cloud-Dienste: Snapshots, Identity and Access Management (IAM), Objektspeicher und Marktplätze der jeweiligen Cloud bilden die technischen Grundbausteine. Eine proprietäre Zwischenschicht soll Funktionen nicht nachbauen, die bereits vorhanden sind.
• Verbrauchsabhängige Abrechnung: Beim „Pay-as-you-protect“-Modell richten sich die Kosten nach tatsächlich geschützten Quelldaten und der Sicherungshäufigkeit – nicht nach vorsorglich reservierter Maximalkapazität.
• Keine zusätzliche Infrastruktur: Unternehmen müssen weder Backup-Appliances noch Agenten oder proprietäre Speichersysteme bereitstellen und dimensionieren.
• Cloud-übergreifende Wiederherstellung: Ein in AWS erstelltes Backup lässt sich beispielsweise in der Google Cloud Platform (GCP) wiederherstellen. Derselbe Mechanismus unterstützt damit auch Migrationen.

Wo Cloud-Washing Kosten verursacht

Drei wiederkehrende Muster treiben die Total Cost of Ownership (TCO) nach oben:

• Überprovisionierung: Eine Appliance wird für künftige Lastspitzen ausgelegt, obwohl sie über Jahre möglicherweise nur zu 30 Prozent ausgelastet ist. Bezahlt werden dennoch 100 Prozent der reservierten Kapazität.
• Versteckte Cloud-Kosten: Ausgehender Datenverkehr, regionsübergreifende Replikation oder API-Aufrufe erscheinen zusätzlich auf der Rechnung des Cloud-Anbieters. Neben dem Softwarepreis entstehen dadurch schwer kalkulierbare Betriebskosten.
• Zusätzlicher Migrationsaufwand: Funktioniert das Backup-Werkzeug nur innerhalb einer Cloud, wird jeder Anbieterwechsel zum separaten Projekt mit eigenem Werkzeug, Budget und Zeitplan.

Multi-Cloud ist längst betriebliche Realität

Die „State of the Cloud“-Studie von Flexera beschreibt Hybrid- und Multi-Cloud-Umgebungen inzwischen als Normalfall. Unternehmen nutzten 2025 durchschnittlich 2,4 Public-Cloud-Anbieter, 70 Prozent betrieben zugleich Public- und Private-Cloud-Infrastrukturen. Hinzu kommen lokale Systeme und zahlreiche Software-as-a-Service-Angebote (SaaS).

Eine Sicherungsstrategie, die nur AWS oder ausschließlich Infrastructure as a Service (IaaS) abdeckt, greift deshalb zu kurz. Das gilt umso mehr, als komplexe Hybridumgebungen Wiederherstellung und Incident Response erschweren können. Laut IBMs „Cost of a Data Breach Report 2024“ lagen die weltweiten Durchschnittskosten einer Datenpanne bei 4,88 Millionen US-Dollar. Betriebsunterbrechungen, entgangene Geschäfte und langwierige Wiederherstellungen gehörten zu den wesentlichen Kostentreibern.

Welche Systeme abgedeckt sein müssen

Eine umfassende Multi-Cloud-Plattform sollte folgende Umgebungen und Workloads schützen:

• AWS: EC2, EBS, RDS, S3, EFS und FSx mit nativen Snapshots und IAM-Integration
• Microsoft Azure: Azure VMs, Managed Disks, Azure SQL, Azure Kubernetes Service (AKS), Blob Storage, Files, Microsoft 365 und Entra ID
• Google Cloud: Compute Engine, Persistent Disks, Cloud SQL, BigQuery, Google Kubernetes Engine (GKE), Google Cloud Storage (GCS) und Filestore
• On-Premises und Private Cloud: Nutanix AHV, ESXi auf Nutanix, VMware, Dell PowerProtect Data Domain, NetApp ONTAP sowie physische Windows- und Linux-Systeme
• Containerisierte Workloads: Elastic Kubernetes Service (EKS), AKS, GKE und lokale Kubernetes-Distributionen
• SaaS-Anwendungen: Microsoft 365, Google Workspace, Salesforce, Atlassian Cloud, GitHub, Okta, Box und Dynamics 365
• Enterprise-Anwendungen: SQL Server, Oracle, SAP HANA und Exchange mit anwendungskonsistenter Datensicherung

Drei Fragen entlarven schwache Angebote

Unternehmen können die Architektur eines Anbieters mit drei Prüfungen bewerten:

• Was muss bereitgestellt werden? Virtuelle Appliances pro Cloud, feste Kapazitätsgrenzen oder langfristige Terabyte-Verpflichtungen sprechen für eine lediglich Cloud-gehostete Architektur.
• Wie wird abgerechnet? Vorab reservierte Kapazitäten folgen dem Appliance-Modell. Cloud-native Angebote berechnen die tatsächlich geschützten Quelldaten.
• Wie funktioniert eine Cloud-übergreifende Migration? Der Anbieter sollte demonstrieren können, wie eine in AWS gesicherte Workload direkt in GCP wiederhergestellt wird. Sind Export, Reimport und zusätzliche Dienstleistungen erforderlich, bleibt das Multi-Cloud-Versprechen eingeschränkt.

Datenhoheit bleibt beim Kunden

Eine Multi-Cloud-Plattform sollte die Cloud-Strategie des Unternehmens unterstützen, nicht begrenzen. Backups verbleiben in den Konten und Regionen des Kunden, die Schlüssel bleiben unter seiner Kontrolle. Damit wird der Backup-Anbieter weder zum zentralen Ausfallpunkt noch zum technischen Abhängigkeitsfaktor.

Auch Compliance lässt sich regional durchsetzen: Müssen Daten nach der Datenschutz-Grundverordnung (DSGVO) innerhalb der Europäischen Union verbleiben, wird dies in der Backup-Konfiguration festgelegt. Der Datenausgang bei einer Wiederherstellung in eine andere Cloud verursacht zwar Kosten, fällt jedoch nur dann an, wenn eine solche Wiederherstellung tatsächlich notwendig wird.

Unternehmen sollten deshalb jede Workload erfassen: Wo läuft sie, welches Werkzeug sichert sie und wie würde eine Wiederherstellung konkret funktionieren? Eine solche Bestandsaufnahme legt häufig Systeme offen, die formal erfasst, praktisch aber nicht vollständig geschützt sind. Genau diese Lücken muss eine belastbare Multi-Cloud-Backup-Strategie schließen.