WISSEN > ENTERPRISE STORAGE > STORAGE TCO VERGLEICH
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Storage TCO Vergleich
Wie sich Speicherkosten belastbar bewerten lassen
Das sollten Sie mitnehmen:
- Ein TCO-Vergleich beginnt nicht mit Preisen, sondern mit der technischen Vergleichsbasis.
Ohne identische Definition von Kapazität, Redundanz, Wachstum und Betrachtungszeitraum vergleicht die Rechnung zwei unterschiedliche Systeme. - Der Preis pro Raw-Terabyte ist als Kennzahl untauglich.
Maßgeblich ist die für die Anforderung benötigte Usable Capacity und die Infrastruktur, die zu ihrer Bereitstellung erforderlich ist. - Nicht jede Kostenposition gehört monetarisiert.
Administration, spätere Migrationen und Lifecycle-Risiken sind entscheidungsrelevant, ohne dass ihnen ohne belastbare Daten ein Eurobetrag zugeordnet werden kann. - Energie ist eine der wenigen Betriebskostenpositionen, die sich über mehrere Jahre belastbar rechnen lässt.
Die dafür verbreitete Kennzahl PUE misst allerdings nicht den Verbrauch, sondern ein Verhältnis. - Der Vergleich einer Kaufentscheidung mit einem Verbrauchs- oder Subscription-Modell ist selbst ein Symmetrieproblem.
Er erfordert eine explizite Behandlung der zeitlichen Kostenverteilung. - Der Qualitätsmaßstab eines TCO-Modells ist nicht seine Komplexität, sondern seine Überprüfbarkeit.
Der Kunde muss die Annahmen durch eigene Zahlen ersetzen und das Ergebnis nachrechnen können.
TCO von Storage-Systemen
Inhaltsverzeichnis
- Was bedeutet TCO bei einem Storage-System?
- Warum der Preis pro Raw-Terabyte wenig aussagt
- Redundanz gehört in die Kapazitätsrechnung
- Wachstum und Betrachtungszeitraum
- Welche Kosten sollten berücksichtigt werden?
- Energie: eine belastbare Position mit einer irreführenden Kennzahl
- Cloud- und Subscription-Modelle im Vergleich
- Warum nicht jeder Faktor einen Eurobetrag bekommen sollte
- Unser Vorgehensmodell: das Modell muss reproduzierbar sein
- Sensitivität und Ergebnisdarstellung
- Performance ist eine Vorbedingung, keine Kostenposition
- Typische Fehler bei Storage-TCO-Vergleichen
- Fazit
- Quellen
Der Anschaffungspreis eines Storage-Systems sagt wenig darüber aus, welche Kosten die Plattform über ihre tatsächliche Nutzungsdauer verursacht. Noch problematischer wird ein Vergleich über einen einfachen Preis pro Terabyte: Zwei Systeme mit nominell gleicher Kapazität können aufgrund von Redundanz, Reservekapazitäten, Replikation und unterschiedlichen Ausbaukonzepten eine deutlich unterschiedliche nutzbare Kapazität bereitstellen.
Ein belastbarer TCO-Vergleich muss deshalb zuerst die technische Vergleichsbasis herstellen und erst danach die Kosten gegenüberstellen.
Die Storage Networking Industry Association (SNIA) weist in ihrem TCO-Modell für Storage ausdrücklich darauf hin, dass Geschäftsziele und Beschaffungskriterien zwischen Kunden erheblich variieren und ein universelles TCO-Modell deshalb nicht für alle Storage-Workloads angemessen ist. Für die Praxis folgt daraus eine wichtige Konsequenz: Ein TCO-Modell wird nicht dadurch besser, dass möglichst viele Kostenpositionen mit einem Geldbetrag versehen werden. Entscheidend ist, dass die relevanten Kosten auf derselben technischen Grundlage berechnet werden, dass die Annahmen nachvollziehbar sind und dass nicht belastbar quantifizierbare Faktoren als solche erkennbar bleiben.
Was bedeutet TCO bei einem Storage-System?
Total Cost of Ownership betrachtet nicht nur den Kaufpreis, sondern die Kosten einer Infrastruktur über einen definierten Zeitraum.
Die SNIA unterscheidet in ihrem Storage-TCO-Modell zwischen Capital Expenditures und Operational Expenditures. Auf der CapEx-Seite betrachtet das Modell nicht nur den Storage selbst, sondern die übrigen Komponenten eines typischen Rechenzentrums-Racks. Die Betriebskosten werden im Modell von Strom, Kühlung und den Kosten von Geräteausfällen dominiert. Die CapEx des Rechenzentrums selbst geht als konstanter Eingabewert in Form eines jährlichen Rack-Preises ein.
Eine Einschränkung des Modells ist für Beschaffungsentscheidungen wichtig: Softwarelizenzkosten sind darin ausdrücklich nicht enthalten. Die SNIA weist darauf hin, dass sie sich bei Bedarf über die statischen Felder der Rack-Konfiguration ergänzen lassen. Wer das SNIA-Modell als Referenz heranzieht, übernimmt also keine vollständige Kostenaufstellung für einen Enterprise-Beschaffungsvergleich, sondern ein methodisches Gerüst, das um die im konkreten Fall relevanten Positionen erweitert werden muss.
Für einen konkreten Beschaffungsvergleich muss deshalb zunächst definiert werden, welche Kosten für die jeweilige Entscheidung relevant und mit ausreichender Genauigkeit bestimmbar sind. Daraus folgt eine grundlegende Regel: Bevor zwei TCO-Werte miteinander verglichen werden, müssen Systemgrenze, Betrachtungszeitraum und technische Bezugsgröße identisch definiert sein.
Ein Vergleich über drei Jahre kann zu einem anderen Ergebnis führen als ein Vergleich über fünf Jahre. Gleiches gilt, wenn ein Angebot lediglich die anfänglich benötigte Kapazität enthält, während ein anderes bereits erwartetes Wachstum berücksichtigt.
Warum der Preis pro Raw-Terabyte wenig aussagt
Eine der wichtigsten Voraussetzungen für einen Storage-Kostenvergleich ist eine einheitliche Kapazitätsdefinition.
Die SNIA definiert Raw Capacity als die gesamte adressierbare Kapazität der Storage Devices eines Storage-Systems. UsableCapacity führt das SNIA Dictionary als Synonym für Formatted Capacity, also für die Menge an Bytes, die nach der Formatierung eines Systems oder Geräts geschrieben werden kann. Entscheidend ist die dort ausdrücklich genannte Abgrenzung: Formatted Capacity ist kleiner oder gleich der Raw Capacity und enthält keine Bereiche, die für Systemnutzung, Spares, RAID-Parity, Checksummen, Remapping auf Host- oder Dateisystemebene, das Right Sizing von Disks oder die Laufwerkskennzeichnung reserviert sind.
Damit wird das Problem einfacher Preisvergleiche unmittelbar sichtbar. Angenommen, zwei Systeme besitzen jeweils 500 TB Raw Capacity. Daraus folgt noch nicht, dass beide dieselbe Datenmenge aufnehmen können. RAID-Verfahren, Spare- beziehungsweise Rebuild-Kapazitäten und weitere interne Reservierungen verändern die tatsächlich verfügbare Kapazität, und zwar architekturabhängig unterschiedlich stark.
Für einen TCO-Vergleich sollte deshalb nicht die installierte Raw Capacity die zentrale Bezugsgröße sein, sondern die für die jeweilige Anforderung benötigte Usable Capacity.
Raw, Usable und Effective Capacity nicht vermischen
Zusätzlich muss zwischen physischer Nutzkapazität und den Effekten von Data Reduction unterschieden werden.
Kompression, Deduplizierung und Thin Provisioning verändern den physischen Kapazitätsbedarf. Das SNIA Dictionary führt sie zusammen mit Delta Snapshots als Capacity Optimization Methods, also als Verfahren, die den zur Speicherung eines Datenbestands erforderlichen Platzbedarf reduzieren. Bemerkenswert ist, dass die SNIA auch RAID 5 und RAID 6 in diese Kategorie einordnet, weil sie für dieselbe Schutzfunktion weniger Platz benötigen als reines Mirroring. Redundanzverfahren sind also nicht einfach das Gegenteil von Kapazitätsoptimierung — sie unterscheiden sich lediglich in ihrer Effizienz. Für die Vergleichsrechnung heißt das: Auch die Wahl des Schutzverfahrens gehört zur Kapazitätsdefinition und nicht in eine nachgelagerte Bewertung.
Das TCO-Modell der SNIA arbeitet darüber hinaus mit einer Effective Capacity, abgekürzt TBe. Gemeint ist der tatsächlich nutzbare Speicherplatz nach Replikation, Kapazitätsauslastung und Data Reduction. Die SNIA merkt dazu ausdrücklich an, dass es bei Enterprise-Storage- und All-Flash-Systemen verbreitete Praxis ist, für Angaben zu Kosten pro Terabyte die Effective Capacity heranzuziehen.
Genau darin liegt das Risiko. Ein System auf Basis seiner Usable Capacity mit einem anderen System auf Basis einer angenommenen Effective Capacity zu vergleichen, erzeugt keine belastbare Kostenaussage. Bei Herstellerangeboten muss deshalb geprüft werden, auf welche Kapazitätsdefinition sich eine Angabe wie „Kosten pro TB" tatsächlich bezieht.
Das gilt besonders dann, wenn für Data Reduction pauschale Faktoren angesetzt werden. Ob Kompression oder Deduplizierungden angenommenen Effekt erzielt, hängt vom konkreten Datenbestand ab. Wir setzen deshalb in Vergleichsrechnungen keine Reduktionsfaktoren an, die nicht aus dem tatsächlichen Datenbestand des Kunden abgeleitet oder zumindest an vergleichbaren Beständen beobachtet worden sind.
[BILD: Schema Raw → Usable → Effective Capacity mit den jeweils dazwischenliegenden Abzügen und Aufschlägen]
Redundanz gehört in die Kapazitätsrechnung
Die benötigte Nutzkapazität allein beschreibt noch nicht die tatsächlich zu beschaffende Infrastruktur.
Ein Storage-System muss die geforderte Usable Capacity unter den festgelegten Anforderungen an Datenverfügbarkeit und Redundanz bereitstellen. Die dafür benötigte physische Kapazität hängt von der Architektur ab. Das betrifft zunächst die systeminterne Absicherung, etwa durch Mirroring oder Parity-basierte RAID-Verfahren. Hinzu können weitere Kopien oder eine Replikation auf ein zweites System oder einen zweiten Standort kommen.
Die Ausgangsfrage einer Beschaffung sollte deshalb nicht lauten, wie viel ein Petabyte Storage kostet. Sie sollte lauten, welche Infrastruktur die verglichenen Lösungen jeweils benötigen, um ein Petabyte Usable Capacity mit den geforderten Redundanz- und Verfügbarkeitseigenschaften bereitzustellen. Erst wenn diese Frage für beide Architekturen beantwortet ist, besitzen die daraus errechneten Kosten eine gemeinsame technische Grundlage.
Ausführlicher behandeln wir die architektonischen Unterschiede zwischen Replikations- und Erasure-Coding-Verfahren im Beitrag [QUERVERWEIS: Objektspeicher als Datenplattform, URL folgt].
Wachstum und Betrachtungszeitraum
Storage wird selten für einen über mehrere Jahre konstanten Datenbestand beschafft. Wächst ein Bestand jährlich um einen konstanten Prozentsatz, entwickelt sich die benötigte Kapazität exponentiell, nicht linear. Bei einer Ausgangskapazität von 500 TB und einem angenommenen jährlichen Wachstum von 20 Prozent liegt der Bedarf nach einem Jahr bei 600 TB, nach drei Jahren bei rund 864 TB und nach fünf Jahren bei etwa 1.244 TB — also beim Zweieinhalbfachen des Ausgangswerts.
Die Zahlen sind ein Rechenbeispiel. Entscheidend ist der Effekt: Schon moderate Wachstumsannahmen verändern die benötigte Kapazität über einen mehrjährigen Zeitraum erheblich. Das Wachstum muss deshalb in beide verglichenen Systeme mit derselben Annahme einfließen.
Anschließend stellt sich eine zweite Frage, die in Kostenvergleichen häufig untergeht: Wann entstehen die Kosten? Ein System kann mit Kapazitätsreserven beschafft werden, ein anderes lässt sich in kleineren Schritten erweitern. Damit können zwei Architekturen denselben Kapazitätsbedarf über fünf Jahre decken und trotzdem völlig unterschiedliche Zahlungsverläufe erzeugen. Ein statischer Vergleich der Anschaffungspreise ist deshalb nur eine Momentaufnahme.
Für den Betrachtungszeitraum selbst existiert kein grundsätzlich richtiger Wert. In unseren Projekten betrachten wir abhängig vom Kunden und dessen Planungsrahmen typischerweise drei oder fünf Jahre. Wichtig ist weniger, welcher Zeitraum gewählt wird, sondern dass er für beide Alternativen identisch ist und die erwartete Nutzung realistisch abbildet.
Beide Varianten haben spezifische Schwächen. Bei einer Drei-Jahres-Betrachtung können Kosten außerhalb dieses Zeitraums unsichtbar bleiben, etwa eine Erweiterung im vierten Jahr oder ein absehbarer Lifecycle-Wechsel. Bei einer längeren Betrachtung nehmen dagegen die Unsicherheiten hinsichtlich Wachstum, Preisen und zukünftiger Anforderungen zu. Der Betrachtungszeitraum ist damit selbst eine Annahme des Modells und sollte explizit dokumentiert werden.
Welche Kosten sollten berücksichtigt werden?
Welche Kostenpositionen relevant sind, hängt von der konkreten Beschaffung ab. Typischerweise können unter anderem folgende Positionen untersucht werden:
Kostenbereich
Mögliche Bestandteile
Initiale Infrastruktur
Storage-Systeme, Controller, Nodes, Drives
Software
Basissoftware, erforderliche Funktionen und Lizenzen
Support und Wartung
Wartungsverträge und Support über den Betrachtungszeitraum
Kapazitätserweiterungen
zusätzliche Drives, Shelves, Nodes oder Systeme
Redundanz
zusätzliche Infrastruktur für die geforderte Absicherung
Rechenzentrum
Rackspace, Energie und Kühlung, sofern belastbar bestimmbar
Dienstleistungen
Implementierung und andere unmittelbar der Beschaffung zurechenbare Leistungen
Die Liste ist keine Vorgabe, jede Position zwingend zu monetarisieren. Für jede einzelne Position ist vielmehr zu fragen, ob dieser Kostenfaktor für die konkrete Entscheidung relevant ist und ob er sich ausreichend belastbar bestimmen lässt. Beide Bedingungen müssen erfüllt sein. Ein Faktor, der relevant, aber nicht bestimmbar ist, gehört in das Entscheidungsmodell — aber nicht in die Summe.
Energie: eine belastbare Position mit einer irreführenden Kennzahl
Energie ist eine der wenigen Betriebskostenpositionen, die sich über einen mehrjährigen Zeitraum tatsächlich belastbar rechnen lässt. Anders als Administrationsaufwände hängt sie nicht von schwer prognostizierbarem menschlichem Verhalten ab, sondern von Leistungsaufnahme, Auslastung und Strompreis. Alle drei Größen sind zumindest näherungsweise bekannt oder messbar.
Die SNIA behandelt den Stromverbrauch entsprechend als einen der größten Treiber der Betriebskosten im Rechenzentrum und zugleich als wesentliche Randbedingung für die Auslegung eines Racks. Im Modell wird der Verbrauch der IT-Ausrüstung im Rack mit dem Verbrauch des Storage summiert, wobei ein Duty Cycle abbildet, wie häufig sich die Geräte im aktiven statt im Idle-Zustand befinden. Die Umrechnung in Kosten erfolgt anschließend über feste Konstanten für Strompreis und PUE.
Bemerkenswert ist die Behandlung der Kühlung: Das SNIA-Modell unterstellt, dass Kühlkosten bereits in der IT-Ausrüstung enthalten sind, statt sie auf Rechenzentrumsebene zu betrachten. Sind die Kühlkosten für eine gegebene Rack-Leistung bekannt und fest, lassen sie sich als fixe Rechenzentrumskosten ergänzen. Das ist eine Modellvereinfachung, keine Aussage über die Realität — und ein gutes Beispiel dafür, warum Modellgrenzen mitgelesen werden müssen.
Warum PUE als Kostenkennzahl in die Irre führt
Power Usage Effectiveness ist nach ISO/IEC 30134-2 definiert als das Verhältnis des Gesamtenergieverbrauchs eines Rechenzentrums zum Energieverbrauch seiner IT-Ausrüstung, berechnet, gemessen oder bewertet über denselben Zeitraum. Die SNIA verwendet diese Definition in ihrem TCO-Modell.
Aus dieser Definition folgt unmittelbar das Problem. PUE misst keinen Verbrauch, sondern ein Verhältnis. Der Wert kann sich verbessern, während der absolute Energieverbrauch steigt — und er verbessert sich sogar dann, wenn die IT-Last zunimmt, ohne dass sich an der Infrastruktur irgendetwas geändert hätte. Ein Rechenzentrum, das mehr Server in denselben gekühlten Raum stellt, senkt seinen PUE und erhöht seine Stromrechnung.
Für einen TCO-Vergleich ist das entscheidend: Die relevante Größe ist der absolute Energieverbrauch der verglichenen Lösungen über den Betrachtungszeitraum, nicht die Effizienzkennzahl des Rechenzentrums, in dem sie betrieben werden. PUE geht in die Rechnung ein — als Faktor, um von IT-Verbrauch auf Gesamtverbrauch zu schließen. Als Vergleichsmaßstab zwischen zwei Storage-Architekturen taugt er nicht.
Diese Unterscheidung wird umso wichtiger, je stärker sich der Energiebedarf zwischen den verglichenen Medien und Architekturen unterscheidet. Wir behandeln die Zusammenhänge zwischen Speicherdichte, Rackfläche und Leistungsaufnahme ausführlicher im Beitrag [QUERVERWEIS: All-Flash-Medien, URL folgt].
Regulatorischer Rahmen
Für Betreiber in Deutschland kommt hinzu, dass der Energieverbrauch von Rechenzentren inzwischen reguliert ist. Das Energieeffizienzgesetz stellt seit November 2023 Anforderungen unter anderem an die Energieverbrauchseffektivität, an die Abwärmenutzung und an Berichtspflichten.
Dieser Rahmen befindet sich derzeit in Bewegung. Die Bundesregierung hat im Juni 2026 den Entwurf eines Gesetzes zur Beschleunigung der Umsetzung der Energieeffizienzrichtlinie beschlossen und dem Bundesrat als besonders eilbedürftig zugeleitet; begründet wurde dies mit der bereits abgelaufenen Umsetzungsfrist der EU-Energieeffizienzrichtlinie und einem laufenden Vertragsverletzungsverfahren. Der Bundesrat hat im Juli 2026 Stellung genommen, das Verfahren im Bundestag steht zum Zeitpunkt dieses Beitrags noch aus.
Inhaltlich zielt der Entwurf für Rechenzentren in Richtung einer Entlastung: Für Bestandsrechenzentren sollen die Anforderungen an die Energieverbrauchseffektivität gegenüber der geltenden Rechtslage abgesenkt werden. Für Neubauten ist dies nach dem Kabinettsentwurf nicht vorgesehen — hier sind Erleichterungen, die eine frühere Entwurfsfassung noch enthielt, wieder entfallen.
Für die TCO-Praxis bedeutet das zweierlei. Erstens gilt bis zur Verkündung das bestehende Recht. Zweitens sollte ein Fünf-Jahres-Modell nicht auf Grenzwerten aufgebaut werden, die sich noch im parlamentarischen Verfahren befinden. Wir behandeln regulatorische Anforderungen in Beschaffungsentscheidungen deshalb als Randbedingung mit Statusangabe, nicht als feste Kalkulationsgröße — und weisen konkrete Zahlenwerte erst nach Verkündung aus.
Cloud- und Subscription-Modelle im Vergleich
Der bisher beschriebene Ansatz unterstellt implizit eine Kaufentscheidung. Sobald eine der verglichenen Alternativen ein Verbrauchs- oder Subscription-Modell ist, kommt ein zusätzliches Symmetrieproblem hinzu.
Der offensichtliche Unterschied liegt in der zeitlichen Verteilung. Eine Kaufentscheidung bindet Kapital zu Beginn, ein Verbrauchsmodell verteilt die Zahlungen über die Nutzungsdauer. Werden beide Varianten als einfache Summe über fünf Jahre gegenübergestellt, bleibt dieser Unterschied unsichtbar. Wer die Kapitalbindung berücksichtigen will, muss die Zahlungsströme abzinsen — und dann wird der gewählte Zinssatz zu einer weiteren dokumentationspflichtigen Annahme. Wer darauf verzichtet, sollte das explizit benennen, statt es stillschweigend zu tun.
Der methodisch schwierigere Unterschied betrifft aber die Kostentreiber selbst. Bei einem gekauften System hängen die Kosten im Wesentlichen von der bereitgestellten Kapazität ab. Bei Verbrauchsmodellen kommen Kostenarten hinzu, die nicht vom gespeicherten Volumen abhängen, sondern vom Zugriffsverhalten: Datenausgang, Abrufvorgänge, API-Operationen, Mindestspeicherdauern bei kälteren Speicherklassen. Diese Positionen lassen sich nicht aus der Kapazitätsplanung ableiten. Sie erfordern eine Annahme darüber, wie häufig und in welchem Umfang auf die Daten zugegriffen wird — und genau diese Annahme ist bei einer Neubeschaffung oft am schwächsten belegt.
Daraus folgt für die Praxis: Ein Cloud- oder Subscription-Angebot lässt sich nicht seriös über einen reinen Preis pro Terabyte und Monat mit einer On-Premises-Lösung vergleichen. Der Vergleich benötigt ein Zugriffsprofil. Liegt kein belastbares Profil vor, sollten mehrere Szenarien gerechnet werden, statt einen Mittelwert als Tatsache zu behandeln.
Hinzu kommen zwei Faktoren, die sich einer Vorabbewertung weitgehend entziehen. Der eine ist das Verlängerungsrisiko: Bei einem Subscription-Modell endet die Preisbindung mit der Vertragslaufzeit, und die Anschlusskonditionen sind zum Entscheidungszeitpunkt unbekannt. Der andere sind Ausstiegskosten. Ein Wechsel des Anbieters verursacht Aufwand für Datenausgang, Migration und Parallelbetrieb — und dieser Aufwand steigt mit dem Datenvolumen, das während der Laufzeit angewachsen ist. Beide Faktoren gehören sichtbar in das Entscheidungsmodell, ohne dass ihnen ohne konkrete Vertragsgrundlage ein belastbarer Betrag zugeordnet werden könnte.
[BILD: Gegenüberstellung der Zahlungsverläufe Kauf gegen Subscription über fünf Jahre, mit Kennzeichnung der zugriffsabhängigen Kostenanteile]
Warum nicht jeder Faktor einen Eurobetrag bekommen sollte
TCO-Modelle vermitteln schnell eine Genauigkeit, die ihre Eingangsdaten nicht besitzen.
Ein gutes Beispiel sind Administrationskosten. Selbstverständlich verursacht der Betrieb eines Storage-Systems Personalaufwand. Daraus folgt aber noch nicht, dass sich für zwei konkurrierende Systeme ohne belastbare Betriebsdaten seriös unterschiedliche Personalkosten ansetzen lassen. Wir berücksichtigen Administrationskosten in TCO-Vergleichen deshalb nicht automatisch monetär. Ohne kundenspezifische Daten würde eine solche Rechnung im Wesentlichen von willkürlich gewählten Annahmen abhängen — und weil diese Annahmen typischerweise vom Anbieter stammen, fallen sie erfahrungsgemäß zugunsten des eigenen Systems aus.
Dasselbe Prinzip gilt für andere schwer vorhersehbare Kosten.
Ein System kann innerhalb des betrachteten Zeitraums einen technologischen oder herstellerseitigen Lifecycle-Punkt erreichen, und daraus können Kosten entstehen. Wenn jedoch nicht feststeht, wann und in welcher Höhe diese Kosten auftreten, ist ein frei angenommener Eurobetrag problematisch. Der Faktor sollte im Entscheidungsmodell sichtbar bleiben, ohne eine Genauigkeit vorzutäuschen, die nicht vorhanden ist.
Auch eine spätere Datenmigration kann erhebliche technische und organisatorische Aufwände verursachen. Die tatsächlichen Kosten hängen von Datenvolumen, Datenstruktur, Protokollen, Downtime-Anforderungen, Parallelbetrieb und Migrationsverfahren ab. Wir weisen diesen Punkt deshalb als möglichen Kostenfaktor aus, ohne ihn ohne konkrete Projektgrundlage pauschal zu monetarisieren. Welche Faktoren den Aufwand einer Migration tatsächlich bestimmen, haben wir im Beitrag [QUERVERWEIS: NAS-Migration auf ein Global File System, URL folgt] aus der Projektpraxis beschrieben.
Damit entsteht eine wichtige Trennung: Nicht in der TCO-Summe enthalten bedeutet nicht automatisch irrelevant. Ein Entscheidungsmodell kann quantitative und qualitative Faktoren nebeneinander darstellen, solange es kenntlich macht, welche der beiden Kategorien eine Aussage trägt.
Unser Vorgehensmodell: das Modell muss reproduzierbar sein
Das folgende Beispiel stammt aus einem Kundenprojekt, in dem wir selbst die anbietende Partei waren. Wir hatten damit ein unmittelbares wirtschaftliches Interesse am Ergebnis des Vergleichs — was die Frage aufwirft, warum ein solcher Vergleich überhaupt Vertrauen verdienen sollte. Genau darum ging es bei der Konstruktion des Modells.
Der Kostenvergleich wurde bewusst so aufgebaut, dass der Kunde die Berechnung selbst nachvollziehen und überprüfen konnte. Zunächst wurden die Kosten der angebotenen eigenen Lösung nach bestem Wissen vollständig modelliert und mit konkreten Zahlen hinterlegt. Für das Wettbewerbssystem standen nicht für sämtliche Positionen verifizierte Kosten zur Verfügung. Diese Informationslücke wurde nicht dadurch geschlossen, unbekannte Werte als Tatsachen darzustellen. Stattdessen wurden die notwendigen Annahmen und Schätzwerte transparent als solche in das Modell eingesetzt.
Der entscheidende Schritt bestand darin, die Berechnung so aufzubauen, dass der Kunde diese Werte anschließend durch die ihm vorliegenden tatsächlichen Wettbewerbspreise ersetzen konnte. Damit änderte sich die Funktion des Modells grundlegend. Es sollte nicht mehr beweisen, dass die eigene Lösung um einen bestimmten Prozentsatz günstiger sei. Der Kunde konnte stattdessen prüfen, ob die errechnete Kostendifferenz bestehen bleibt, wenn er die Annahmen durch seine eigenen Zahlen ersetzt.
Diese Vorgehensweise reduziert eine typische Schwäche von Anbieter-TCO-Rechnungen: Das Ergebnis hängt nicht verborgen von Annahmen über den Wettbewerber ab. Die für das Resultat entscheidenden Parameter bleiben sichtbar und veränderbar. Ein Anbieter, der sein Modell so aufbaut, gibt die Kontrolle über das Ergebnis ab — und das ist der Punkt.
Daraus lässt sich ein allgemeines methodisches Prinzip ableiten. Ein belastbarer TCO-Vergleich sollte transparent sein, sodass jede wesentliche Annahme sichtbar ist. Er sollte symmetrisch sein, sodass für beide Systeme dieselben Anforderungen hinsichtlich Kapazität, Wachstum, Zeitraum und Redundanz gelten. Er sollte austauschbar sein, sodass geschätzte Werte durch reale Angebots- oder Kundendaten ersetzt werden können. Und er sollte reproduzierbar sein, sodass nachvollziehbar bleibt, wie sich das Ergebnis durch die Änderung eines Eingabewerts verschiebt. Ein Modell, das diese vier Eigenschaften besitzt, ist weniger eine Verkaufsrechnung als ein überprüfbares Entscheidungsinstrument.
Sensitivität und Ergebnisdarstellung
Gerade bei einem Drei- oder Fünf-Jahres-Modell sind einige Eingangswerte zwangsläufig Annahmen. Das betrifft insbesondere das zukünftige Datenwachstum.
Statt eine Wachstumsrate von 17,3 Prozent als vermeintlich exakte Prognose zu behandeln, ist es sinnvoller, mehrere Szenarien zu rechnen — ein niedriges, ein erwartetes und ein hohes. Dasselbe Verfahren lässt sich für andere unsichere, aber einflussreiche Parameter einsetzen, etwa für Zugriffsprofile bei Verbrauchsmodellen oder für Data-Reduction-Faktoren.
Dadurch lässt sich eine für die Entscheidung wichtigere Frage beantworten: Ab welcher Änderung einer Annahme kippt der wirtschaftliche Vorteil von System A zu System B? Ist System A im Basisszenario günstiger und bleibt dies auch bei deutlich höherem oder niedrigerem Wachstum so, ist die Aussage robuster als ein einzelner exakt aussehender TCO-Wert. Liegt der Break-even dagegen bereits bei einer kleinen Änderung der Wachstumsannahme, sollte die Kostendifferenz bei der Architekturentscheidung entsprechend vorsichtig gewichtet werden.
Für die Darstellung des Ergebnisses reicht eine einzelne Kennzahl meist nicht aus. Wir verwenden deshalb eine Kombination aus drei Betrachtungen.
Die Gesamtkosten über den Betrachtungszeitraum beantworten die unmittelbarste wirtschaftliche Frage, nämlich welche quantifizierten Kosten über drei beziehungsweise fünf Jahre entstehen.
Eine kapazitätsbezogene Kennzahl ermöglicht zusätzlich die Normalisierung unterschiedlicher Systeme. Dabei muss exakt dokumentiert werden, welche Kapazität im Nenner steht. Raw Capacity, Usable Capacity und eine unter Annahmen errechnete Effective Capacity dürfen nicht ohne Kennzeichnung gegeneinander verwendet werden. Die SNIA normalisiert in ihrem Modell auf Kosten je Effective Capacity, Rack und Monat — eine legitime Wahl, solange sie offengelegt wird.
Der Kostenverlauf schließlich zeigt, wann Erweiterungen erforderlich werden und wann dadurch Kosten entstehen. Damit wird sichtbar, ob ein niedriger Einstiegspreis durch spätere Erweiterungen relativiert wird oder eine höhere Anfangsinvestition über den Gesamtzeitraum wirtschaftlicher ist.
[BILD: Sensitivitätsdarstellung mit Break-even-Punkt zweier Systeme über variierende Wachstumsannahmen]
Performance ist eine Vorbedingung, keine Kostenposition
Ein Storage-System wird nicht ausschließlich gekauft, um Daten möglichst günstig zu speichern. Es muss einen definierten Workload bedienen.
Die SNIA hat ihr TCO-Modell deshalb um einen performanceorientierten Ansatz erweitert. Das entsprechende Whitepaper beschreibt ein zeitbewusstes TCO-Modell, das neben den Infrastrukturkosten unter anderem die Prozessorauslastung, die Ausführungszeit und den Energieverbrauch eines Workloads einbezieht. Der Grundgedanke: Die vollen Kosten eines Workloads ergeben sich nicht aus dem Preis der Infrastruktur allein, sondern aus Performance, Bearbeitungsdauer und Ressourcennutzung.
Das verweist auf eine wichtige Grenze klassischer TCO-Vergleiche. Die kostengünstigste Infrastruktur ist nicht wirtschaftlicher, wenn sie die technischen Anforderungen nicht erfüllt.
Wir behandeln Performance deshalb nicht als Kostenposition, sondern als Vorbedingung. Zunächst wird definiert, welche Anforderungen hinsichtlich Latenz, IOPS oder Durchsatz erfüllt sein müssen. Nur Lösungen, die diese Kriterien erfüllen, gelangen anschließend in den wirtschaftlichen Vergleich. Andernfalls werden technisch unterschiedliche Leistungen über eine gemeinsame Kostenkennzahl scheinbar vergleichbar gemacht — mit dem absehbaren Ergebnis, dass das schwächere System gewinnt.
Welche Kriterien sich für die Definition solcher Mindestanforderungen eignen, behandeln wir im Beitrag [QUERVERWEIS: Hochperformanter Datenzugriff, URL folgt].
Typische Fehler bei Storage-TCO-Vergleichen
Besonders kritisch sind TCO-Rechnungen, bei denen unterschiedliche technische oder wirtschaftliche Annahmen unbemerkt miteinander vermischt werden. Dazu gehören insbesondere:
Vergleich der Raw Capacity eines Systems mit der Usable oder Effective Capacity eines anderen,
unterschiedliche Redundanzanforderungen,
angenommene Data-Reduction-Ratios ohne Bezug zum tatsächlichen Datenbestand,
fehlendes oder unterschiedlich angesetztes Datenwachstum,
unterschiedliche Betrachtungszeiträume,
nicht vergleichbare Support- oder Wartungszeiträume,
Erweiterungskosten nur bei einer Alternative,
Gegenüberstellung von Kauf und Subscription ohne Behandlung der zeitlichen Kostenverteilung,
zugriffsabhängige Kosten ohne hinterlegtes Zugriffsprofil,
monetarisierte Betriebsaufwände ohne belastbare Datengrundlage,
versteckte Annahmen über Wettbewerbskosten,
technisch ungeeignete Systeme, die allein aufgrund niedrigerer Kosten in den Vergleich aufgenommen werden.
Das gemeinsame Problem dieser Fehler ist nicht zwingend eine falsche mathematische Berechnung. Die Mathematik kann vollkommen korrekt sein und das Ergebnis trotzdem irreführend, weil die Eingangsdaten keine vergleichbare technische Ausgangssituation beschreiben.
Fazit
Storage-TCO beginnt nicht mit einer Preisliste, sondern mit einer technischen Definition dessen, was miteinander verglichen werden soll. Benötigte Usable Capacity, Redundanz, erwartetes Wachstum, technischer Leistungsbedarf und Betrachtungszeitraum müssen für beide Alternativen auf dieselbe Grundlage gestellt werden. Erst danach können Anschaffung, Software, Wartung, Erweiterungen, Energie und weitere belastbar bestimmbare Kosten gegenübergestellt werden.
Ebenso wichtig ist, die Grenzen der Rechnung sichtbar zu machen. Administration, zukünftige Migrationen, Ausstiegskosten oder Lifecycle-Risiken können für eine Entscheidung relevant sein, ohne dass ihnen ein belastbarer Eurobetrag zugeordnet werden kann.
Ein Drei- oder Fünf-Jahres-TCO kann zukünftige Kosten ohnehin nicht exakt vorhersagen. Datenwachstum verläuft anders als geplant, Anforderungen und Preise verändern sich, neue Workloads entstehen, Systeme werden länger genutzt oder früher ersetzt als vorgesehen. Das spricht nicht gegen TCO-Modelle — es verändert lediglich ihren Zweck. Ein gutes Modell gibt nicht vor, die Zukunft zu kennen. Es zeigt transparent, welche wirtschaftlichen Konsequenzen sich aus definierten technischen und kaufmännischen Annahmen ergeben.
Aus unserer Projekterfahrung folgt deshalb ein bewusst pragmatischer Ansatz: Belastbar quantifizierbare Kosten werden gerechnet. Unsichere Faktoren werden transparent ausgewiesen. Annahmen über Wettbewerbsangebote bleiben austauschbar.
Der Qualitätsmaßstab eines Storage-TCO-Modells ist damit nicht seine Komplexität. Ein belastbarer TCO-Vergleich ist eine Rechnung, deren Ergebnis der Kunde durch Veränderung der Annahmen selbst überprüfen kann.
Quellen
Hands, Jonmichael (SNIA Compute, Memory and Storage Initiative, Solid State Drive Special Interest Group): Total Cost of Ownership (TCO) Model for Storage, Whitepaper, © 2021 Storage Networking Industry Association. Grundlage für die Abgrenzung von CapEx und OpEx, für die Definition der Effective Capacity (TBe), für die Modellmetrik TCO $/TBe/Rack/Monat sowie für die Behandlung von Strom, Kühlung und Geräteausfällen. Softwarelizenzkosten sind im Modell ausdrücklich nicht enthalten. https://www.snia.org/sites/default/files/SSSI/SNIA-TCO-Whitepaper-2022.pdf Abruf: 31.08.2026. Anmerkung: Das Dokument wird unter einem Dateinamen mit der Jahreszahl 2022 bereitgestellt, trägt jedoch durchgehend den Copyright-Vermerk 2021 und ist inhaltlich identisch mit der unter SNIA_TCO_Whitepaper_03-2021.pdf veröffentlichten Fassung.
Storage Networking Industry Association (SNIA): SNIA Dictionary – raw capacity. Definition der Raw Capacity als gesamte adressierbare Kapazität der Storage Devices eines Storage-Systems. https://www.snia.org/education/online-dictionary/term/raw-capacity Abruf: 31.08.2026.
Storage Networking Industry Association (SNIA): SNIA Dictionary – usable capacity sowie formatted capacity. Usable Capacity als Synonym für Formatted Capacity; Abgrenzung gegenüber der Raw Capacity einschließlich der Bereiche für Systemnutzung, Spares, RAID-Parity, Checksummen, Remapping und Right Sizing. https://www.snia.org/education/online-dictionary/term/usable-capacity https://www.snia.org/education/online-dictionary/term/formatted-capacity Abruf: 31.08.2026.
Storage Networking Industry Association (SNIA): SNIA Dictionary – capacity optimization methods. Einordnung von Kompression, Deduplizierung, Thin Provisioning und Delta Snapshots sowie von RAID 5 und RAID 6 als Verfahren zur Reduzierung des Kapazitätsverbrauchs. https://www.snia.org/education/online-dictionary/term/capacity-optimization-methodsAbruf: 31.08.2026.
Storage Networking Industry Association (SNIA): Performance-Based TCO, Whitepaper, 2025. Zeitbewusster TCO-Ansatz unter Einbeziehung von Prozessorauslastung, Ausführungszeit und Energieverbrauch. https://www.snia.org/educational-library/performance-based-tco-2025 Abruf: 31.08.2026. Anmerkung: Das Whitepaper ist um eine Fallstudie zu einem konkreten Hardware-Beschleuniger aufgebaut. Es wird hier ausschließlich für die methodische Rahmenaussage herangezogen, nicht für Zahlenwerte.
ISO/IEC 30134-2:2016: Information technology — Data centres — Key performance indicators — Part 2: Power usage effectiveness (PUE). Definition des PUE als Verhältnis des Gesamtenergieverbrauchs eines Rechenzentrums zum Energieverbrauch der IT-Ausrüstung über denselben Zeitraum.
Bundesrat, Drucksache 388/26 vom 25.06.2026: Entwurf eines Gesetzes zur Beschleunigung der Umsetzung der Energieeffizienzrichtlinie. Gesetzentwurf der Bundesregierung, zugeleitet als besonders eilbedürftige Vorlage gemäß Artikel 76 Absatz 2 Satz 4 GG. Stellungnahme des Bundesrates in der 1067. Sitzung am 10.07.2026 (BR-Drs. 388/26(B)). https://www.bundesrat.de/bv.html?id=0388-26 Abruf: 31.08.2026. Anmerkung: Das parlamentarische Verfahren im Bundestag war zum Redaktionsschluss nicht abgeschlossen. Bis zur Verkündung gilt das bestehende Energieeffizienzgesetz.
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
