S3 Object Storage in Europa: Was Sie bewerten sollten, bevor Sie ein einziges Byte speichern

• S3-Kompatibilität ist ein Spektrum. Manche Anbieter implementieren die Grundlagen; nur wenige liefern das vollständige Protokoll mit konsistenter Zuverlässigkeit im großen Maßstab.
• Die Zuverlässigkeit von Object Storage hängt von der Architektur ab, nicht von Versprechen. Verteilte Architekturen über mehrere Standorte sind grundsätzlich widerstandsfähiger als Einzelstandort-Setups.
• Datensouveränität ist für europäische Organisationen eine gesetzliche Pflicht, kein Marketing-Häkchen. Wissen Sie genau, wo Ihre Objekte landen und unter wessen Rechtsprechung.
• Preismodelle variieren stark. API-Anfragegebühren, Abrufkosten und Egress-Kosten können Ihre effektiven Speicherkosten verdoppeln oder verdreifachen.

Jeder europäische Speicheranbieter behauptet S3-Kompatibilität. Fast keiner von ihnen spezifiziert, was das tatsächlich für Ihre Workloads bedeutet.

Die S3-API-Oberfläche ist groß. Grundlegende Operationen — PUT, GET, DELETE, Buckets auflisten — sind relativ einfach zu implementieren. Aber Produktions-Workloads hängen von einem wesentlich breiteren Funktionsumfang ab: multipart uploads, Versionierung, lifecycle policies, bedingte Schreibvorgänge, CORS-Konfiguration, pre-signed URLs und granulare Zugriffskontrolle über bucket policies. Die Lücke zwischen „unterstützt S3“ und „implementiert S3 vollständig“ ist der Punkt, an dem Anwendungen abbrechen, Migrationen stocken und Backup-Jobs stillschweigend fehlschlagen.

Manche Anbieter erzwingen Write-Once-Semantik — das heißt, Sie können ein bestehendes Objekt nicht aktualisieren oder überschreiben. Das ist eine legitime Designentscheidung für Archivierungs-Workloads, aber es ist grundsätzlich inkompatibel mit Anwendungen, die Standard-S3-Verhalten erwarten. Wenn Ihre Anwendung Objekte als Teil ihres normalen Workflows schreibt, aktualisiert und liest, wird eine WORM-only-Implementierung sie auf eine Weise beschädigen, die bei anfänglichen Tests nicht sofort offensichtlich ist.

Testen Sie vor der Datenübergabe Ihren tatsächlichen Workflow gegen den Zielspeicher. Keinen synthetischen Benchmark — Ihr echtes Backup-Tool, Ihre echte Anwendung, Ihre echten Datenmuster. Lassen Sie es eine Woche laufen, nicht einen Nachmittag.

Die Verfügbarkeit von Object Storage ist eines dieser Dinge, über die niemand nachdenkt, bis es ausfällt. Und wenn es ausfällt, tendiert es dazu, kaskadierend zu versagen — Backups können nicht abgeschlossen werden, Anwendungs-Assets werden unverfügbar, Compliance-Archive werden genau dann unzugänglich, wenn ein Prüfer sie braucht. Manche Teams haben berichtet, dass ihr Speicher tagelang nicht verfügbar war, nicht stundenlang. Ab diesem Punkt haben Sie keine Infrastruktur. Sie haben eine Haftungsposition.

Die Zuverlässigkeit jedes Speicherdienstes ist eine direkte Funktion seiner Architektur. Zwei Fragen sind wichtiger als jede SLA-Zahl auf einer Website:

• Wie werden Daten verteilt? Ein Object Store an einem einzelnen Standort ist ein Single Point of Failure, egal wie viele Festplatten er betreibt. Wenn alle Ihre Objekte in einer Einrichtung stehen, nimmt ein Stromausfall, eine Netzwerkpartition oder ein Kapazitätsengpass in dieser Einrichtung alles gleichzeitig offline. Manche Anbieter bieten überhaupt keine Replikation — nicht einmal innerhalb derselben Region. Ihre Daten existieren an einem Ort, in einer Kopie, und wenn diese Einrichtung ein Problem hat, geht der Dienst einfach ohne Failover vom Netz. Multi-Standort-Architekturen, bei denen Daten verschlüsselt, fragmentiert und über mehrere unabhängige Standorte verteilt werden, bieten grundlegend andere Ausfallcharakteristiken. Der Unterschied ist wichtig: Ein Dienst, der Daten über drei unabhängige Einrichtungen spiegelt, kann einen gesamten Standort verlieren, ohne ein einziges Byte zu verlieren.
• Was passiert unter Last? Manche Speicherplattformen funktionieren bei moderater Auslastung gut, degradieren aber scharf, wenn die Kapazität sich füllt oder Anforderungsraten sprunghaft ansteigen. Timeouts, fehlgeschlagene Schreibvorgänge und verminderte Leistung während Spitzennutzung sind Symptome einer Architektur, die für einen kleineren Workload dimensioniert wurde, als sie jetzt trägt. Dies ist besonders tückisch, wenn die Degradation standortabhängig ist — eine Rechenzentrumsregion funktioniert einwandfrei, während eine andere durchgängig überlastet ist, weil die Nachfrage die Kapazität überstiegen hat. Fragen Sie Ihren Anbieter, was bei 80% Auslastung passiert. Wenn er nicht mit Einzelheiten antworten kann, ist das die Antwort.

Hier stellt sich eine breitere Reifefrage. S3 als Protokoll existiert seit fast zwei Jahrzehnten. Es ist eine gut verstandene, gut dokumentierte Schnittstelle. Das Tooling ist ausgereift. Die Client-Bibliotheken sind praxiserprobt. Einen zuverlässigen S3-kompatiblen Dienst zu bauen ist kein Forschungsproblem — es ist eine Engineering- und Betriebsherausforderung, die ordentliche Kapazitätsplanung, Redundanzdesign und operative Disziplin erfordert. Wenn ein Anbieter seinen Object Storage vor über einem Jahr gestartet hat und dieser noch immer die Art von Zuverlässigkeitsproblemen zeigt, die man von einem Beta-Produkt erwarten würde, sagt das etwas über die zugrunde liegende Architektur aus, nicht darüber, wie schwer S3 zu implementieren ist.

Für europäische Organisationen hat sich die Frage, wo Ihre Daten physisch gespeichert sind, von einem Nice-to-have zu einer gesetzlichen Verpflichtung entwickelt. Die DSGVO ist seit 2018 in Kraft, aber die Durchsetzung wird intensiver. Die nationalen NIS2-Umsetzungen werden 2026 in den EU-Mitgliedstaaten ausgerollt, wobei Artikel 21 ausdrücklich Risikobewertungen der Lieferkette verlangt — einschließlich der Infrastrukturanbieter, von denen Sie abhängen.

Gartner prognostiziert Ausgaben für souveräne Cloud-Infrastruktur von etwa 80 Milliarden USD im Jahr 2026, wobei die europäische souveräne Cloud um rund 83% im Jahresvergleich wächst. Dies ist kein Nischenthema. Es ist die Richtung, in die sich der Markt bewegt, getrieben durch Regulierung, Corporate Governance und die praktische Realität, dass der Nachweis der Datenresidenz zu einer Beschaffungsanforderung für Unternehmensverträge wird.

Bei der Bewertung von Object Storage bedeutet souverän mehr als eine Flagge auf einem Rechenzentrum. Es bedeutet: europäisches Unternehmen, europäische Infrastruktur, europäische Rechtsprechung und kein rechtlicher Mechanismus, durch den eine ausländische Regierung Zugang zu Ihren Daten erzwingen kann. Wenn Ihr Anbieter nicht alle vier nachweisen kann, hat Ihre Compliance-Position eine Lücke.

Das schafft ein praktisches Dilemma. Die am häufigsten empfohlenen S3-kompatiblen Alternativen — Cloudflare R2, Backblaze B2, Wasabi — sind alle US-amerikanische Unternehmen. Sie betreiben möglicherweise europäische Rechenzentren, aber die Muttergesellschaft unterliegt weiterhin US-Recht, einschließlich dem CLOUD Act. Für europäische Organisationen, die sowohl zuverlässigen S3-Speicher als auch echte Datensouveränität benötigen, war die Liste der Anbieter, die beide Kriterien erfüllen, historisch gesehen sehr kurz. Das beginnt sich zu ändern, aber es bedeutet, dass Sie die Unternehmensstruktur Ihres Speicheranbieters bewerten müssen, nicht nur die Rechenzentrumsadresse.

Object-Storage-Preise haben ein Transparenzproblem. Der Schlagzeilenpreis — ein paar Euro pro Terabyte pro Monat — sieht übersichtlich aus, bis man untersucht, wofür man sonst noch bezahlt.

Eine aktuelle Befragung von über 400 IT-Führungskräften ergab, dass 95% auf unerwartete Kosten auf ihren Cloud-Speicherrechnungen gestoßen sind. Fast die Hälfte der gesamten Speicherkosten entfiel auf Gebühren jenseits der Basis-Speicherkapazität — API-Anfragegebühren, Datenabrufgebühren, Replikationszuschläge, Kosten für Speicherklassenwechsel und Egress-Bandbreite. Bei einem großen Hyperscaler fügte das etwa 41% zum Speicherkapazitätspreis hinzu.

Vergleichen Sie bei der Preisbewertung nicht isoliert den Preis pro Terabyte. Modellieren Sie Ihr tatsächliches Nutzungsmuster: wie viel Daten Sie speichern, wie oft Sie schreiben und lesen, wie viel Bandbreite Ihre Anwendungen verbrauchen und was es kosten würde, Ihre Daten herauszuziehen, wenn Sie wechseln müssten. Der günstigste Speicherpreis ist bedeutungslos, wenn die Betriebskosten die Rechnung verdoppeln.

Wenn Sie Ihren eigenen Object Storage mit Open-Source-Software betreiben, hat sich die Landschaft im vergangenen Jahr erheblich verändert.

MinIO, der am weitesten verbreitete Open-Source S3-kompatible Object Store, wechselte 2021 von Apache 2.0 zur AGPLv3-Lizenz. Seitdem hat die Community Edition schrittweise Funktionen verloren — die webbasierte Admin-Oberfläche wurde 2025 entfernt, und das Community-Repository ging in den Wartungsmodus, bevor es Anfang 2026 archiviert wurde. Eine Migrationshilfe wurde nicht bereitgestellt. Für Teams, die ihre Speicherinfrastruktur auf MinIOs Community Edition aufgebaut hatten, schuf dies eine dringende Notwendigkeit, Alternativen zu evaluieren.

Alternativen existieren — RustFS, Garage, SeaweedFS, Ceph RGW — aber den meisten fehlt der kommerzielle Support, die Ökosystemreife und die kampferprobte Produktionserfahrung, die MinIO über Jahre aufgebaut hat. Für Organisationen, die ihre Speicherschicht nicht auf ein kleines Open-Source-Projekt setzen wollen, oder die die Engineering-Investition für den Eigenbetrieb und die Wartung eines Speicher-Clusters nicht rechtfertigen können, ist verwalteter S3-kompatibler Speicher von einem vertrauenswürdigen Anbieter eine attraktivere Option geworden als noch vor zwei Jahren.

Dies ist kein Argument gegen selbst gehosteten Speicher. Wenn Sie das Team, die Expertise und die operative Bereitschaft haben, gibt Ihnen der Betrieb Ihres eigenen Object Store maximale Kontrolle. Aber wenn Sie ehrlich sind über die Kosten, einen Speicher-Cluster rund um die Uhr gesund, gepatcht und leistungsfähig zu halten, ist der Vergleich mit einem verwalteten Dienst es wert, gründlich durchgeführt zu werden.

Ob Sie zum ersten Mal Object Storage wählen oder Ihren aktuellen Anbieter überdenken — hier ist eine praktische Bewertungs-Checkliste:

1. Protokollvollständigkeit. Unterstützt der Anbieter die vollständige S3-API-Oberfläche, die Ihre Workloads erfordern? Versionierung, lifecycle policies, multipart uploads, bedingte Schreibvorgänge, bucket policies? Fordern Sie eine Kompatibilitätsmatrix an, bevor Sie testen.
2. Architektur und Redundanz. Wo werden Daten physisch gespeichert? Wie viele unabhängige Standorte? Was ist das Replikationsmodell? Einzelstandort-Speicher mit RAID ist nicht dasselbe wie geo-verteilter Speicher über mehrere Einrichtungen.
3. Leistung unter Last. Welche dokumentierten Rate Limits gibt es pro Bucket? Was passiert bei hoher Auslastung? Fragen Sie nach konkreten Angaben zum Degradationsverhalten und zur Kapazitätsplanung. Vage Antworten über unbegrenzte Skalierung sind ein Warnsignal.
4. Datensouveränität. Ist der Anbieter ein europäisches Unternehmen, das europäische Infrastruktur betreibt? Werden die Daten ausschließlich innerhalb der EU-Grenzen gespeichert? Gibt es einen rechtlichen Pfad für den Zugriff durch eine nicht-EU-Regierung? Können Sie die Residenz in einem Audit nachweisen?
5. Kostentransparenz. Wie sehen die Gesamtkosten für Ihr tatsächliches Nutzungsmuster aus, einschließlich API-Anfragen, Abrufkosten, Bandbreite und potenzieller Egress-Kosten? Sind die Preise von Monat zu Monat vorhersehbar, oder variabel basierend auf Nutzung, die Sie nicht vollständig kontrollieren können?
6. Verschlüsselung und Sicherheitsmodell. Sind Daten verschlüsselt at rest und in transit? Wer hält die Verschlüsselungsschlüssel? Kann ein einzelner kompromittierter Knoten vollständige Objekte offenlegen, oder sind Daten so fragmentiert, dass eine Rekonstruktion von einem einzelnen Standort ausgeschlossen ist?
7. Support und operative Reife. Wie sieht der Support um 3 Uhr morgens an einem Samstag aus, wenn Ihr Speicher ausgefallen ist und Ihre Anwendung nicht funktioniert? Können Sie tatsächlich einen Menschen erreichen, oder funktioniert das Support-Formular selbst nicht? Das ist kein hypothetisches Szenario — es gibt Anbieter, deren Kontaktmechanismen genauso unzuverlässig sind wie die Dienste, die sie unterstützen sollen. Achten Sie auf veröffentlichte durchschnittliche Antwortzeiten, 24/7-Verfügbarkeit und eine Erfolgsbilanz beim Lösen von Problemen, nicht nur beim Zur-Kenntnis-Nehmen.
8. Abzugskosten. Wie viel würde es kosten, Ihre Daten zu einem anderen Anbieter zu verschieben? Egress-Preise sind das klarste Signal dafür, ob ein Anbieter darauf vertraut, Sie durch Servicequalität zu halten — oder durch finanzielles Lock-in.

Worldstream hat kürzlich S3-kompatiblen Object Storage auf Basis der DS3 Composer-Technologie von Cubbit gestartet. Die Architektur ist um die oben beschriebenen Prinzipien herum konzipiert: Daten werden verschlüsselt, fragmentiert und über drei unabhängige Worldstream-Rechenzentren in den Niederlanden verteilt. Kein einzelnes Datenfragment existiert in lesbarer Form an einem einzelnen Standort, was Widerstandsfähigkeit sowohl gegen Vorfälle auf Einrichtungsebene als auch gegen Cyberangriffe bietet.

Der Technologie-Stack ist zu 100% europäisch. Worldstream ist ein niederländisches Unternehmen, das seine eigenen Rechenzentren und Netzwerkinfrastruktur betreibt. Cubbit ist ein italienisches Unternehmen, das die verteilte Speicher-Softwareschicht liefert. Es gibt kein US-amerikanisches Unternehmen in der Kette, was bedeutet, dass es keine CLOUD-Act-Exposition gibt. Für Organisationen, die DSGVO- und NIS2-Lieferkettenanforderungen navigieren, ist das eine unkomplizierte Compliance-Position.

Der Dienst unterstützt Standard-S3- und Swift-Protokolle. 24/7-Support mit einer veröffentlichten durchschnittlichen Antwortzeit von 7 Minuten. Die Architektur ist für null technologisches Lock-in konzipiert — Ihre Daten sind über Standard-S3-Tooling zugänglich, und Sie sind nie von proprietärer Client-Software oder APIs abhängig.

Das ist das sachliche Bild. Ob es zu Ihrem Workload passt, hängt von Ihren spezifischen Anforderungen an Protokollunterstützung, Leistung und Preisgestaltung ab. Wir möchten lieber, dass Sie gründlich evaluieren und die richtige Wahl treffen, als dass Sie eine Entscheidung auf Basis einer Verkaufsseite fällen.

Object Storage ist langweilige Infrastruktur. Es soll langweilig sein — man schreibt Daten, man liest Daten, sie sind da, wenn man sie braucht. Die interessante Frage ist, was passiert, wenn diese Annahme bricht. Wenn eine Einrichtung offline geht. Wenn die Auslastung die Kapazität erreicht. Wenn eine Regierung Zugang verlangt. Wenn man gehen will. Wenn man Hilfe braucht und tatsächlich jemand abhebt.

Die Anbieter, die diese Fragen mit Architektur beantworten und nicht mit Marketing, sind diejenigen, bei denen es sich lohnt, ein Petabyte zu speichern.