> ## Content Index
> Fetch the complete content index at: https://prod-0-dol-blog-zrh1.dol.ch/llms.txt
> Use this file to discover other available public pages before exploring further.

# CloudFront liefert keine Dateien über 50 GB aus. Mit Range-Requests geht es trotzdem
- URL: https://prod-0-dol-blog-zrh1.dol.ch/blog/cloudfront-50gb-limit/
- Published: 2026-09-10T20:59:49.000Z
- Updated: 2026-09-10T21:49:31.000Z
- Description: Sechs von 194 Dateien standen den ganzen Tag auf failed, mitten in einem 2-TB-Restore über CloudFront, und Retry brachte nichts. CloudFront liefert schlicht keine Datei über 50 GB in einem GET aus.
- Author: dima
- Tags: de, AWS, CloudFront, S3, Glacier Deep Archive, Backup, Bash

Ich habe vor Kurzem [einen Artikel veröffentlicht](https://www.dol.ch/blog/s3-deep-archive-cloudfront-egress/?ref=prod-0-dol-blog-zrh1.dol.ch), wie ich 2 TB aus S3 Glacier Deep Archive über CloudFront gezogen habe, 15 Dollar Flatrate statt der 200, vor denen ich Angst hatte. Ein Haken kam erst, nachdem ich ihn veröffentlicht hatte, und den erzähle ich hier nach.

194 Objekte insgesamt, die meisten 45 bis 50 GB, weil iCloud Drive den Foto-Export in Stücke dieser Grösse schneidet, und so sind sie auch nach S3 gewandert. Sechs davon waren 250 bis 350 GB, alte Backups, die ich jeweils in ein einziges grosses Archiv gepackt hatte. Ich dachte, ein grosses Objekt lässt sich leichter verschieben, je grösser, desto besser, und über die Folgen habe ich nie nachgedacht. Am Morgen habe ich den Download von allem gestartet und bin zur Arbeit gegangen.

## Sechs Dateien auf failed, und Retry half nicht

Am Abend kam ich zurück und sechs Dateien standen auf `failed`. Alle anderen waren durch. Ich habe den Retry laufen lassen, und es waren dieselben sechs Dateien, dasselbe Ergebnis. Mein erster Gedanke war also, dass der ganze Trick nicht mehr funktioniert und dass es eben doch Limits gibt, auch bei einer Flatrate.

Ich habe einen direkten Link auf eine der sechs Dateien im Browser geöffnet, und das hier bekommen.

![ERROR: The request could not be satisfied.](https://prod-0-dol-blog-zrh1.dol.ch/content/images/2026/09/cf_antwort-1.png)

Ich habe den Fehler gegoogelt, und meine Vermutung stimmte, es gibt ein Limit. Nur nicht das, an das ich gedacht hatte. Es steht auf der [offiziellen Quotenseite](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html?ref=prod-0-dol-blog-zrh1.dol.ch), Abschnitt "General quotas on distributions".

> Maximum cacheable file size per HTTP GET response: **50 GB**

Meine sechs Dateien lagen weit darüber, die grösste beim Siebenfachen. Und die 45-bis-50-GB-Dateien lagen die ganze Zeit knapp darunter, ich habe es nur nie gemerkt.

Kurz war ich bereit, einfach für die zusätzlichen 500 GB Egress zu zahlen, zum Teufel damit, und die sechs Dateien direkt aus S3 zu ziehen. Aber ich gebe nicht gern auf.

## Range-Requests, direkt aus der AWS-Doku

Ich habe eine KI um Hilfe gebeten, und die Antwort waren Range-Requests. AWS beschreibt genau diesen Fall selbst, im [Leitfaden zu Range-GETs](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RangeGETs.html?ref=prod-0-dol-blog-zrh1.dol.ch).

> When caching is enabled, CloudFront doesn't retrieve or cache an object that is larger than 50 GB (...) However, with range requests, you can use CloudFront to cache an object that is larger than the maximum cacheable file size.

CloudFront teilt eine grosse Datei nicht von selbst auf. Der Client muss sie in Stücken anfordern, über den `Range`\-Header, jedes Stück unter 50 GB, und CloudFront cached und liefert dann jedes Stück einzeln aus.

Auf derselben Seite steht auch, dass CloudFront bei ausgeschaltetem Caching grössere Objekte einfach durchreicht, nur ohne sie zu cachen. Das wusste ich damals nicht, also war es bei mir das Skript.

## Das curl-Skript mit Chunks

Ein `curl` pro Chunk mit `Range: bytes=START-END`, 40 GB pro Teil, um klar unter der Grenze zu bleiben. Die Gesamtgrösse holt sich das Skript selbst, über eine `Range: bytes=0-0`\-Anfrage und den `Content-Range`\-Header der Antwort. Jeder Teil landet in einer eigenen `.part.NNNN`\-Datei, und vor jedem Download prüft das Skript, ob die Datei schon die erwartete Grösse hat, sonst wird sie neu geholt. Wenn der Lauf also abbricht, startest du ihn einfach neu und er überspringt die fertigen Teile.

```bash
URL="PATH_TO_LARGE_CLOUDFRONT_FILE"
OUT="$HOME/Downloads/NAME_OF_THE_CLOUDFRONT_FILE"
CHUNK=$((40*1024*1024*1024)) # 40 GB pro Chunk, mit Reserve zur 50-GB-Grenze

TOTAL=$(curl -sD - -o /dev/null -A "Mozilla/5.0" -H "Range: bytes=0-0" "$URL" \
  | awk -F/ 'tolower($0) ~ /content-range:/ {gsub("\r","",$2); print $2; exit}')
echo "size: $TOTAL"
[ -n "$TOTAL" ] || exit 1

START=0
PART=0
while [ "$START" -lt "$TOTAL" ]; do
  END=$((START + CHUNK - 1))
  [ "$END" -ge "$TOTAL" ] && END=$((TOTAL - 1))
  PART_FILE=$(printf "%s.part.%04d" "$OUT" "$PART")
  NEED=$((END - START + 1))
  HAVE=0
  [ -f "$PART_FILE" ] && HAVE=$(wc -c < "$PART_FILE" | tr -d ' ')
  if [ "$HAVE" -ne "$NEED" ]; then
    echo "part $PART  $START-$END"
    curl --fail --retry 20 --retry-all-errors --retry-delay 5 \
      -A "Mozilla/5.0" \
      -H "Range: bytes=${START}-${END}" \
      -o "$PART_FILE" \
      "$URL" || exit 1
  else
    echo "part $PART already ok"
  fi
  START=$((END + 1))
  PART=$((PART + 1))
done

cat "$OUT".part.* > "$OUT" && rm -f "$OUT".part.*
ls -lh "$OUT"
# Die 40-GB-Teile siehst du nur kurz. Nach dem cat ist es wieder eine Datei.

```

Es hat beim ersten Mal funktioniert. Eine 250-GB-Datei hat etwa eine Stunde gebraucht, und kein einziger Teil musste zweimal geholt werden.

## Was es gekostet hat, und warum AWS noch läuft

15 Dollar sind trotzdem 15 Dollar. Unter 4% des CloudFront-Kontingents von 50 TB verbraucht. Ich hätte für genau dasselbe Ergebnis auch die 200 zahlen können, vor denen ich Angst hatte.

Jetzt liegt alles auf dem NAS und bei Proton Drive (Visionary, 6 TB). In der Theorie könnte ich AWS jetzt abschalten. In der Praxis noch nicht. Die Platten im NAS sind alle noch da, aber sie haben zehn Jahre Laufzeit, sie sind klein, und es ist RAID 5 mit einer Reserveplatte aus derselben Charge. Ich traue ihnen nicht. Also bleibt AWS, bis ich eine weitere Festplatte kaufe und alles für ein sauberes 3-2-1-Backup kopiere. Speicherpreise steigen gerade wie verrückt, Festplatten inklusive, mir fehlen fast die Worte dafür. Aber ein bisschen Hoffnung ist noch da.

Das ist meine eigene Erfahrung, vielleicht hilft sie jemandem. Fragen beantworte ich gern, und helfen auch.