2026-04-22 · 8 Min. Lesezeit

Hetzner Object Storage vs. AWS S3 für EU-Backup-Stacks

Kosten, Rate-Limits, Haltbarkeit und Datenspeicherort: ein praxisnaher Vergleich für EU-Backup-Stacks.

Resistro Cloud speichert Backups auf Hetzner Object Storage in Nürnberg. Für EU-basierte Backup-Stacks ist AWS S3 in Frankfurt der naheliegende Vergleichspunkt — die APIs sind identisch, das Tooling ist überall. Dies ist ein praxisnaher Vergleich auf Basis von Betriebsbedingungen, Kosten und einem frühen Skalierungsproblem, das wir gezielt lösen mussten.

Kosten bei 1 TB / Monat

Speicherkosten sind der erste Blickfang — und sie spielen ab 500 GB wirklich eine Rolle. Preise netto ohne MwSt., Stand April 2026:

Hetzner Object Storage AWS S3 (eu-central-1)
1 TB gespeichert / Monat ~6 € (erstes TB im Bucket enthalten) ~21 €
Egress 100 GB / Monat 0 € (innerhalb Hetzner) / niedrig extern ~8 €
PUT/COPY/POST pro Million ~0,55 € (ca.) ~4,40 €
GET pro Million ~0,055 € ~0,35 €

Für eine typische Mittelstands-Backup-Workload — 200 GB verschlüsselte Dumps pro Woche, selten abgerufen — liegt die reine Speicherrechnung bei AWS ca. 3–4× über Hetzner. Die request-basierten APIs (PUT, LIST) treiben den Unterschied weiter, wenn die Workload kleinteilig ist. Ein 200–500 GB Backup-Stack der von S3 eu-central-1 auf Hetzner Object Storage wechselt, spart typischerweise 200–300 € pro Monat bei identischer Retention; der genaue Wert hängt davon ab, wie oft man die Daten anfasst.

Allerdings: AWS gewinnt im Sub-TB-Bereich (unter 50 GB) dank Free Tier, und ist bei hot tiers mit häufigem Zugriff oft günstiger als erwartet.

Rate-Limits — das eine, das wirklich beißt

Das ist die Falle, die für alle mit Multi-Tenant-Aufbau relevant ist:

  • Hetzner Object Storage: ~750 Requests/Sekunde pro Bucket (dokumentiertes Soft-Limit, in der Praxis bestätigt).
  • AWS S3: 3.500 PUT/COPY/POST/DELETE pro Sekunde pro Prefix, 5.500 GET pro Sekunde pro Prefix — und das Limit skaliert automatisch mit zunehmender Prefix-Verteilung.

Der Unterschied: AWS begrenzt pro Prefix, von denen man beliebig viele anlegen kann. Hetzner begrenzt pro Bucket, fertig. Wer alle Kunden-Backups unter /tenant-abc/… und /tenant-xyz/… ablegt, teilt trotzdem ein gemeinsames 750/s-Budget über alle Tenants.

Der Fehler, der uns zum Sharding gebracht hat

Anfangs speicherte Resistro Cloud Objekte als <tenant-uuid>/<backup-uuid>.backup. Bei zwei Kunden kein Problem. Bei 50 Kunden mit stündlichen Backups und ~3 Operationen pro Backup (PUT + HEAD + COMPLETE) bleibt man rechnerisch im Budget. In der Praxis ist die Last jedoch bursty — 30 Kunden, die zur vollen Stunde triggern, können 750/s überschreiten.

Der Fix dauerte einen Nachmittag: den Key mit zwei Hex-Zeichen aus einem SHA-256-Hash der Tenant-UUID voranstellen.

shard = hex(sha256(tenant_id.bytes)[0])  // „37" / „c9" / „f2" / …
key   = <shard>/<tenant-uuid>/<backup-uuid>.backup

256 mögliche Shards, annähernd gleichmäßige Verteilung. Aus Hetzners Sicht hat der Bucket 256 unabhängige Schreiboberflächen, weil deren internes Partitioning am Prefix ansetzt. Das 750/s-Bucket-Limit wird effektiv ~2,9/s pro Shard — weit über dem, was ein einzelner Tenant produziert.

Migrationskosten: null für neue Backups (neuer Code-Pfad), alte Objekte bleiben wo sie sind, die Datenbank hält den vollständigen Pfad pro Backup-Datensatz vor.

Haltbarkeit und Garantien

Beide Anbieter versprechen „Elf Neunen" Haltbarkeit für gespeicherte Objekte. Der Vorbehalt gilt für beide: Diese Zahl schützt davor, dass der Anbieter die Daten verliert — nicht davor, dass die Daten noch korrekt sind. Bit-Rot wird verhindert; ein PUT von Datenmüll nicht.

Praktische Unterschiede:

  • AWS hat regionsübergreifende Replikation als Produkt. Hetzner nicht; das baut man selbst mit einem zweiten Bucket in der fsn1-Region.
  • AWS hat Object Lock / Compliance Mode für WORM mit Legal Hold. Hetzner hat Object Lock im Governance Mode. Beide reichen für Standard-Backup-WORM; eine SEC-17a-4-Bestätigung liefert keiner von beiden.
  • AWS hat S3 Intelligent-Tiering, das kalte Objekte automatisch in günstigere Storage-Klassen verschiebt. Hetzner kennt nur eine Tier.

Datenspeicherort und Verarbeitungsrecht

Die Frage, die DACH-Einkäufer wirklich interessiert:

  • Hetzner: GmbH, Gunzenhausen, Deutschland. Vertrag, Rechnung, Support — alles auf Deutsch, deutsches Recht. BSI-C5-geprüft, ISO 27001. Im Standard-Resistro-Speicherpfad gibt es keinen US-Anbieter-CLOUD-Act-Pfad.
  • AWS eu-central-1: Daten liegen in Frankfurt, aber AWS-Europa-Einheiten werden letztlich von Amazon.com Inc. (USA) kontrolliert. Nach dem US CLOUD Act können betroffene Anbieter verpflichtet werden, Daten herauszugeben, die in ihrem Besitz, ihrer Verwaltung oder ihrer Kontrolle liegen — unabhängig vom Speicherort.

Für bestimmte regulierte DACH-Kunden können Anbieter-Jurisdiktion und Verarbeitungsstruktur schwerer wiegen als reine Speicherkosten oder technische Möglichkeiten.

Betriebliche Ergonomie

Wo AWS weiterhin gewinnt:

  • CLI-Tooling. aws s3 sync, IAM-Policies, Presigned URLs sind gut dokumentiert und kampferprobt.
  • Dokumentation. Jeder Grenzfall hat einen Stack-Overflow-Thread.
  • SDK-Abdeckung. Jede Sprache hat ein AWS SDK, das funktioniert.

Wo Hetzner ausreicht, aber mehr Einrichtungsaufwand erfordert:

  • CLI ist mcli (MinIO Client). Funktioniert, aber nicht so ausgereift wie aws s3.
  • Kein IAM — Zugriff über bucket-scoped Credentials. Für ein Single-Product-SaaS kein Problem.
  • S3-kompatible API funktioniert mit jedem SDK; braucht nur einen Endpoint-Override.

Ehrliches Fazit: Wer schon in AWS lebt und kostensensitivität keine Rolle spielt, ist mit S3 gut beraten. Wer für EU-Kunden baut und Kosten eine Rolle spielen, fährt mit Hetzner als Standard besser.

Wann welche Lösung

Situation Empfehlung
Unter 50 GB, bereits auf AWS Auf S3 bleiben. Wechsel lohnt nicht.
100 GB – 5 TB, reine EU-Kunden Hetzner. Kosten und Datenspeicherort gewinnen beide.
> 5 TB oder regulierter Mittelstand Hetzner als Primär + AWS Deep Archive für vierteljährliche Offsite-Kopie. Zwei-Anbieter-Strategie ist günstige Absicherung.
S3 Intelligent-Tiering oder CRR benötigt AWS. Hetzner spielt hier nicht mit.
Multi-Tenant-SaaS, vorhersehbares Rate-Limit-Budget gebraucht Beides — aber Prefixes von Tag eins an sharden.

In der Praxis hängt die Entscheidung von zwei Dingen ab: ob AWS-Betriebsexpertise bereits im Haus vorhanden ist, und wie stark Kosten und Anbieter-Jurisdiktion im Einkauf zählen. Keine Lösung ist universell die richtige.