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 wieaws 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.
