S3-Egress im vierstelligen Bereich? Schritt für Schritt zu R2 migrieren – 90 % Kosten sparen (mit Praxisbeispielen)

Auf der AWS-Rechnung: Speicher nur 230 $, Egress aber 4.500 $ – bei 50 TB Traffic wird es teuer. Mit Bekannten aus Video- und Bildhosting-Services ist das ein Dauerthema. Ein SaaS-Betreiber berichtete: 10 TB Traffic/Monat, S3-Rechnung 891 $ – Speicher nur 15 $, Egress ~98 %.

Bei Cloudflare R2? Null Egress-Gebühren – dieselben 10 TB Traffic, R2 berechnet nur Speicher (~15 $). Dieser Artikel: reale Kostenszenarien, API-Kompatibilität im Test, 30-Minuten-Migration und Fallstricke. Bei hohem Traffic (über 500 GB/Monat) können Sie jährlich Tausende bis Zehntausende Dollar sparen.

Warum von S3 zu R2 migrieren? Zahlen statt Marketing

Die versteckte Kostenfalle bei S3

Die AWS-Preisstruktur wirkt harmlos: Speicher 0,023 $/GB – „günstig“. Sobald Traffic fließt, dominiert Egress mit 0,09 $/GB.

Beispiel Video-Website: 10 TB gespeichert, 50 TB Traffic/Monat (Streaming/Download):

• Speicher: 10 TB × 23 $/TB = 230 $/Monat
• Egress: 50 TB × 90 $/TB = 4.500 $/Monat
• Gesamt: 4.730 $/Monat

Egress macht ~95 % aus – und das bei 0,09 $/GB; kleine Volumen haben oft keine Rabatte.

Ein Bildhosting-Anbieter mit 20 TB/Monat: S3-Rechnung ~20.676 $/Jahr – „Speicher nur 276 $, der Rest Egress – fühlt sich an wie Arbeit für AWS.“

Wo R2 wirklich spart

Cloudflare R2s stärkstes Argument: null Egress-Gebühren.

Nicht reduziert – 0 $. Ob 1 TB oder 100 TB Traffic: keine Egress-Rechnung. Für traffic-intensive Apps ein Game Changer.

Kostenaufschlüsselung:

• Speicher: 0,015 $/GB = 15 $/TB (ca. 35 % unter S3)
• Egress: 0 $ (S3: 90 $/TB)
• Operationen: Class A 4,50 $/Mio., Class B 0,36 $/Mio.

Free-Tier:

• 10 GB Speicher
• 1 Mio. Class-A-Operationen (Schreiben, Listen)
• 10 Mio. Class-B-Operationen (Lesen)

Kleine Blogs oder Hobby-Projekte können komplett im Free-Tier bleiben.

Reale Szenarien im Vergleich

Beim SaaS-Szenario: ~10.896 $/Jahr Ersparnis – für ein Startup oft ein Junior-Gehalt.

Video-Plattform: ~54.960 $/Jahr – Budget für Marketing oder Hiring statt Egress.

Wann sich Migration nicht lohnt

Ehrliche Grenzen – sonst migrieren Sie und sind enttäuscht:

1. Tiefe AWS-Integration: Lambda, Athena, EMR stark genutzt – hoher Refactoring-Aufwand.
2. Compliance: Object Lock, Legal Hold (Finanz, Gesundheit) – R2 derzeit nicht.
3. Wenig Traffic: unter 100 GB/Monat – Ersparnis oft nur wenige Dollar.
4. Strenge Residenz: S3 hat 33 Regionen; R2 weniger Optionen – Landesvorgaben vorher prüfen.

Meine Faustregel: ab ~500 GB/Monat lohnt ROI. Darunter hängt es von der Kostensensibilität ab.

R2 und S3: API-Kompatibilität (inkl. Fallstricke)

Wie kompatibel ist R2 wirklich?

Die zentrale Frage: Stürzt die App ab? Wie viel Code muss geändert werden?

Praxistest: R2 deckt 80–90 % der Kern-S3-API ab – Alltagsoperationen funktionieren.

Cloudflare fokussiert die meistgenutzten Teile:

• Basis: PutObject, GetObject, DeleteObject, ListObjects (~99 % der Fälle)
• Erweitert: Multipart Upload, Presigned URLs, CORS
• Berechtigungen: Bucket Policies, IAM-ähnliche Access Keys

Oft reichen Endpoint-URL und Credentials – der Rest bleibt.

Beispiel AWS SDK for JavaScript – Migration in drei Zeilen:

// Ursprüngliche S3-Konfiguration
const s3 = new AWS.S3({
  region: 'us-east-1'
});
// Migration zu R2 (nur Endpoint und Credentials)
const r2 = new AWS.S3({
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  accessKeyId: R2_ACCESS_KEY_ID,
  secretAccessKey: R2_SECRET_ACCESS_KEY,
  signatureVersion: 'v4',
});

Upload, Download, Delete unverändert. In meinen Tests zwei Wochen ohne Kompatibilitätsprobleme.

Was fehlt (Vorsicht vor der Migration)

R2 ist kein 1:1-Ersatz für jedes S3-Feature:

1. S3 Select (SQL auf Objekten)

SQL direkt auf S3-Objekten – R2 unterstützt das nicht. Daten herunterladen und lokal/abwärts verarbeiten oder Alternative wählen.

2. Object Lock und Legal Hold

WORM-Anforderungen in regulierten Branchen – R2 derzeit nicht. Compliance-Audit vorher klären.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

3. Versioning

S3-Versioning in R2 nur eingeschränkt – bei starker Abhängigkeit von Rollbacks gründlich testen.

4. Erweiterte Analyse

S3 Inventory, S3 Object Lambda – nicht verfügbar.

Empfehlung: Genutzte S3-Features auflisten und mit der offiziellen Cloudflare-Kompatibilitätsliste abgleichen. Die meisten Apps nutzen nur Basis-APIs.

Tool-Kompatibilität im Test

rclone ≥ 1.59 – ältere Versionen hatten Auth-Probleme.

Ein Fallstrick aus der Praxis

Eine App nutzte ListObjectsV2 mit StartAfter für Pagination. Nach R2-Migration wich das Verhalten leicht ab – einige Objekte fehlten in der Liste.

Lösung: auf ContinuationToken umstellen – dann stabil.

Lektion: Nach Migration gründlich testen – nicht nur Happy Path, auch Grenzfälle und Pagination.

Drei Migrationswege im Vergleich

Cloudflare bietet Super Slurper und Sippy; die Community nutzt rclone. Die Wahl hängt vom Szenario ab.

Weg 1: Super Slurper (Einsteiger, einmalige Migration)

Offizielles One-Click-Tool für „alles auf einmal umziehen“.

Vorteile:

• Einfache UI, wenige Formularfelder
• Metadaten bleiben (metadata, content-type)
• Quelldaten in S3 bleiben – null Risiko
• Kostenlos (nur R2 Class-A-Operationen, günstig)
• Seit 2024 deutlich schneller (ca. 5×)

Nachteile:

• Kein inkrementeller Sync
• Neue Uploads nach Start landen nicht automatisch in R2
• Einzelobjekte ideal unter 50 GB

Für wen:

• Unter 10 TB Daten
• Kurze Wartung ok oder Pre-Launch
• Vollständiger Wechsel zu R2

Mein erstes Projekt: 100 GB in ~30 Minuten. Wartungsfenster 3 Uhr nachts – Nutzer kaum betroffen.

Weg 2: Sippy (ohne Downtime, schrittweise)

Intelligente Migration ohne Stillstand.

Ablauf:

App zeigt auf R2. Bei Anfrage:

1. R2 prüft lokales Objekt
2. Vorhanden → direkte Auslieferung
3. Fehlt → von S3 holen, Kopie nach R2, nächstes Mal aus R2

Hot Data zuerst, Cold Data später.

Vorteile:

• Null Downtime
• S3-Egress sinkt mit der Zeit
• Beobachten und bei Bedarf zurück zu S3

Nachteile:

• Erster Zugriff auf fehlende Datei langsamer (S3-Fetch)
• Konfiguration aufwendiger
• Am besten bei klarem Hot/Cold-Muster

Für wen:

• Produktion ohne Wartung
• Über 10 TB – einmalige Migration zu lang
• Stabilität vor Full Cutover testen

Ein CDN-Anbieter migrierte 50 TB mit Sippy – zwei Monate im Hintergrund, Service ununterbrochen.

Weg 3: rclone (maximale Kontrolle)

Open-Source-Sync – mächtig, CLI-basiert.

Vorteile:

• Kostenlos, Open Source
• Resume bei Unterbrechung
• Geplanter Sync (z. B. nächtlich)
• Integritätsprüfung (MD5, SHA256)
• Bandbreitenlimit möglich

Nachteile:

• CLI und Skripte nötig
• Eigenes Monitoring der Migration
• Egress von S3 (seit März 2024 oft kostenlos bei Wegzug zu anderen Anbietern)

Für wen:

• Starke CLI-Kenntnisse
• Dauerhafter Dual-Write oder Sync-Phase
• Höchste Integritätsanforderungen

Typischer Befehl:

rclone copy s3:my-bucket r2:my-bucket \
  --progress \
  --checksum \
  --transfers 32 \
  --s3-chunk-size 64M

--checksum vergleicht MD5; --transfers 32 parallelisiert.

Schnelle Entscheidung

Downtime möglich?
├─ Ja → Weniger als 10 TB?
│      ├─ Ja → Super Slurper (einfachste Option)
│      └─ Nein → rclone (schnell, kontrollierbar)
└─ Nein → Sippy (ohne Downtime)
Technisch stark + volle Kontrolle → rclone

Für die meisten reicht Super Slurper. Nur bei absolut keiner Wartung oder sehr großen Datenmengen (über 50 TB) lohnt sich der Mehraufwand der Alternativen.

Praxis: Migration in 30 Minuten (Super Slurper)

Theorie reicht – hier die Schritte. Super Slurper: Konfiguration in ~30 Minuten (Übertragungszeit extra).

Schritt 1: Vorbereitung (5 Minuten)

1. Cloudflare-Konto und R2

Auf Cloudflare registrieren, in der Sidebar „R2 Object Storage“ aktivieren.

Hinweis: Kreditkarte nötig, Free-Tier deckt kleine Projekte oft ab.

2. R2-Bucket anlegen

„Create bucket“:

• Name (gleich wie S3 erleichtert Verwaltung)
• Location hint (EU bei Compliance, sonst Automatic)

⚠️ Location hint und jurisdictional restrictions sind danach nicht änderbar – meist reicht Automatic.

3. AWS nur-Lese-IAM-User

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Nicht den Hauptaccount-Key nutzen.

IAM → Users → Add User:

• Name: r2-migration-readonly
• Programmatic access
• Policy: AmazonS3ReadOnlyAccess

Oder restriktiver (nur ein Bucket):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

Access Key ID und Secret sofort speichern – einmalige Anzeige.

4. R2 API Token

R2 → Manage R2 API Tokens → Create:

• Name: migration-token
• Permissions: Object Read & Write
• Bucket auswählen

Keys ebenfalls sichern.

Schritt 2: Migration ausführen (15 Minuten Konfiguration)

1. Data Migration

R2-Konsole → „Data Migration“ → „Migrate Files“.

2. Super Slurper wählen

Zwei Optionen: Super Slurper (einmalig) und Sippy – hier Super Slurper.

3. Quell-Bucket (S3)

• Provider: Amazon S3
• Bucket name: z. B. my-images
• Bucket region: z. B. us-east-1
• Access Key ID / Secret vom IAM-User

„Verify Connection“ – grüner Haken bei Erfolg.

4. Ziel-Bucket (R2)

• Bucket name: R2-Bucket
• R2 Access Key ID / Secret vom Token

5. Optionen

• Overwrite existing objects: empfohlen
• Path prefix: optional (z. B. nur images/)

6. Start Migration

Konfiguration prüfen → „Start Migration“.

7. Fortschritt

• Übertragungsrate
• Anzahl Dateien
• Restzeit-Schätzung

Zeiten:

• 100 GB → ~30 Min.
• 1 TB → ~4–6 h
• 10 TB → ~2–3 Tage

Migration läuft im Hintergrund – Seite kann geschlossen werden.

Schritt 3: Validierung (10 Minuten)

S3 nicht sofort löschen – zuerst prüfen.

1. Objektanzahl

R2-Bucket vs. S3 – Anzahl sollte übereinstimmen. Abweichung → Migrations-Logs.

2. Integrität (Stichprobe)

# MD5/ETag S3
aws s3api head-object --bucket my-bucket --key test.jpg --query 'ETag' --output text
# R2
rclone md5sum r2:my-bucket/test.jpg

Gleicher ETag → Datei intakt.

3. Zugriff testen

Public URL oder API – Download prüfen.

4. Metadaten

aws s3api head-object --bucket my-bucket --key test.jpg
# Mit R2-Metadaten vergleichen

Schritt 4: App auf R2 umstellen

Nach erfolgreicher Validierung – Canary, nicht Big Bang.

1. Konfiguration

# S3
S3_ENDPOINT=https://s3.amazonaws.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=xxx
S3_SECRET_KEY=xxx
S3_REGION=us-east-1
# R2
S3_ENDPOINT=https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=R2_xxx
S3_SECRET_KEY=R2_xxx
S3_REGION=auto

2. Canary

10 % Traffic → Logs, Fehlerrate, Feedback → 50 % → 100 %.

3. Monitoring

• API-Fehlerrate
• Latenz
• Egress-Kosten (sollten stark fallen)

4. S3-Backup 30 Tage

S3-Daten 30 Tage behalten. Seit März 2024 ist Egress bei Wegzug zu vielen Anbietern oft kostenlos.

Lifecycle für automatische Löschung:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

{
  "Rules": [
    {
      "Status": "Enabled",
      "Expiration": {
        "Days": 30
      }
    }
  ]
}

Schritt 5: Optimierung und Monitoring

Migration ist der Start – so holen Sie mehr aus R2.

Performance

1. Cloudflare CDN

R2 bucket → Public Access → Connect Domain (Domain bei Cloudflare) → CDN-Cache.

2. Cache-Control

// Statische Assets – 1 Jahr
s3.upload({
  Bucket: 'my-bucket',
  Key: 'image.jpg',
  Body: fileBuffer,
  CacheControl: 'public, max-age=31536000, immutable'
});
// Häufig wechselnde Inhalte – 1 Stunde
s3.upload({
  // ...
  CacheControl: 'public, max-age=3600'
});

3. Custom Domain

Statt https://xxx.r2.cloudflarestorage.com/file.jpg → https://cdn.yoursite.com/file.jpg – bessere URLs und CDN.

Kosten

1. Infrequent Access (IA)

• Speicher 0,01 $/GB vs. Standard 0,015 $/GB
• Lesen 0,01 $/GB extra

Für Archive, Backups, Cold Data.

2. Multipart part size

Jeder Part = Class-A-Operation:

• Unter 100 MB: Single Upload
• 100 MB–1 GB: 64 MB Parts
• Über 1 GB: 128 MB Parts

rclone copy s3:bucket r2:bucket --s3-chunk-size 64M

3. Class A/B beobachten

• Class A (Schreiben): 4,50 $/Mio.
• Class B (Lesen): 0,36 $/Mio.

Viele Class-A-Ops → doppelte Uploads oder unnötige Requests prüfen.

Monitoring

1. Cloudflare Analytics

R2 bucket → Analytics: Requests, Traffic, Fehler, Top-Dateien.

2. Kostenalarm

Dashboard → Notifications → „R2 storage usage“ – z. B. E-Mail ab 50 $/Monat.

3. APM

Fehlerrate (< 0,1 %), Latenz (< 100 ms avg, P99 < 500 ms) – Sentry, Datadog.

4. Monatlicher Vergleich

S3 vorher vs. R2 nachher – Ersparnis dokumentieren.

Fazit: Lohnt sich Migration zu R2?

Ab ~500 GB Traffic/Monat: ja, klar.

Drei Punkte:

1. Kosten: Null Egress kann 50–90 % der Cloud-Rechnung streichen. SaaS oft 10.000 $+/Jahr, Video 50.000 $+.
2. Aufwand: Super Slurper ~30 Min. Konfiguration, 80–90 % API-Kompatibilität – meist nur Endpoint ändern.
3. Risiko: Quelldaten bleiben, Canary, Rollback möglich. Egress bei Wegzug oft kostenlos.

Grenzen:

• Tiefe AWS-Integration (Lambda, Athena) → hoher Aufwand
• Object Lock / Compliance → R2 derzeit nicht
• Unter 100 GB/Monat → ROI oft gering

Empfehlung: Mit R2-Free-Tier testen, bei Produktion Sippy für schrittweise Migration.

Ein Bildhosting-Fall: S3 ~1.800 $/Monat → R2 ~18 $ (nur Speicher). Ersparnis floss in Design – bessere UX. Kosteneinsparung ist nicht nur „weniger Rechnung“, sondern Budget für Wichtigeres.

Nächste Schritte:

1. R2-Rechner – Ihre Ersparnis schätzen
2. Free-Tier und Performance testen
3. Weg wählen: Super Slurper / Sippy / rclone
4. Canary-Migration
5. Full Cutover

Bei Fragen zur Migration gerne diskutieren – viel Erfolg und sinkende Rechnungen!