Servere statiske assets fra Cloudflare R2 i stedet for S3: fordeler, regler og begrensninger

Statiske assets virker enkle helt til de blir en stor og lite forutsigbar del av regningen. Produktbilder, PDF-er, video, fonter, dokumentasjonseksporter, genererte rapporter og nedlastbare builds starter ofte i samme bucket. Når trafikken vokser, er problemet ikke lenger bare lagring. Det er levering.

Cloudflare R2 endrer regnestykket: S3-kompatibel objektlagring, ingen R2-egressavgift til Internett og en enkel vei til å legge bucketen bak et Cloudflare-styrt domene. Men R2 erstatter ikke alle former for statisk hosting. Riktig valg avhenger av om du serverer en webapplikasjon eller objekter.

Det egentlige problemet er ikke bare lagring

Et offentlig assetsystem må gjøre fire ting:

1. Lagre objekter varig.
2. Eksponere URL-er under et kontrollert hostname.
3. Cache populære filer aggressivt.
4. Invalidate eller versjonere endringer forutsigbart.

S3 løser dette ofte med CloudFront foran. R2 gjør det med et Cloudflare-domene, Cache Rules, WAF, Access og Workers når du trenger logikk. Den praktiske forskjellen er ikke bare bucket-API-et. Det handler om hvor edge-laget ligger og hva du betaler når bytes forlater lagringen.

Når R2 passer best

R2 passer spesielt godt for offentlige filer som leses ofte og endres sjelden:

• hashede assets som app.4f3a1c.css eller vendor.91bc2.js
• bilder, video, fonter og Open Graph-media
• PDF-er, whitepapers, rapporter og offentlige nedlastinger
• releases, datasett, modellfiler og store arkiver
• statiske kataloger der URL-en skal mappe til en objektnøkkel

Fordelen er både økonomisk og operasjonell. R2 tar ikke betalt for egress fra R2 til Internett, fungerer med mye S3-kompatibel tooling og lar cache, sikkerhet og leveringsregler ligge i samme Cloudflare-kontrollplan.

SSG eller direkte levering fra R2?

Første spørsmål er enkelt: serverer du sider eller filer?

Bruk SSG for HTML og ruter. Astro, Cloudflare Pages, Workers Static Assets, Netlify og Vercel forstår ruter som /pricing, SPA-fallbacks, redirects, headers per rute, 404-sider og atomiske deploys. Det er riktig for marketing sites, dokumentasjon, blogger og apper der SEO, canonical, structured data og statuskoder betyr noe.

Bruk R2 direkte når pathen identifiserer en fil:

https://assets.example.com/brand/logo.svg
https://downloads.example.com/reports/audit-2026.pdf
https://releases.example.com/app/1.8.4/linux-amd64.tar.gz

R2 antar ikke automatisk at /docs/ skal servere /docs/index.html, eller at /app/settings skal falle tilbake til /app/index.html. Du kan legge en Worker foran R2 for dette, men da bygger du i praksis en liten statisk host. Det kan være riktig, men bør være et bevisst valg.

Produksjonsmønstre som fungerer

Det tryggeste mønsteret er å beholde nettstedet på en SSG-plattform og flytte tunge filer til R2:

www.example.com       -> nettsted eller app
assets.example.com    -> offentlig R2-bucket
downloads.example.com -> offentlig R2-bucket

Da blir HTML-ruter, previews, redirects og SEO-signaler værende i webplattformen, mens bilder, PDF-er og releases serveres fra R2 via Cloudflare-cache.

For offentlige versjonsarkiver kan R2 servere et objekt-tre direkte. Ikke bruk bucket-listing som navigasjon. Publiser en indeksside fra hovedsiden eller last opp en eksplisitt index.html hvis brukere må bla i innholdet.

Hvis du trenger autentisering, tokens, path-normalisering eller dynamiske headers, legg en Worker foran R2. Workeren kan validere requesten, finne objektnøkkelen, sette Cache-Control og returnere filen.

Egendefinert domene, cache og sikkerhet

I produksjon bør du bruke et egendefinert domene som assets.example.com. r2.dev er praktisk for testing, men bør ikke være den viktigste offentlige flaten. Med eget domene kan du bruke Cache Rules, WAF, Access, botregler og Workers.

Cachereglene bør være tydelige:

• Hashede assets: Cache-Control: public, max-age=31536000, immutable.
• Mutable filer som latest.zip, catalog.json eller index.html: kort TTL og purge ved deploy.
• Private eller signerte nedlastinger: bypass cache eller en korrekt designet cache key.
• Cache Everything: bare på bucket-hostname, ikke globalt på applikasjonen.

Upload-pipelinen er like viktig. Hvert objekt trenger riktig Content-Type og riktige cachemetadata. JavaScript servert som application/octet-stream, eller SVG med feil type, kan skape problemer i nettlesere, previews og sikkerhetspolicyer.

R2 vs S3: praktisk regel

S3 gir fortsatt mening for selskaper som allerede er dypt AWS-native, med CloudFront, IAM, signed URLs, logging og governance på plass. R2 blir attraktivt når egresskostnaden er merkbar, filene er offentlige eller semi-offentlige, og Cloudflare allerede er edge-laget.

Bruk tommelfingerregelen:

• HTML-sider og appruter: SSG, Pages eller Workers Static Assets.
• Store offentlige filer og immutable assets: R2 bak eget domene.
• Enkle offentlige filtrær: R2 direkte.
• Filtrær med auth eller routing: Worker foran R2.
• Private AWS-native workflows: S3 kan fortsatt være best.

Den beste arkitekturen er sjelden “R2 overalt”. Den er mer presis: behold sider i verktøyet som er bygget for sider, flytt offentlige høyvolumsbytes til R2 og legg cache og sikkerhet der trafikken faktisk kommer inn.