WISSEN > OBJECT STORAGE > OBJECT STORAGE ON-PREMISES ODER CLOUD

Autor: Dirk Neumann                Geschäftsführer ASSISTRA Cloud Services GmbH                            17.08.2026

Object Storage On-Premises oder in der Cloud?
Wie Datenpfad, Kapazität, Kosten und Souveränität die Betriebsform bestimmen
 


Das sollten Sie mitnehmen:
 

  1. On-Premises und Cloud unterscheiden sich vor allem in der Betriebsform.
    Verantwortlichkeiten, Datenpfade, Kapazitätsbereitstellung und Kostenmodelle verändern sich, das Speichermodell nicht.
     
  2. Der Datenpfad ist ein wesentliches Entscheidungskriterium.
    Liegen Anwendung und Storage an verschiedenen Standorten, werden Bandbreite und Latenz Bestandteil des Zugriffspfads.
     
  3. Kapazität entsteht in beiden Modellen unterschiedlich.
    On-Premises verlangt Dimensionierung, Reserve und Lifecycle-Management, die Cloud verlagert diese Aufgaben zum Provider.
     
  4. Kosten müssen über einen definierten Zeitraum verglichen werden.
    Betrachtungszeitraum und Preismodell verändern das Ergebnis erheblich.
     
  5. Datenstandort und digitale Souveränität sind nicht dasselbe.
    Jurisdiktion, Betreiberkontrolle, Lieferketten und Datenzugriffe gehören getrennt betrachtet.

Wie Datenpfad, Kapazität, Kosten und Souveränität die Betriebsform bestimmen

Inhaltsverzeichnis

Object Storage kann als eigene Infrastruktur im Rechenzentrum oder als Cloud-Service bereitgestellt werden. Das grundlegende Speichermodell ändert sich dadurch nicht: Anwendungen adressieren Objekte über Identifier beziehungsweise Keys und greifen typischerweise über eine Object-Storage-API darauf zu. Was sich ändern kann, liegt darunter und daneben — der Datenpfad, die Betriebsverantwortung, die Kapazitätsplanung, das Kostenmodell und die Kontrolle über die Infrastruktur.

 

Die Frage „On-Premises oder Cloud?“ sollte deshalb nicht am Anfang einer Storage-Entscheidung stehen. Zunächst muss geklärt werden, ob Object Storage für den jeweiligen Workload überhaupt das geeignete Zugriffs- und Speichermodell ist [QUERVERWEIS: Was ist Object Storage?]. Erst danach stellt sich die Frage nach der Betriebsform.

 

Einen generellen technischen Gewinner gibt es dabei nicht. Eine Cloud stellt Kapazität als Service bereit und reduziert den eigenen Infrastrukturaufwand. On-Premises Object Storage ermöglicht dagegen weitgehende Kontrolle über Infrastruktur, Datenpfade und Betrieb. Welche Variante trägt, entscheidet sich an den Anforderungen des konkreten Workloads.

Die Betriebsform ist mehr als eine Standortentscheidung

Cloud Computing wird vom NIST als Modell beschrieben, bei dem konfigurierbare IT-Ressourcen über ein Netzwerk bedarfsgerecht aus einem gemeinsamen Ressourcenpool bereitgestellt und mit geringem Managementaufwand provisioniert beziehungsweise freigegeben werden können. Zu den fünf wesentlichen Eigenschaften zählt NIST On-Demand Self-Service, Broad Network Access, Resource Pooling, Rapid Elasticity und Measured Service. 

Ein Cloud Object Storage unterscheidet sich damit grundsätzlich von einer Storage-Plattform, die ein Unternehmen selbst beschafft und betreibt. Es geht nicht darum, wo die Festplatten stehen. Bei einem On-Premises-System stellt die Organisation physische Kapazität bereit, betreibt die Storage-Infrastruktur und verantwortet deren Lifecycle. Bei einem vollständig gemanagten Cloud Object Storage wandert ein Teil dieser Aufgaben in den Verantwortungsbereich des Service Providers. Diese Verschiebung ist der eigentliche Gegenstand der Entscheidung. 

Was bei beiden Varianten gleich bleibt 

Die Betriebsform sollte nicht mit dem Storage-Modell verwechselt werden. Object Storage bleibt Object Storage, unabhängig davon, ob die zugrunde liegende Infrastruktur im eigenen Rechenzentrum oder beim Cloud Provider läuft. 

Für eine Anwendung ist zunächst entscheidend, welche Schnittstelle das Storage-System bereitstellt und ob diese zur Anwendung passt. Ein S3-kompatibles Object Storage wird durch seinen Betrieb im eigenen Rechenzentrum nicht zu File Storage. Umgekehrt stellt ein Cloud Object Storage nicht automatisch SMB- oder NFS-Dateiservices bereit [QUERVERWEIS: S3 als Zugriffsschicht auf Object Storage]. Benötigt eine bestehende Anwendung File-Zugriffe, ist deshalb eine zusätzliche File-Service-Schicht zwischen Anwendung und Object Storage erforderlich. 

Die Entscheidungskette beginnt damit beim Workload und führt über Zugriffsmodell, Datenpfad und Betriebsanforderungen zur Betriebsform. Sie beginnt nicht umgekehrt bei der Festlegung auf Cloud oder On-Premises, an die anschließend ein Storage-System angepasst wird. 

On-Premises Object Storage: Kapazität und Betriebsverantwortung 

Bei einer On-Premises-Architektur betreibt das Unternehmen die für Object Storage erforderliche Infrastruktur selbst oder lässt sie in seinem Auftrag betreiben. Der Datenpfad verläuft von der Anwendung über das lokale Rechenzentrumsnetzwerk und die Object-Storage-API zu den Storage-Nodes und den dort verbauten Speichermedien. 

Die konkrete Architektur hängt vom eingesetzten System ab. Scale-out Object Storage kann Daten und Redundanzinformationen über mehrere Nodes beziehungsweise Failure Domains verteilen [QUERVERWEIS: Scale-out Storage]. Replikation oder Erasure Coding, Metadatenarchitektur und FailureHandling sind jedoch implementationsabhängig und dürfen nicht pauschal für jedes Object-Storage-System angenommen werden. 

Kapazität muss vorab geplant werden 

Der wesentliche Unterschied zur Nutzung eines Cloud-Service liegt darin, dass physische Kapazität nicht erst in dem Moment entsteht, in dem eine Anwendung sie benötigt. 

Die Planung beginnt bei der Ausgangskapazität und dem erwarteten Datenwachstum, führt aber schnell zu Fragen, die sich nicht einzeln beantworten lassen. Das gewählte Redundanzverfahren bestimmt, wie viel der installierten Rohkapazität tatsächlich nutzbar bleibt. Der Zuschnitt der Failure Domains legt fest, in welchen Schritten sich das System überhaupt erweitern lässt. Reservekapazität muss vorhanden sein, bevor sie gebraucht wird, und das Netzwerk muss die geplante Skalierung tragen. Über den Hardware-Lifecycle kommt schließlich der Zeitpunkt hinzu, zu dem die Plattform ganz oder in Teilen ersetzt wird. 

Nutzbare Kapazität und installierte Rohkapazität sind deshalb zwei verschiedene Größen. Wie weit sie auseinanderliegen, hängt vom Redundanzverfahren und von der Systemarchitektur ab. 

Kontrolle bedeutet Betriebsverantwortung 

Mit der Kontrolle über die Infrastruktur übernimmt die Organisation deren Betriebsaufgaben. Dazu gehören je nach Produkt und Betriebsmodell Hardwareaustausch, Software-Updates, Monitoring, Kapazitätsüberwachung, Erweiterungen und Fehlerbehandlung. Beides ist dieselbe Medaille: Wer die Infrastruktur kontrollieren will, muss sie auch betreiben, und beides gehört in dieselbe Bewertung. 

Cloud Object Storage: Kapazität als Service 

Bei Cloud Object Storage wird Storage-Kapazität als Service konsumiert. Der Kunde dimensioniert und beschafft die darunterliegende physische Infrastruktur nicht selbst. Das entspricht wesentlichen Cloud-Eigenschaften der NIST-Definition: Ressourcen werden bedarfsgerecht bereitgestellt, Cloud-Systeme verwenden Messmechanismen zur Erfassung der Ressourcennutzung, und Kapazitäten lassen sich elastisch bereitstellen. 

Aus Sicht der Storage-Planung verändert das die Leitfrage. On-Premises lautet sie, wie viel physische Kapazität heute bereitgestellt werden muss, damit das System den erwarteten Bedarf einschließlich Wachstum und Reserven abdeckt. Bei einem Cloud-Service lautet sie, wie viel Kapazität voraussichtlich konsumiert wird, wie sich diese Menge entwickelt und welche technischen und wirtschaftlichen Konsequenzen daraus entstehen. 

Die Kapazitätsplanung verschwindet damit nicht, sie bekommt eine andere Funktion. Statt die Beschaffung physischer Infrastruktur zu bestimmen, dient sie der Kostenplanung, der Netzwerkplanung und dem Forecasting. 

Wachstum wirkt sich in beiden Modellen unterschiedlich aus 

Ein wesentlicher Vorteil eines Cloud-Service ist, dass Unternehmen nicht für jede erwartete Erweiterung zusätzliche physische Storage-Nodes installieren müssen. Rapid Elasticity gehört ausdrücklich zu den von NIST definierten Eigenschaften von Cloud Computing. Wirtschaftlich unbegrenzt ist Cloud-Kapazität deshalb aber nicht. Mehr gespeicherte Daten führen zu mehr konsumierter Kapazität und damit, abhängig vom Preismodell, zu höheren Kosten. 

On-Premises wird Kapazität dagegen in diskreten Hardware- beziehungsweise Systemschritten bereitgestellt. Dadurch entsteht freie Kapazität, die zunächst nicht genutzt wird, für Wachstum und sicheren Betrieb aber erforderlich sein kann. Damit stehen sich zwei Logiken gegenüber: On-Premises wird Kapazität bereitgestellt, als Reserve vorgehalten, genutzt und anschließend erweitert; in der Cloud wird sie konsumiert, gemessen und laufend abgerechnet. Für die wirtschaftliche Betrachtung ist dieser Unterschied entscheidend. 

[BILD 1: Gegenüberstellung der beiden Kapazitätsmodelle. Links eine Treppenkurve für On-Premises mit Beschaffungsstufen, ungenutzter Reservekapazität zwischen den Stufen und tatsächlich genutzter Kapazität als darunterliegende Wachstumskurve. Rechts eine glatte Verbrauchskurve für Cloud, bei der genutzte und abgerechnete Kapazität zusammenfallen. Gleiche Achsen für beide Seiten: Zeit horizontal, Kapazität vertikal.] 

Der Datenpfad kann die Entscheidung bestimmen 

Einer der wichtigsten Unterschiede zwischen lokalem und entferntem Object Storage entsteht durch den Datenpfad. Befinden sich Anwendung und On-Premises Object Storage im selben Rechenzentrum, läuft der Zugriff vollständig über das lokale Netzwerk. Liegt die Anwendung dagegen On-Premises und das Object Storage bei einem Cloud Provider, wird die Verbindung zum Provider Bestandteil jedes Zugriffs. 

[BILD 2: Zwei Datenpfade untereinander. Oben: Anwendung, LAN, Object Storage innerhalb einer Rechenzentrumsgrenze. Unten: Anwendung und LAN innerhalb der Rechenzentrumsgrenze, danach WAN- beziehungsweise Cloud-Anbindung als eigenes Segment, dann Cloud Object Storage außerhalb der Grenze. Das WAN-Segment ist als das Element hervorgehoben, das im oberen Pfad fehlt.] 

Das heißt nicht, dass Cloud Object Storage zu langsam wäre. Entscheidend sind Workload und Verbindung. Ein Workload, der wenige große Objekte sequenziell schreibt, verhält sich über eine WAN-Strecke völlig anders als einer, der viele kleine Objekte mit hoher Parallelität liest. Neben Bandbreite und Round-Trip-Latenz bestimmen deshalb Objektgrößen, Anzahl und Parallelität der Requests, das Verhältnis von Lese- und Schreibzugriffen, die insgesamt zu bewegende Datenmenge und die Antwortzeiterwartung der Anwendung, ob ein entfernter Datenpfad trägt. 

Aussagekräftig sind daher Upload-, Download- und Anwendungstests mit realistischen Datenmustern, nicht die nominelle Bandbreite einer Netzwerkverbindung. Wir haben in Cloud-Object-Storage-Projekten erlebt, dass Kunden vor der Einführung genau solche Tests mit der vorgesehenen Anwendung durchgeführt haben. Damit wurde nicht die theoretisch verfügbare Leitungskapazität gemessen, sondern der tatsächlich erreichbare Datenpfad zwischen Anwendung und Storage. 

Kosten: CAPEX gegen OPEX reicht als Vergleich nicht 

Ein Vergleich, der On-Premises mit CAPEX und Cloud mit OPEX gleichsetzt, greift zu kurz. 

Auf der On-Premises-Seite stehen zunächst die offensichtlichen Positionen: Storage-Hardware, Storage-Nodes, Netzwerkkomponenten sowie Software und Lizenzen. Dazu kommen die laufenden Kosten für Wartung, Support und Rechenzentrumsinfrastruktur, die über die gesamte Nutzungsdauer anfallen. Und schließlich die Positionen, die in Vergleichsrechnungen am häufigsten fehlen: die Reservekapazität, die bezahlt, aber zunächst nicht genutzt wird, geplante Erweiterungen und die Ersatzbeschaffung am Ende des Lifecycles. 

Bei Cloud Object Storage hängt die Kostenstruktur vom Anbieter und Tarif ab. Wie unterschiedlich Modelle aufgebaut sein können, zeigt bereits ein Vergleich zweier Anbieter. Wasabi dokumentiert für sein Pay-as-you-Go-Modell eine kapazitätsbasierte Abrechnung ohne separate Gebühren für regulären Ingress, Egress und API-Requests; gleichzeitig gelten eine Mindestaufbewahrungsdauer und Richtlinien für die kostenlose Datenausgabe. IONOS rechnet ausgehenden Traffic aus dem Object Storage dagegen grundsätzlich als kostenpflichtigen öffentlichen Traffic mit gestaffelten Preisen ab, während eingehender Traffic nicht berechnet wird und Replikationsverkehr innerhalb einer Region wie auch zwischen Regionen kostenfrei bleibt. 

Beide Modelle sind in sich schlüssig, führen bei identischer Datenmenge aber zu deutlich unterschiedlichen Kostenverläufen, sobald sich das Zugriffsverhalten ändert. Ein Kostenvergleich muss deshalb immer das konkrete Angebot und den konkreten Workload abbilden. 

Unsere Kalkulation für rund 1 PB 

Wir haben in einem Projekt die Kosten einer On-Premises- und einer Cloud-Variante für eine Größenordnung von rund 1 PB gegenübergestellt. In dieser Kalkulation näherte sich die Cloud-Variante erst in der Fünfjahresbetrachtung dem Kostenniveau der On-Premises-Lösung an. 

Als allgemeine TCO-Regel taugt diese Beobachtung nicht. Die Kalkulation stammt aus dem Frühjahr 2025 und bildet die damaligen Marktpreise ab. Seither haben sich die Preise nicht nur nach unten bewegt: Mehrere Anbieter von Cloud Object Storage haben ihre Listenpreise 2026 angehoben. Weder die damaligen Cloud- noch die damaligen Hardwarepreise lassen sich deshalb auf heutige Angebote übertragen. 

Übertragbar ist etwas anderes. Das Ergebnis eines Kostenvergleichs verändert sich mit dem gewählten Betrachtungszeitraum, und eine Einjahresbetrachtungkann zu einer anderen Schlussfolgerung führen als eine Fünfjahresbetrachtung derselben Architektur. Bei On-Premises kommen Reservekapazität und zukünftige Erweiterungen hinzu, die im ersten Jahr als Kosten sichtbar sind, ihren Nutzen aber erst später entfalten. Die vollständige wirtschaftliche Betrachtung gehört deshalb in eine TCO-Analyse und nicht in einen isolierten Vergleich des Preises pro Terabyte [QUERVERWEIS: TCO von Storage-Infrastrukturen]. 

Zwei Betriebsformen aus unserer Projektpraxis 

Wie unterschiedlich die Ausgangslagen sein können, zeigen zwei Projekttypen aus unserer Praxis: eine On-Premises-Plattform, deren Betriebsform vorgegeben war, und die Nutzung von Cloud Object Storage als Backup Target, die sich aus dem Anwendungsfall selbst ergibt. 

On-Premises: Scality RING in einem CTERA-Projekt 

In einem von uns begleiteten CTERA-Projekt kam Scality RING als On-Premises-Object-Storage-Plattform zum Einsatz. Die Vorgabe für die lokale Betriebsform kam vom Kunden: Eine Cloud-Lösung war für dieses Projekt nicht vorgesehen. 

Die Plattform wurde zunächst als gespiegelte Konfiguration über zwei Standorte betrieben und später auf eine standortübergreifende Stretched-Konfiguration umgestellt. Diese Umstellung zeigt einen bei On-Premises-Architekturen häufig unterschätzten Punkt: Die Verteilung über Failure Domains ist keine einmalige Designentscheidung, sondern kann sich über den Lebenszyklus einer Plattform verändern. Nach der ursprünglichen Verwendung wurde die vorhandene Object-Storage-Infrastruktur zusätzlich als Backup Target weitergenutzt. 

Das Projekt zeigt zugleich, dass nicht jede Auswahl mit einem offenen Vergleich sämtlicher Betriebsmodelle beginnt. Eine organisatorische, regulatorische oder strategische Vorgabe kann den Lösungsraum vorher definieren, sodass nicht mehr die Betriebsform zur Entscheidung steht, sondern nur noch die dazu passende Object-Storage-Architektur. In einem anderen Projekt kann die Ausgangslage genau umgekehrt sein. Die technische Architektur muss deshalb nicht nur zum Workload passen, sondern auch die übergeordneten Rahmenbedingungen des Kunden erfüllen. 

Cloud: Object Storage als Backup Target 

In den von uns begleiteten Cloud-Object-Storage-Projekten wurde Cloud Object Storage bisher vor allem als Backup Target eingesetzt. Das ist architektonisch nachvollziehbar: Ein Backup-System benötigt nicht denselben Zugriffspfad wie produktiver Primary Storage, und die Speicherung außerhalb der lokalen Storage-Infrastruktur schafft eine zusätzliche Failure Domain. 

Mit einem vollständigen Backup- oder Cyber-Resilience-Konzept ist das allerdings nicht zu verwechseln. Das Schreiben einer Kopie in ein externes ObjectStorage beantwortet die Fragen nach Retention, Immutability, Zugriffsschutz, Recovery und RPO/RTO noch nicht. Diese Aspekte müssen separat geplant werden [QUERVERWEIS: Cyber Resilience im Storage-Umfeld]. 

Datenlokalität und digitale Souveränität sind nicht dasselbe 

Neben Performance, Kapazität und Kosten gewinnt ein weiteres Entscheidungskriterium an Bedeutung. Wir beobachten in Kundengesprächen zunehmend Anforderungen nach europäischen Storage- und Cloud-Lösungen. Thema ist dabei nicht nur, in welchem Land Daten gespeichert werden, sondern auch, welcher rechtliche und organisatorische Einfluss auf Anbieter, Infrastruktur und Daten bestehen kann. Diese Beobachtung deckt sich mit einer breiteren europäischen Diskussion über digitale und Cloud-Souveränität. 

Die Europäische Kommission behandelt Cloud-Souveränität inzwischen ausdrücklich mehrdimensional. Ihr Cloud Sovereignty Framework wurde im Oktober 2025 im Rahmen einer Ausschreibung für souveräne Cloud-Dienste der EU-Institutionen vorgestellt und 2026 durch eine Implementierungsleitlinie ergänzt. Es strukturiert Souveränität in acht Sovereignty Objectives: strategische, rechtliche und jurisdiktionelle, Data-&-AI-, operative, Supply-Chain-, technologische, Security- und Compliance-bezogene sowie umweltbezogene Aspekte. 

Ein regulatorisches Regelwerk ist das Framework nicht, sondern ein Bewertungsinstrument für die Beschaffung. Es kombiniert eine fünfstufige Skala für das erreichte Souveränitätsniveau mit einem gewichteten Gesamtscore, wobei das Gesamtniveau dem niedrigsten in einem einzelnen Objective erreichten Wert entspricht. Gerade diese Logik ist für eine Architekturbewertung interessant: Ein einzelner schwacher Bereich bestimmt das Ergebnis, unabhängig davon, wie gut die übrigen Kriterien erfüllt werden. 

Daraus folgt ein wichtiger Unterschied. Der Standort der Daten ist nur ein Bestandteil von Souveränität. Eine Cloud-Region in Deutschland oder einem anderen EU-Mitgliedstaat beantwortet noch nicht die Fragen nach rechtlicher Jurisdiktion, Kontrolle des Anbieters, technologischen Abhängigkeiten oder administrativen Zugriffsmöglichkeiten. Auch der EU Data Act adressiert diesen Punkt: Kapitel VII regelt den Umgang mit Zugriffs- und Herausgabeverlangen von Behörden und Gerichten aus Drittstaaten auf nicht personenbezogene Daten, die in der Union von Datenverarbeitungsdiensten gehalten werden. 

Für eine Architekturentscheidung sollten deshalb mindestens fünf Dimensionen getrennt betrachtet werden. 

Dimension 

Leitfrage 

Datenlokalität 

Wo werden Daten gespeichert und verarbeitet? 

Jurisdiktion 

Welchen rechtlichen Rahmenbedingungen unterliegen Anbieter und Datenverarbeitung? 

Operative Kontrolle 

Wer betreibt die Systeme und wer besitzt administrative Zugriffsmöglichkeiten? 

Technologische Abhängigkeit 

Von welchen Anbietern, Softwarekomponenten und Lieferketten hängt der Betrieb ab? 

Datenkontrolle 

Welche technischen und organisatorischen Mechanismen kontrollieren den Zugriff auf die Daten? 

Europäisches Rechenzentrum und souveräne Cloud sind deshalb nicht dasselbe. 

Hybride Architekturen zwischen beiden Modellen 

Zwischen einem vollständig lokalen und einem vollständig cloudbasierten Storage-Modell liegen Architekturen, die lokale Dienste mit Cloud ObjectStorage kombinieren. Ein verbreitetes Muster sieht einen lokalen File-Service mit Cache vor, der die Clients bedient, während das Cloud Object Storage über die WAN-Anbindung als zentrale Speicherebene dient [QUERVERWEIS: Public, Private und Hybrid Cloud]. 

[BILD 3: Hybride Architektur als horizontaler Schichtaufbau. Von links nach rechts: Clients, lokaler File-Service mit Cache innerhalb der Standortgrenze, WAN-Anbindung, Cloud Object Storage als persistente Ebene. Der lokale File-Service ist als eigene Schicht mit den Funktionen Protokollumsetzung, Cache und Synchronisation ausgewiesen.] 

Eine solche Architektur verändert den Datenpfad erheblich. Der Anwender arbeitet nicht unmittelbar gegen das entfernte Object Storage. Die zusätzliche Schicht stellt File-Protokolle, lokalen Cache und weitere Funktionen bereit, während Object Storage als persistente Storage-Ebene dient. 

Mit einem nativen Object-Storage-Zugriff ist das jedoch nicht gleichzusetzen. Die zusätzliche Schicht besitzt eigene Konsistenz-, Cache-, Synchronisations- und Failure-Eigenschaften, die in die Architekturplanung gehören. Wir setzen solche Architekturen insbesondere im Umfeld globaler File Services ein [QUERVERWEIS: Global File System]. 

Wann welche Betriebsform näher geprüft werden sollte 

Die folgenden Kriterien entscheiden nichts, sie zeigen, wo eine detaillierte Prüfung ansetzen sollte. 

Indikatoren für On-Premises 

Anforderung 

Technische Bedeutung 

Große Datenmengen entstehen lokal 

Daten können im lokalen Rechenzentrum verbleiben 

Hoher kontinuierlicher Datentransfer 

WAN muss nicht Bestandteil jedes Storage-Zugriffs sein 

Cloud ist organisatorisch ausgeschlossen 

Lokale Betriebsform wird zur Architekturvorgabe 

Kontrolle über Infrastruktur erforderlich 

Hardware und Storage-Plattform bleiben im eigenen Verantwortungsbereich 

Definierte Datenlokalität erforderlich 

Physischer Betriebsort kann unmittelbar festgelegt werden 

Vorhandene RZ-Infrastruktur 

Bestehende Ressourcen fließen in die TCO-Betrachtung ein 

Langfristig große Kapazität 

Wirtschaftlicher Vergleich über mehrere Jahre erforderlich 

Indikatoren für Cloud Object Storage 

Anforderung 

Technische Bedeutung 

Kapazität soll ohne eigene Hardware erweitert werden 

Provider stellt die physische Infrastruktur bereit 

Datenmenge wächst schwer vorhersehbar 

Keine vollständige Zielkapazität muss vorab installiert werden 

Object Storage dient primär als externes Backup Target 

Räumlich getrennte Storage-Infrastruktur wird bereitgestellt 

Eigener Storage-Betrieb soll reduziert werden 

Teile des Infrastruktur-Lifecycles liegen beim Provider 

Anwendungen befinden sich bereits in der Cloud 

Datenpfade können näher an der Cloud-Umgebung geplant werden 

Verbrauchsbasierte Kosten sind gewünscht 

Kapazität wird nach Tarif als Service abgerechnet 

Keines dieser Kriterien beweist für sich allein, dass eine Betriebsform technisch oder wirtschaftlich überlegen ist. Die Eignung hängt weiterhin vom konkreten Provider, Tarif, Datenpfad und Workload ab. 

Die Entscheidungsreihenfolge 

Eine Architekturentscheidung sollte nicht mit der Frage beginnen, was ein Terabyte kostet. Am Anfang stehen der Workload und die beteiligten Anwendungen, daraus leitet sich das benötigte Zugriffsmodell ab, also die Entscheidung zwischen Object, File und Block Storage [QUERVERWEIS: Cloud Storage: File, Block und Object]. Anschließend werden Datenmenge und Wachstum für den heutigen Bedarf sowie für einen Horizont von drei bis fünf Jahren bestimmt, und der Datenpfad wird analysiert: Wo befinden sich Anwendungen, Benutzer, Compute und Storage? 

Darauf aufbauend lassen sich die Performance-Anforderungen an Bandbreite, Latenz und Parallelität festlegen und die Betriebsanforderungen definieren, also die Verantwortung für Hardware, Plattform, Updates und Kapazität. Erst danach folgen die Anforderungen an Datenlokalität und Souveränität sowie der Kostenvergleich, der On-Premises und Cloud über denselben Zeitraum und mit identischen Kapazitäts- und Wachstumsszenarien betrachten muss. Die Festlegung der Betriebsform steht am Ende dieser Kette, nicht an ihrem Anfang. 

[BILD 4: Achtstufige Entscheidungskette als vertikale Abfolge von Workload über Zugriffsmodell, Datenmenge und Wachstum, Datenpfad, Performance, Betriebsanforderungen und Souveränität bis zum Kostenvergleich. Die Festlegung der Betriebsform steht als abgesetzter letzter Schritt am Ende. Jede Stufe trägt ihre Leitfrage als kurzen Text.] 

Die folgende Übersicht macht sichtbar, welche Fragen vor einer Entscheidung beantwortet sein müssen. Eine automatische Auswahlmatrix ist sie nicht. 

Frage 

On-Premises stärker prüfen 

Cloud stärker prüfen 

Wo entstehen die Daten? 

überwiegend eigenes RZ 

überwiegend Cloud 

Wie groß ist der kontinuierliche Datentransfer? 

sehr hoch und lokal 

WAN technisch ausreichend 

Wie planbar ist das Wachstum? 

gut planbar 

stark schwankend oder unsicher 

Soll Hardware selbst betrieben werden? 

ja 

nein 

Ist Cloud grundsätzlich zulässig? 

nein oder eingeschränkt 

ja 

Welche Kontrolle wird benötigt? 

Infrastrukturkontrolle erforderlich 

Provider-Verantwortung akzeptabel 

Welche Souveränitätsanforderungen bestehen? 

vollständig analysieren 

Provider und Betriebsmodell vollständig analysieren 

Wie soll bezahlt werden? 

Infrastrukturinvestition 

Service- und Verbrauchsmodell 

Wie lang ist der Betrachtungszeitraum? 

drei bis fünf Jahre oder Lifecycle 

gleicher Zeitraum erforderlich 

Ist Object Storage Backup Target? 

lokale Anforderungen prüfen 

häufig geeigneter Anwendungsfall 

Muss eine File-Schnittstelle bereitgestellt werden? 

zusätzliche Schicht prüfen 

zusätzliche Schicht prüfen 

Fazit 

Object Storage On-Premises und Cloud Object Storage basieren auf demselben Speichermodell, führen aber zu unterschiedlichen Infrastruktur- und Betriebsarchitekturen. Cloud Object Storage verschiebt Bereitstellung und Betrieb der physischen Storage-Infrastruktur zum Provider und ermöglicht eine bedarfsgerechte Nutzung von Kapazität. Dafür werden Netzwerkverbindung und Provider-Modell Bestandteile der Gesamtarchitektur. On-Premises ObjectStorage hält Infrastruktur und Datenpfade unter eigener Kontrolle, verlangt dafür aber Kapazitätsplanung, Reserve, Betrieb und Lifecycle-Management. 

Unsere Projekterfahrung zeigt zudem, dass Entscheidungen nicht ausschließlich aus technischen Performance-Kriterien entstehen. In einem Projekt war die Vorgabe, keine Cloud einzusetzen, ausschlaggebend für eine On-Premises-Architektur. Eine separate Kalkulation für rund 1 PB aus dem Frühjahr 2025 zeigte wiederum, wie stark der gewählte Betrachtungszeitraum das wirtschaftliche Ergebnis beeinflusst. Gleichzeitig gewinnen in aktuellen Kundengesprächen Anforderungen an europäische Lösungen und digitale Souveränität an Bedeutung. 

Die entscheidende Frage lautet damit nicht, ob Cloud oder On-Premises besser ist, sondern welche Betriebsform Datenpfad, Kapazität, Betrieb, Souveränität und Wirtschaftlichkeit des konkreten Workloads am besten erfüllt. 

Quellen

National Institute of Standards and Technology (NIST): Mell, Peter; Grance, Timothy: The NIST Definition of Cloud Computing, NIST Special Publication 800-145, September 2011. DOI 10.6028/NIST.SP.800-145. Abruf: 6. September 2026. NIST SP 800-145 – The NIST Definition of Cloud Computing

European Commission: Cloud Sovereignty Framework, Version 1.2.1, Directorate-General for Digital Services, Oktober 2025. Abruf: 6. September 2026. European Commission – Cloud Sovereignty Framework

European Commission: Cloud Sovereignty Framework – Implementation Guidance, 2026. Enthält die acht Sovereignty Objectives, die Assurance Levels und die Berechnungslogik des Sovereignty Score. Abruf: 6. September 2026. European Commission – Implementation Guidance

European Commission: Sovereign Cloud Framework explained, 1. Juni 2026. Abruf: 6. September 2026. European Commission – Sovereign Cloud Framework explained

European Commission: Data Act explained, Informationen insbesondere zu Kapitel VII und Artikel 32 zum Umgang mit Zugriffsverlangen von Drittstaatenbehörden auf nicht personenbezogene Daten. Abruf: 6. September 2026. European Commission – Data Act explained

Wasabi Technologies: Pricing FAQs for Wasabi's Pay as You Go Pricing Model. Dokumentation des Abrechnungsmodells einschließlich Storage, Egress, API Requests und Mindestaufbewahrungsdauer. Abruf: 6. September 2026. Wasabi – Pricing FAQs

Wasabi Technologies: Minimum Storage Duration Policy, aktualisiert 9. Januar 2026. Abruf: 6. September 2026. Wasabi – Minimum Storage Duration Policy

IONOS: IONOS Object Storage – Pricing Model, Produktdokumentation. Angaben zu Traffic-Abrechnung, kostenfreiem Ingress und Replikationsverkehr. Abruf: 6. September 2026. IONOS – Object Storage Pricing Model

Scality: Scality RING – Scalable Object Storage. Herstellerdokumentation als Hintergrund zur im Projekt eingesetzten On-Premises-Object-Storage-Technologie. Produktspezifische Aussagen wurden nicht auf Object Storage allgemein übertragen. Abruf: 6. September 2026. Scality RING

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

Information icon

Wir benötigen Ihre Zustimmung zum Laden der Übersetzungen

Wir nutzen einen Drittanbieter-Service, um den Inhalt der Website zu übersetzen, der möglicherweise Daten über Ihre Aktivitäten sammelt. Bitte überprüfen Sie die Details in der Datenschutzerklärung und akzeptieren Sie den Dienst, um die Übersetzungen zu sehen.