WISSEN > CLOUD STORAGE > STORAGE ENTSCHEIDUNG DATENBESTAND KOSTEN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Storage-Entscheidungen beginnen nicht beim Storage
Fünf Fragen zu Datenbestand, Kosten, Platzierung, KI-Eignung und Portabilität
Das sollten Sie mitnehmen:
- Cloud-Storage-Kosten bestehen nicht nur aus Kapazität.
Operations, Retrieval, Replikation und Datenübertragung erscheinen je nach Anbieter und Storage Class als eigene Positionen auf der Rechnung.
- Der eigene Datenbestand ist die Voraussetzung jeder Kostenprognose.
Wer nicht weiß, welche Daten existieren und wie sie genutzt werden, kann weder Kosten modellieren noch Placement entscheiden.
- Hybrid und Multicloud sind keine Ziele an sich.
Entscheidend ist, welcher Workload welche Daten an welchem Ort benötigt.
- KI-Infrastruktur beginnt bei den Daten.
Ohne Auffindbarkeit, Klassifizierung und durchgesetzte Berechtigungen löst zusätzliche Kapazität das Problem nicht.
- Portabilität benötigt mehr als eine kompatible API.
Datenvolumen, Bandbreite, Migrationsdauer und Transferkosten bestimmen die tatsächliche Wechselhürde.
Storage-Entscheidungen beginnen nicht beim Storage
Inhaltsverzeichnis
- Wissen wir überhaupt, welche Daten wir speichern?
- Wissen wir, was unsere Daten tatsächlich kosten?
- Liegen die Daten dort, wo sie technisch und wirtschaftlich sinnvoll sind?
- Ist die vorhandene Dateninfrastruktur für KI vorbereitet?
- Wie abhängig ist die Datenarchitektur von einem einzelnen Anbieter?
- Die fünf Fragen hängen voneinander ab
- ASSISTRA-Praxiserfahrung: Die Rechnung beginnt vor der Produktauswahl
- Vier Phasen, in denen die Produktauswahl erst am Ende steht
- Fazit
- Quellen
Cloud Storage wird häufig zunächst über den Preis der gespeicherten Kapazität bewertet, und für eine erste Orientierung ist das nachvollziehbar: Der Wert pro Terabyte ist über Anbieter hinweg vergleichbar und lässt sich in eine Tabelle schreiben. Für eine belastbare Infrastrukturentscheidung reicht diese Betrachtung jedoch nicht aus, weil Datenzugriffe, API-Operationen, Retrieval, Replikation und Datenübertragungen zusätzliche Kosten verursachen können, die erst im laufenden Betrieb sichtbar werden. Gleichzeitig führen KI, wachsende unstrukturierte Datenbestände und hybride IT-Landschaften dazu, dass Unternehmen nicht nur über Storage-Kapazität, sondern über die Platzierung, Nutzung und Beweglichkeit ihrer Daten entscheiden müssen.
Wie relevant diese Fragen inzwischen sind, zeigt der Wasabi Global Cloud Storage Index 2026. Für die vierte Ausgabe der Studie befragte Vanson Bourne im November und Dezember 2025 insgesamt 1.700 IT-Entscheidungsträger aus Organisationen mit mehr als 100 Mitarbeitenden, darunter 500 in der EMEA-Region. Befragt wurden C-Level und Managementebene; die Teilnehmer waren zumindest teilweise am Kaufprozess für Public-Cloud-Storage beteiligt.
Zur Einordnung gehört die Herkunft der Studie. Auftraggeber ist ein Anbieter, dessen Geschäftsmodell ausdrücklich darauf beruht, genau die Gebührenarten zu vermeiden, deren Höhe die Untersuchung belegt. Die Erhebung selbst wurde von einem unabhängigen Marktforschungsinstitut durchgeführt und richtet sich nicht an Kunden des Auftraggebers, das Erkenntnisinteresse ist jedoch nicht neutral. Wir verwenden die Ergebnisse deshalb als Momentaufnahme von Prioritäten und Problemwahrnehmungen, nicht als Beleg für die Überlegenheit einer bestimmten Architektur. Hinzu kommt, dass alle Angaben auf Selbsteinschätzungen der Befragten beruhen und nicht auf einer Auswertung realer Abrechnungsdaten; sie beschreiben, wie Entscheider ihre Kostenstruktur wahrnehmen, was für die Budgetplanung relevant, aber nicht mit einer Messung gleichzusetzen ist.
Unter diesem Vorbehalt sind die Ergebnisse deutlich. Die EMEA-Befragten ordneten durchschnittlich 49 Prozent ihrer Public-Cloud-Storage-Rechnung Gebühren und 50 Prozent der eigentlichen Speicherkapazität zu; die Differenz zu 100 Prozent ergibt sich aus der Rundung der Einzelangaben. Weltweit nennt die Studie einen Gebührenanteil von 50 Prozent, der sich über vier Erhebungen hinweg kaum verändert hat. 45 Prozent der EMEA-Unternehmen gaben an, ihr Cloud-Storage-Budget 2025 überschritten zu haben. Gleichzeitig nutzen 78 Prozent mehr als einen Public-Cloud-Anbieter für Object Storage, während 67 Prozent ihre KI-Workflows mit einer Kombination aus On-Premises- und Public-Cloud-Storage unterstützen.
Auch andere Untersuchungen zeigen eine zunehmend hybride Landschaft. Im State of the Cloud Report 2026 von Flexera verwenden 73 Prozent der mehr als 750 Befragten Hybrid Cloud. Multi-Cloud kommt auf 88 Prozent, wobei sich beide Werte überschneiden: Nur 14 Prozent der Organisationen arbeiten ausschließlich mit mehreren Public Clouds ohne Private Cloud. Flexera weist außerdem darauf hin, dass Multi-Cloud nicht zwingend das Ergebnis einer bewusst geplanten Architektur ist, sondern auch aus Übernahmen, organisatorischen Silos oder historisch gewachsenen Anwendungslandschaften entstehen kann. Für die Infrastrukturplanung ist dieser Unterschied erheblich, denn eine gewachsene Multi-Cloud-Landschaft bringt selten die Vorteile mit, die eine geplante mitbringen würde, wohl aber deren Komplexität.
Für eine Infrastrukturentscheidung folgt daraus weder „mehr Cloud" noch „zurück ins Rechenzentrum". Entscheidend sind andere Fragen: Welche Daten besitzen wir? Was kostet ihre Nutzung tatsächlich? Wo sollten sie liegen? Wie werden sie für KI nutzbar? Und wie einfach können wir diese Entscheidung später wieder ändern?
Wissen wir überhaupt, welche Daten wir speichern?
Eine der auffälligsten Aussagen des Wasabi Index betrifft sogenannte Dark Data. Wasabi definiert darunter Daten, die ein Unternehmen sammelt, aber nicht für Analysen, Entscheidungen, Kundennutzen, Compliance oder andere strategische Zwecke verwendet, und nennt als Beispiele unter anderem Logs sowie Anruf-, Chat-, E-Mail-, Video- und Dokumentenarchive. Die Mehrheit der EMEA-Befragten schätzt, dass zwischen 25 und 74 Prozent ihrer Speicherkapazität nicht analysiert beziehungsweise nicht ausreichend genutzt werden oder aus solchen Dark Data bestehen, und 91 Prozent bewerten eine bessere Analyse und Operationalisierung dieser Daten als Priorität.
Der Begriff sollte allerdings nicht mit „nutzlose Daten" gleichgesetzt werden. Dass Daten aktuell nicht ausgewertet werden, sagt weder etwas über ihre geschäftliche Bedeutung noch über Aufbewahrungspflichten, Schutzbedarf oder ihren möglichen zukünftigen Wert aus. Die Spannweite von 25 bis 74 Prozent ist außerdem so breit, dass sie weniger eine Messgröße als ein Eingeständnis beschreibt: Die Befragten wissen selbst nicht genau, wie hoch der Anteil ist. Genau darin liegt das eigentliche Problem, denn ein Datenbestand, dessen Zusammensetzung nur geschätzt werden kann, entzieht sich jeder nachgelagerten Planung.
Für eine technische Bestandsaufnahme sind deshalb präzisere Fragen erforderlich. Welche Daten existieren, wo befinden sie sich und wem gehören sie? Wann wurden sie zuletzt verwendet und welche Anwendungen greifen darauf zu? Welche Aufbewahrungspflichten bestehen, welche Daten sindredundant, welche müssen geschützt werden? Und schließlich: Welche Daten können archiviert oder gelöscht werden, und welche könnten für neue Analytics- oder KI-Anwendungen relevant werden? Diese Fragen lassen sich in vielen Umgebungen weitgehend automatisiert beantworten, weil Dateisysteme und Object Stores Alter, Größe, Zugriffszeitpunkt und Eigentümer ohnehin führen. Der Aufwand liegt weniger in der Erhebung als in der Interpretation, denn erst die fachliche Bewertung entscheidet, ob ein seit drei Jahren unberührter Datenbestand ein Archivkandidat oder ein aufbewahrungspflichtiger Nachweis ist.
[BILD: Lifecycle-Entscheidungen nach der Bestandsanalyse — Keep, Protect, Archive, Migrate, Classify, Make AI-ready, Delete als gleichrangige Ergebnisse einer vorgelagerten Bewertung, nicht als Abfolge]
Damit verändert sich auch die Betrachtung einer Storage-Migration. Das Ziel sollte nicht automatisch darin bestehen, den kompletten vorhandenen Datenbestand unverändert auf eine neue Plattform zu kopieren, denn jede nicht hinterfragte Migration überträgt die Kostenstruktur des Altbestands unverändert in die neue Umgebung. Eine vorgelagerte Analyse klärt zunächst, welche Daten tatsächlich migriert werden müssen und welche anderen Lifecycle-Entscheidungen sinnvoll sind. In der Praxis reduziert das nicht nur das zu bewegende Volumen, sondern verkürzt auch das Migrationsfenster und damit die Phase, in der zwei Umgebungen parallel betrieben und bezahlt werden.
[QUERVERWEIS: NAS-Migration — Analyse und Bereinigung des Datenbestands vor der eigentlichen Migration]
Wissen wir, was unsere Daten tatsächlich kosten?
Der Preis pro TB oder GB ist eine leicht vergleichbare Kennzahl, bildet die tatsächlichen Kosten eines Cloud-Storage-Workloads jedoch nicht zwingend vollständig ab. Das lässt sich direkt anhand der Preismodelle großer Cloud-Anbieter nachvollziehen. Amazon S3 unterscheidet Kosten für gespeicherte Kapazität, Requests und Datenabrufe, Datenübertragung einschließlich Transfer Acceleration, Datenmanagement- und Analysefunktionen, Replikation sowie Transformations- und Abfragefunktionen. Google Cloud Storage gliedert seine Kosten in Datenspeicherung, Datenverarbeitung einschließlich Operations, Retrieval und Inter-Region-Replikation, Netzwerknutzung sowie die optionale Caching-Schicht Anywhere Cache.
Damit wird die technische Nutzung selbst zu einer Kostengröße. Zwei Datenbestände gleicher Größe können unterschiedliche Gesamtkosten verursachen, wenn die Anzahl der Operationen, die Zugriffshäufigkeit, die Speicherklasse, die Datenbewegungen oder die Replikationsanforderungen voneinander abweichen. Besonders deutlich wird das bei den kostengünstigeren Speicherklassen: Sie senken den Kapazitätspreis, verlagern die Kosten aber auf Retrieval und Mindestspeicherdauer. Ein Datenbestand, der in eine Archivklasse verschoben und anschließend häufiger als erwartet gelesen wird, kann in Summe teurer werden als derselbe Bestand in der Standardklasse. Die Entscheidung über die Speicherklasse ist damit keine Preisentscheidung, sondern eine Aussage über das erwartete Zugriffsmuster — und sie ist nur so gut wie die Kenntnis dieses Musters.
Der Wasabi Cloud Storage Index zeigt, warum dies für die Budgetplanung relevant ist. Von den EMEA-Unternehmen, die 2025 ihr Budget überschritten hatten, nannten 88 Prozent Gebühren als einen der Gründe; weltweit liegt dieser Wert bei 91 Prozent. Zu den genannten Faktoren gehörten unter anderem höher als erwartete Datenverarbeitungs-, API-, Retrieval- und Datenausgangskosten. Bemerkenswert ist dabei weniger die Höhe der Gebühren als ihre Unvorhersehbarkeit: Es handelt sich um Positionen, die nicht aus dem Bestand folgen, sondern aus dem Verhalten von Anwendungen und Nutzern, und die deshalb im Voraus schwerer zu modellieren sind als die Kapazität.
[BILD: Kostenstruktur einer Cloud-Storage-Rechnung — Kapazität, Wachstum, Speicherklasse, Zugriffsmuster, API-Operationen, Retrieval, Datenbewegung, Replikation und Protection als parallele Positionen gegenüber der einzelnen Kennzahl €/TB]
Dabei reicht es nicht, eine aktuelle Rechnung zu analysieren, denn sie beschreibt einen Zustand und keine Entwicklung. Die Kosten müssen auch unter der erwarteten Veränderung des Workloads betrachtet werden. Die FinOps Foundation beschreibt Forecasting entsprechend als Modellierung zukünftiger Kosten und Werte unter Einbeziehung historischer Ausgaben, geplanter Änderungen und weiterer Metriken. Unit Economics bezeichnet im FinOps Framework die Entwicklung und Verfolgung von Metriken, mit denen sich bewerten lässt, wie Nutzung und Verwaltungspraxis den Wert von Produkten, Services oder Abläufen beeinflussen, beispielsweise als Kosten pro GB, Workload, Service Request oder Transaktion. Mit der Fassung 2026 hat das Framework seinen Anwendungsbereich zudem von reinen Cloud-Ausgaben auf weitere Technologiekategorien ausgeweitet. Für Storage bedeutet das, nicht nur Werte pro Terabyte zu vergleichen, sondern die Kosten des tatsächlichen Daten- und Zugriffspfades über den geplanten Nutzungszeitraum.
[QUERVERWEIS: TCO-Artikel — vollständige Kostenbetrachtung über den Nutzungszeitraum statt Anschaffungspreis]
Liegen die Daten dort, wo sie technisch und wirtschaftlich sinnvoll sind?
Die zunehmende Nutzung hybrider und verteilter Infrastrukturen bedeutet nicht automatisch, dass Daten beliebig zwischen ihnen verteilt werden sollten. Im Wasabi Index nennen die Befragten als Gründe für Multicloud unter anderem unterschiedliche Leistungsoptionen, Anforderungen an die Anwendungsverfügbarkeit und die Verringerung von Risiken durch Anbieterabhängigkeit, und 67 Prozent der EMEA-Unternehmen geben an, Hybrid Storage für KI-Workflows einzusetzen. Daraus lässt sich jedoch nicht ableiten, dass Hybrid oder Multicloud einer rein lokalen oder rein cloudbasierten Architektur grundsätzlich überlegen wäre. Verbreitung ist keine Eignung.
Die relevante Architekturfrage lautet, welcher Workload welche Daten an welchem Ort benötigt. Ein selten verwendetes Archiv besitzt andere Anforderungen als ein produktiver Fileservice, Backup-Daten unterscheiden sich von Trainingsdaten für Machine Learning, und ein weltweit genutzter Dateibestand stellt andere Anforderungen an Datenlokalität und Zugriff als ein lokaler Applikationsdatensatz. Eine Data-Placement-Entscheidung sollte daher mindestens Zugriffshäufigkeit, Datenvolumen, Performanceanforderungen, Datenlokalität, Schutzanforderungen, Anwendungen, Netzwerkverbindungen und Kosten der Datenbewegung berücksichtigen.
Zwei Effekte werden dabei regelmäßig unterschätzt. Der erste ist die Asymmetrie der Datenbewegung: Der Weg in die Cloud ist bei den großen Anbietern in der Regel kostenfrei, der Weg heraus nicht. Eine Platzierungsentscheidung ist deshalb ökonomisch keine symmetrische Wahl zwischen zwei Orten, sondern eine Bewegung, deren Rückweg gesondert bepreist ist. Der zweite Effekt ist die Anziehungskraft, die ein hinreichend großer Datenbestand auf die zugehörige Verarbeitung ausübt. Sobald Daten eine bestimmte Größe erreichen, ist es günstiger und schneller, die Verarbeitung dorthin zu verlagern, wo die Daten liegen, als umgekehrt. Wer den Ort der Daten festlegt, entscheidet damit implizit auch über den Ort künftiger Verarbeitung — und über die Frage, wie frei diese Entscheidung später noch ist.
Hinzu kommen Anforderungen, die sich nicht aus Technik oder Kosten ergeben. Regulatorische Vorgaben, vertragliche Zusagen gegenüber Kunden und Anforderungen an die Verfügbarkeit im Störungsfall können die Menge zulässiger Orte erheblich einschränken, bevor überhaupt über Performance gesprochen wird. Data Placement ist damit keine reine Storage-Entscheidung, sondern eine Entscheidung über den gesamten Datenpfad und über die Freiheitsgrade, die einer Organisation danach noch bleiben.
[QUERVERWEIS: Hybrid Cloud Storage — Pfade und Performance planen]
[QUERVERWEIS: Object Storage Datenplattform — Einordnung von Object Storage als Plattformschicht statt als Archivziel]
Ist die vorhandene Dateninfrastruktur für KI vorbereitet?
Die zunehmende Nutzung hybrider und verteilter Infrastrukturen bedeutet nicht automatisch, dass Daten beliebig zwischen ihnen verteilt werden sollten. Im Wasabi Index nennen die Befragten als Gründe für Multicloud unter anderem unterschiedliche Leistungsoptionen, Anforderungen an die Anwendungsverfügbarkeit und die Verringerung von Risiken durch Anbieterabhängigkeit, und 67 Prozent der EMEA-Unternehmen geben an, Hybrid Storage für KI-Workflows einzusetzen. Daraus lässt sich jedoch nicht ableiten, dass Hybrid oder Multicloud einer rein lokalen oder rein cloudbasierten Architektur grundsätzlich überlegen wäre. Verbreitung ist keine Eignung.
Die relevante Architekturfrage lautet, welcher Workload welche Daten an welchem Ort benötigt. Ein selten verwendetes Archiv besitzt andere Anforderungen als ein produktiver Fileservice, Backup-Daten unterscheiden sich von Trainingsdaten für Machine Learning, und ein weltweit genutzter Dateibestand stellt andere Anforderungen an Datenlokalität und Zugriff als ein lokaler Applikationsdatensatz. Eine Data-Placement-Entscheidung sollte daher mindestens Zugriffshäufigkeit, Datenvolumen, Performanceanforderungen, Datenlokalität, Schutzanforderungen, Anwendungen, Netzwerkverbindungen und Kosten der Datenbewegung berücksichtigen.
Zwei Effekte werden dabei regelmäßig unterschätzt. Der erste ist die Asymmetrie der Datenbewegung: Der Weg in die Cloud ist bei den großen Anbietern in der Regel kostenfrei, der Weg heraus nicht. Eine Platzierungsentscheidung ist deshalb ökonomisch keine symmetrische Wahl zwischen zwei Orten, sondern eine Bewegung, deren Rückweg gesondert bepreist ist. Der zweite Effekt ist die Anziehungskraft, die ein hinreichend großer Datenbestand auf die zugehörige Verarbeitung ausübt. Sobald Daten eine bestimmte Größe erreichen, ist es günstiger und schneller, die Verarbeitung dorthin zu verlagern, wo die Daten liegen, als umgekehrt. Wer den Ort der Daten festlegt, entscheidet damit implizit auch über den Ort künftiger Verarbeitung — und über die Frage, wie frei diese Entscheidung später noch ist.
Hinzu kommen Anforderungen, die sich nicht aus Technik oder Kosten ergeben. Regulatorische Vorgaben, vertragliche Zusagen gegenüber Kunden und Anforderungen an die Verfügbarkeit im Störungsfall können die Menge zulässiger Orte erheblich einschränken, bevor überhaupt über Performance gesprochen wird. Data Placement ist damit keine reine Storage-Entscheidung, sondern eine Entscheidung über den gesamten Datenpfad und über die Freiheitsgrade, die einer Organisation danach noch bleiben.
[QUERVERWEIS: Hybrid Cloud Storage — Pfade und Performance planen]
[QUERVERWEIS: Object Storage Datenplattform — Einordnung von Object Storage als Plattformschicht statt als Archivziel]
Wie abhängig ist die Datenarchitektur von einem einzelnen Anbieter?
44 Prozent der im Wasabi Index befragten EMEA-Unternehmen mit Multicloud nennen die Reduzierung von Risiken im Zusammenhang mit Anbieterabhängigkeit als einen der drei häufigsten Gründe für die Einführung von Multicloud. Der Report nennt außerdem die Unterstützung der S3 API als relevantes Merkmal für Offenheit und Interoperabilität von Cloud Object Storage. API-Kompatibilität allein garantiert jedoch noch keine vollständige Portabilität eines Workloads.
Eine Anwendung kann zusätzliche Dienste, bestimmte Storage Classes, Identitäts- und Berechtigungsmodelle, Lifecycle-Funktionen oder andere anbieterspezifische Komponenten verwenden. Die reine Objektschnittstelle ist dabei meist der am wenigsten problematische Teil. Schwieriger wird es bei allem, was um das Objekt herum liegt: benutzerdefinierte Metadaten, Versionierung, Aufbewahrungs- und Unveränderlichkeitsmechanismen, Verschlüsselungsschlüssel und deren Verwaltung, Ereignisbenachrichtigungen an nachgelagerte Systeme sowie die Zuordnung von Speicherklassen, die zwischen Anbietern selten deckungsgleich ist. Ein Wechsel, der auf Ebene der Lese- und Schreiboperationen vollständig funktioniert, kann an der Frage scheitern, ob eine gesetzlich geforderte Aufbewahrungssperre auf der Zielplattform in gleicher Weise nachweisbar ist.
Hinzu kommt, dass bei einem Providerwechsel nicht nur die Anwendung kompatibel sein muss — die gespeicherten Daten müssen tatsächlich bewegt werden. Diese Rechnung wird selten aufgemacht, ist aber einfach: Eine Leitung mit 1 Gbit/s überträgt brutto rund 125 Megabyte pro Sekunde, wodurch 500 Terabyte auch ohne Protokoll-Overhead und ohne Parallelnutzung der Leitung etwa 46 Tage benötigen. Bei 10 Gbit/s bleiben immer noch rund viereinhalb Tage. In dieser Zeit ändert sich der Quellbestand weiter, sodass ein Abgleich der Änderungen und ein planbares Umschaltfenster erforderlich werden. Parallel fallen Transfer-, Retrieval- und Operationskosten an, die bei archivierten Beständen deutlich über den laufenden Kapazitätskosten liegen können.
[BILD: Schichten der Portabilität — Anwendung, API und Protokoll, Funktionen und Metadaten, Storage, Netzwerk, Zielplattform; die API-Schicht als einzige, die durch Kompatibilität allein abgedeckt ist]
Eine Architektur kann damit auf API-Ebene portabel erscheinen und trotzdem eine hohe praktische Wechselhürde besitzen. Eine Exit-Strategie gehört deshalb in das Architekturdesign und nicht erst in die Planung eines konkreten Providerwechsels. Praktisch bedeutet das, bereits bei der Einführung festzulegen, welche anbieterspezifischen Funktionen bewusst genutzt werden, welche Daten im Ernstfall bewegt werden müssten, über welche Wege das geschehen könnte und mit welchem Zeitbedarf zu rechnen wäre. Diese Festlegung kostet in der Entwurfsphase wenig und ist später kaum nachzuholen.
[QUERVERWEIS: GFS Plattformvergleich — Bewertung von Plattformen anhand von Protokollen, Funktionen und Betriebsmodell]
Die fünf Fragen hängen voneinander ab
Die einzelnen Fragestellungen lassen sich nicht getrennt beantworten. Ein unbekannter Datenbestand erschwert die Kostenprognose, weil sich weder Zugriffsmuster noch Wachstum belastbar schätzen lassen. Fehlende Klassifizierung erschwert das Data Placement, weil Schutzbedarf und Lokalitätsanforderungen unklar bleiben. Ungeeignetes Data Placement verursacht zusätzliche Datenbewegungen, und Datenbewegungen erzeugen wiederum Kosten und Latenz. Eine Architektur schließlich, aus der sich Daten nur schwer wieder herausbewegen lassen, erhöht die Abhängigkeit von der einmal getroffenen Entscheidung und verteuert jede spätere Korrektur.
Daraus ergibt sich eine andere Reihenfolge als die in Beschaffungsprozessen übliche. Nicht die Auswahl eines Storage-Systems steht am Anfang, sondern die Analyse des Datenbestands, die Bewertung der realen Kostenstruktur, die Entscheidung über Workload und Data Placement, die Prüfung der AI Data Readiness und die Untersuchung von Portabilität und Exit-Szenarien. Die Produktauswahl ist das Ergebnis dieser Untersuchung, nicht ihr Ausgangspunkt.
ASSISTRA-Praxiserfahrung: Die Rechnung beginnt vor der Produktauswahl
Diese Betrachtungsweise entspricht auch unseren Erfahrungen aus ASSISTRA-Projekten. Wir haben bei Kunden bereits unerwartete Cloud-Kosten untersucht und Cloud- und On-Premises-Varianten anhand ihrer Gesamtbetriebskosten miteinander verglichen. Auch die Analyse beziehungsweise teilweise Klassifizierung vorhandener Datenbestände vor Migrationen war Bestandteil von Projekten.
Dabei ist insbesondere die TCO-Betrachtung relevant. Wir vergleichen Storage-Alternativen nicht ausschließlich über Anschaffungspreis oder nominelle Kosten pro TB. Betrachtungszeitraum und relevante Kostenpositionen werden abhängig vom Kundenszenario festgelegt, und entscheidend ist die nutzbare Kapazität sowie die konkrete Funktion der Infrastruktur. Auch Wachstum, Support beziehungsweise End-of-Service und weitere für die jeweilige Architektur tatsächlich relevante Kostenfaktoren müssen berücksichtigt werden.
Das bedeutet gleichzeitig, dass es kein allgemeingültiges TCO-Modell gibt, mit dem Cloud und On-Premises pauschal verglichen werden können. Ein Archiv mit seltenen Zugriffen erzeugt ein anderes Kostenprofil als ein produktiver Datenbestand mit regelmäßigen Reads, Writes und Transfers, und ebenso verändern Wachstum, Redundanzanforderungen, Nutzungsdauer und vorhandene Infrastruktur das Ergebnis. Die Architekturentscheidung folgt deshalb erst aus dem konkreten Kundenszenario.
Vier Phasen, in denen die Produktauswahl erst am Ende steht
ASSESS: Zuerst der Bestand, nicht der Produktkatalog
Am Anfang stehen Datenbestände, Kapazitäten, Wachstum, Zugriffsmuster, bestehende Systeme, Datenbewegungen, Schutzanforderungen und Kosten. Diese Phase liefert keine Architekturempfehlung, sondern die Grundlage, auf der eine solche Empfehlung überhaupt begründbar wird. Ihr Ergebnis ist häufig, dass sich Teile des Bestands anders verhalten als angenommen — etwa weil ein als aktiv geführter Datenbereich seit Jahren nur noch gelesen wird.
DESIGN: Die Platzierung folgt dem Workload
Danach lässt sich entscheiden, welche Daten lokal, in einer Public Cloud, in einem privaten Object Store oder in einer hybriden Architektur liegen sollten und welche File-, Object- oder anderen Zugriffsmöglichkeiten benötigt werden. In dieser Phase werden auch die Abhängigkeiten festgelegt, die später den Aufwand eines Wechsels bestimmen, weshalb Exit-Überlegungen hierher gehören und nicht ans Ende.
DELIVER: Migration ist Folge, nicht Ausgangspunkt
Erst auf dieser Grundlage folgen Konsolidierung, Migration und technische Integration. Die Datenmigration ist damit Folge einer Architekturentscheidung und nicht deren Ausgangspunkt, und ihr Umfang steht bereits fest, bevor das erste Byte bewegt wird.
OPERATE: Kosten bleiben eine bewegliche Größe
Auch nach der Implementierung bleiben Kapazitätsentwicklung, tatsächliche Nutzung, Kosten und Datenbewegungen dynamische Größen. Forecasting und kontinuierliche Kostenkontrolle sind deshalb Bestandteil des Betriebs und nicht eine einmalige Übung im Rahmen der Beschaffung.
Fazit
Der Wasabi Global Cloud Storage Index 2026 zeigt keine technische Überlegenheit einer bestimmten Storage-Architektur, und angesichts des Auftraggebers wäre eine solche Lesart auch nicht angemessen. Er macht jedoch mehrere Probleme sichtbar, die Unternehmen bei Infrastrukturentscheidungen berücksichtigen sollten: Ein erheblicher Teil der Cloud-Storage-Ausgaben der Befragten entfällt nicht auf die reine Kapazität, Budgetüberschreitungen bleiben verbreitet, hybride und Multi-Cloud-Umgebungen sind häufig, und KI erhöht den Druck, vorhandene Daten kontrolliert nutzbar zu machen.
Die Konsequenz sollte nicht darin bestehen, Cloud Storage grundsätzlich infrage zu stellen oder Daten pauschal zurück ins eigene Rechenzentrum zu holen. Ebenso wenig ist Hybrid Cloud automatisch die richtige Antwort. Die zentrale Aufgabe besteht darin, Datenbestand, Zugriffsmuster, Kosten, Datenbewegung, Schutzbedarf und zukünftige Nutzung gemeinsam zu betrachten. Erst dann lässt sich beantworten, welche Daten lokal bleiben sollten, welche von Cloud- oder Object-Storage-Modellen profitieren, welche Daten vor einer Migration zunächst bewertet werden sollten und welche Infrastruktur für zukünftige KI-Anwendungen erforderlich ist.
Die entscheidende Storage-Frage lautet damit nicht mehr nur, wie viele Terabyte gespeichert werden müssen, sondern welche Daten für welchen Zweck an welchem Ort zu welchen Gesamtkosten verfügbar sein müssen.
Quellen
Wasabi Technologies / Vanson Bourne: 2026 Wasabi Global Cloud Storage Index, 2026. Befragung von 1.700 IT-Entscheidungsträgern, November/Dezember 2025. Die in diesem Artikel verwendeten EMEA-Werte stammen aus dem regionalen Kurzbericht (500 Befragte), der öffentlich nicht abrufbar ist; die jeweils genannten globalen Entsprechungen sind über die Pressemitteilung und den Blogbeitrag von Wasabi nachvollziehbar.
Flexera: 2026 State of the Cloud Report, 15. Ausgabe, März 2026. N=753. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
Amazon Web Services: Amazon S3 Pricing. Abruf: 2. September 2026. https://aws.amazon.com/de/s3/pricing/
Google Cloud: Cloud Storage Pricing. Abruf: 2. September 2026. https://cloud.google.com/storage/pricing
FinOps Foundation: FinOps Framework 2026, Domain Planning & Estimating, Capabilities Forecasting und Unit Economics. Abruf: 2. September 2026. https://www.finops.org/framework/
ISO/IEC 42001:2023: Information technology -- Artificial intelligence -- Management system.
National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, Juli 2024. https://doi.org/10.6028/NIST.AI.600-1
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
