Inhaltsverzeichnis

In eigener Sache: ASSISTRA implementiert und betreibt Object-Storage-Umgebungen auf Basis von Wasabi Cloud Object Storage und unterhält Partnerschaften mit Wasabi und IONOS. Zu OVHcloud besteht keine Geschäftsbeziehung. Die folgenden Abschnitte beschreiben die Struktur der jeweiligen Preismodelle; sie sprechen keine Kaufempfehlung aus. Alle Angaben stammen aus der öffentlichen Anbieterdokumentation und sind im Quellenapparat nachgewiesen. 

[BILD 3] Matrix mit den drei Anbietern als Zeilen und den Kostendimensionen Kapazität, API-Requests, Ingress, Egress, Retrieval, Mindesthaltedauer und Mindestabrechnung als Spalten. Kein Preisvergleich, sondern die Darstellung, an welcher Stelle die jeweilige Kostenvariable liegt. 

Wasabi: kapazitätsorientiert mit Nutzungsbedingungen 

Beim Pay-as-you-Go-Modell von Wasabi werden API Requests und eingehender Datentransfer nicht separat berechnet. Auch ausgehender Datentransfer wird innerhalb der definierten Nutzungsbedingungen nicht separat berechnet. Die zentrale Abrechnungsgröße ist damit die gespeicherte Kapazität. 

Allerdings muss auch dieses Modell genauer betrachtet werden. Es gilt eine monatliche Mindestabrechnung von 1 TB aktivem Speicher; für Wasabi Cloud NAS liegt diese Schwelle bei 10 TB. Hinzu kommt eine Mindesthaltedauer von 90 Tagen: Wird ein Objekt vorher gelöscht, kann die verbleibende Zeit als Timed Deleted Storage berechnet werden. 

Die kostenlose Datenübertragung ist an Bedingungen gebunden. Wasabi beschreibt monatlichen Egress bis zur Höhe des aktiven Storage-Volumens als mit der entsprechenden Policy vereinbar; bei regelmäßig darüber hinausgehendem Egress behält sich der Anbieter vor, den Dienst einzuschränken oder auszusetzen. Eine analoge Bedingung gilt für API Requests. Bei kommerziellen Anwendungen, die Wasabi validiert hat, kann in der Regel von Konformität ausgegangen werden; bei nicht validierten Anwendungen, die eine unangemessene Last erzeugen, gilt derselbe Vorbehalt. 

Drei weitere Mechanismen wirken direkt auf die abgerechnete Kapazität. Die kleinste abrechnungsrelevante Dateigröße beträgt 4 KB, eine gespeicherte Datei von 2 KB wird also berechnet, als wäre sie 4 KB groß. Versioning legt zusätzliche Objektversionen an und erhöht dadurch die Speicherkosten, und Bucket-Logs werden wie jeder andere abrechenbare Speicher behandelt. Wird eine Datei ohne aktiviertes Versioning überschrieben, wechselt die ursprüngliche Kopie von aktivem in gelöschten Speicher und wird für die verbleibenden Tage der Mindesthaltedauer berechnet. 

Die korrekte Aussage lautet daher nicht, dass bei Wasabi ausschließlich Speicherkosten entstehen. Präziser ist: Das Modell reduziert die Anzahl verbrauchsabhängiger Kostenvariablen erheblich, weil API Requests und, innerhalb der geltenden Bedingungen, Egress nicht separat berechnet werden. Für eine TCO-Prognose kann das einen wesentlichen Unterschied darstellen. Bei Beständen aus mehreren Millionen kleiner Dateien verschiebt die Mindestobjektgröße die Kalkulation gegenüber einer reinen Volumenbetrachtung allerdings messbar. 

IONOS: freie API, gestaffelter Traffic 

IONOS trennt Speicherkapazität und Datenübertragung, berechnet für die API jedoch keine Gebühren. Die Nutzung der API ist kostenfrei, der Speicherplatz wird pro GB und Stunde berechnet, und eingehender Datentransfer ist kostenlos. Die Preisliste weist die üblichen Operationen einzeln aus: PUT, COPY, POST und LIST ebenso wie GET und DELETE sind kostenfrei, ebenso lesender und schreibender Datenzugriff [QUERVERWEIS: S3 als Zugriffsschicht für Object Storage]. 

Bei der Datenübertragung wird das Modell differenzierter, und zwar auf eine Weise, die für eine TCO-Prognose unmittelbar relevant ist. Ausgehender öffentlicher Traffic ist bis zu einem Volumen von 2 TB pro Monat kostenfrei; darüber greift nach der Preisliste vom 27. August 2026 eine Staffelung von 0,030 Euro je GB für die nächsten 8 TB bis hinunter zu 0,015 Euro je GB oberhalb von 150 TB. Entscheidend ist dabei die Bezugsgröße: Die Preisstaffelung gilt für den gesamten ausgehenden Datenverkehr aller IONOS-Public-Cloud-Services innerhalb desselben Vertrags, und der kumulierte Gesamtbetrag wird auf der Rechnung ausgewiesen. 

Der Object-Storage-Egress wird also nicht isoliert bepreist, sondern gegen den Gesamtverbrauch des Vertrags gerechnet. Wer neben Object Storage weitere Dienste betreibt, kann die Freimenge dort bereits ausgeschöpft haben. 

Hinzu kommt eine Unterscheidung, die in der Architekturentscheidung getroffen wird. Bei vertragseigenen Buckets ist ausgehender Transfer als öffentlicher Traffic abrechenbar, ausgenommen Transfers zu virtuellen Maschinen im selben Rechenzentrum. Bei benutzereigenen Buckets wird sämtlicher ausgehender Transfer als öffentlicher Traffic abgerechnet; die Definitionen für lokalen und nationalen Traffic gelten dort nicht, auch nicht für Transfers zu IONOS-VMs oder Dedicated Servers, unabhängig von deren geografischem Standort. Transfer zwischen Buckets ist kostenpflichtig, Replikationstraffic innerhalb einer Region und zwischen Regionen dagegen kostenfrei. 

OVHcloud: die Kostenvariable liegt in der Storage Class 

OVHcloud zeigt ein drittes Modell. Object Storage wird nutzungsabhängig nach dem durchschnittlich pro Stunde gespeicherten Volumen je Storage Class abgerechnet, gemessen in GiB-Stunden. Speicher ist die zentrale Abrechnungskomponente; eingehender Traffic, interner Traffic, API-Calls und ausgehender öffentlicher Traffic sind eingeschlossen. 

Daraus folgt jedoch nicht, dass die Kalkulation auf eine einzige Variable zusammenschrumpft. Sie verschiebt sich lediglich. OVHcloud bietet mehrere S3-kompatible Storage Classes an, darunter Standard, High Performance, Infrequent Access, Active Archive und Cold Archive. Für Infrequent Access, ActiveArchive und Cold Archive gelten eine Mindesthaltedauer und Retrieval-Gebühren. 

Wie diese Mindesthaltedauer wirkt, dokumentiert der Anbieter präzise. Bei vorzeitiger Löschung wird eine anteilige Gebühr für die verbleibenden Tage berechnet. Für die Klasse Infrequent Access beträgt die Mindestspeicherzeit 730 Stunden, also 30 Tage; die Zusatzgebühr ergibt sich aus der Differenz zwischen 730 Stunden und der tatsächlichen Speicherdauer, multipliziert mit dem Stundenpreis der Storage Class. 

Besonders aufschlussreich ist ein Detail, das in einer reinen Kapazitätsbetrachtung unsichtbar bliebe. Bei nicht versionierten Buckets gilt das Überschreiben eines Objekts als Löschung der aktuellen Version und löst die anteilige Gebühr ebenfalls aus. Ein Workload, der Objekte regelmäßig ersetzt, erzeugt in einer Klasse mit Mindesthaltedauer also laufend Kosten für bereits überschriebene Daten. 

Für die kälteste Klasse kommt ein weiterer Mechanismus hinzu. Objekte im Cold Archive stehen nicht unmittelbar zur Verfügung, sondern müssen über einen Restore-Request wiederhergestellt werden; die Bereitstellung dauert von Minuten bis zu mehreren Stunden. Je wiederhergestelltem Objekt fallen eine einmalige Restore-Gebühr pro GiB sowie Speicherkosten zum Tarif der Standard-Klasse an. Schließlich ist auch die Kapazitätsabrechnung selbst nicht zwingend linear: In Regionen mit drei Verfügbarkeitszonen erfolgt sie gestaffelt nach Volumenstufen. 

Damit lässt sich beantworten, worin sich die Modelle unterscheiden. Ein Modell ohne Request- und Transferkosten ist nicht automatisch ein Modell mit nur einer Kostenvariablen. Es verlagert die Variable dorthin, wo sie architektonisch entschieden wird, nämlich in die Klassenwahl und in den Lebenszyklus der Objekte. Für eine Kostenprognose muss der Workload also weiterhin bekannt sein. Die Frage lautet nur nicht mehr, wie oft zugegriffen wird, sondern wie lange Objekte in ihrer Klasse verbleiben. 

Bereits anhand dieser drei Anbieter zeigt sich: Cloud Object Storage besitzt kein einheitliches Kostenmodell. Die konkrete Tarifstruktur muss Bestandteil der Architekturentscheidung sein.