Cloudflare R2 — obiektowy storage bez opłat za transfer

Amazon S3 nauczył cały internet jednego modelu przechowywania plików: obiektowego storage’u z kubełkami (buckets), do którego wrzuca się wszystko — od zdjęć produktów po backupy baz danych. Nauczył też czegoś mniej przyjemnego: opłat za każdy gigabajt danych wychodzących z chmury, tak zwanego egress. Cloudflare R2 to bezpośrednia odpowiedź na ten model — storage zgodny z API S3, w którym transfer wychodzący kosztuje dokładnie zero. W tym artykule sprawdzamy, jak duża jest to różnica w praktyce, jak zacząć z R2 i jak wykorzystać go między innymi do odciążenia mediów WordPressa.

Egress: cichy zabójca budżetu

Policzmy na konkretnym przykładzie. Strona z galerią zdjęć albo sklep z bogatymi kartami produktów serwuje miesięcznie 1 TB obrazków. W klasycznym S3 sam transfer wychodzący do internetu to wydatek rzędu 90 USD miesięcznie — niezależnie od tego, że przechowywanie tych plików kosztuje grosze. Przy 10 TB robi się z tego kilkaset dolarów, a popularny plik wideo potrafi jednym wpisem na social mediach wygenerować rachunek, o jakim nikt nie śnił.

W R2 ta pozycja po prostu nie istnieje. Płaci się za przechowywanie (0,015 USD za GB miesięcznie) i za operacje (ułamki dolara za milion), a wyjście danych do internetu — czy to 1 GB, czy 100 TB — jest darmowe. Do tego dochodzi hojny plan bezpłatny: 10 GB przestrzeni i miliony operacji miesięcznie, co dla mniejszych projektów oznacza koszt równy zeru.

Zgodność z S3, czyli migracja bez przepisywania kodu

R2 wystawia API zgodne z S3 — działają z nim te same biblioteki (aws-sdk, boto3), te same narzędzia (rclone, Cyberduck) i te same wtyczki. Migracja zwykle sprowadza się do zmiany endpointu i kluczy dostępowych. Cloudflare oferuje też tryb Sippy, który migruje dane z S3 „leniwie”: obiekt jest kopiowany do R2 przy pierwszym żądaniu, więc przeprowadzka odbywa się bez okna serwisowego.

Start: kubełek i dostęp z Workera

Kubełek tworzymy w panelu Cloudflare albo Wranglerem:

npx wrangler r2 bucket create media-okinet

Najprzyjemniejszy sposób pracy z R2 to binding w Workerze — bez kluczy, bez podpisywania żądań, po prostu obiekt w env:

{
  "r2_buckets": [
    { "binding": "MEDIA", "bucket_name": "media-okinet" }
  ]
}

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const key = url.pathname.slice(1);

    if (request.method === "PUT") {
      await env.MEDIA.put(key, request.body, {
        httpMetadata: { contentType: request.headers.get("content-type") }
      });
      return new Response("Zapisano: " + key, { status: 201 });
    }

    const object = await env.MEDIA.get(key);
    if (!object) {
      return new Response("Nie znaleziono", { status: 404 });
    }
    const headers = new Headers();
    object.writeHttpMetadata(headers);
    headers.set("cache-control", "public, max-age=31536000, immutable");
    return new Response(object.body, { headers: headers });
  }
};

Kilkanaście linijek i mamy własny, globalny serwer plików — z pełną kontrolą nad uprawnieniami, nagłówkami cache i logiką dostępu (np. autoryzacją przed wydaniem pliku).

Publiczny hosting plików z własną domeną

Do prostszych zastosowań Worker nie jest konieczny: kubełek można podpiąć bezpośrednio pod własną subdomenę (np. cdn.twojadomena.pl) w kilka kliknięć. Pliki są wtedy serwowane przez sieć Cloudflare z pełnym cache’owaniem na edge’u — obiekt raz pobrany do punktu obecności jest kolejnym użytkownikom wydawany lokalnie. Dla statycznych assetów (fonty, skrypty, obrazy, wideo) to praktycznie gotowy CDN bez dodatkowej konfiguracji.

Backupy z rclone

Ponieważ R2 mówi dialektem S3, świetnie współpracuje z narzędziem rclone. Kopia katalogu na serwerze do kubełka to jedno polecenie, które można wrzucić do crona:

rclone sync /var/www/strona/backups r2:backupy-okinet/strona   --transfers 8 --fast-list

Za przechowywanie 50 GB backupów zapłacimy w R2 około 75 centów miesięcznie, a ewentualne przywracanie danych (czyli duży transfer wychodzący!) nie kosztuje nic — dokładnie odwrotnie niż w usługach, gdzie odzyskanie własnych danych bywa najdroższą operacją w cenniku.

R2 i WordPress: odciążamy media

Typowy WordPress trzyma wszystkie zdjęcia w katalogu uploads na tym samym serwerze co PHP i baza danych. Przy większym ruchu to marnowanie zasobów: serwer aplikacji zajmuje się wydawaniem statycznych plików zamiast generowaniem stron, a katalog puchnie, utrudniając backupy i migracje. Wtyczki do offloadu mediów (np. WP Offload Media czy Media Cloud) potrafią automatycznie wysyłać każdy upload do storage’u zgodnego z S3 — wystarczy podać endpoint R2 i klucze — a w treściach podmieniać adresy na domenę kubełka. Efekt: lżejszy serwer, szybsze media z globalnego cache i backupy aplikacji mniejsze o gigabajty. To jedno z naszych ulubionych, szybkich ulepszeń przy stałej opiece nad stronami klientów.

O czym pamiętać

• R2 ma spójność silną dla operacji na obiektach — po zapisie od razu czytasz nową wersję (inaczej niż w KV),
• pojedynczy obiekt może mieć do 5 TB (upload wieloczęściowy powyżej 5 GB),
• lokalizację danych można przypiąć do jurysdykcji (np. Unia Europejska) — istotne przy RODO,
• R2 nie transformuje obrazów — do generowania miniatur w locie warto dołożyć Cloudflare Images albo Workera z biblioteką do obróbki,
• koszty operacji klasy A (zapisy, listowania) są wyższe niż klasy B (odczyty) — projektując strukturę kluczy, warto unikać nadmiarowych listowań.

Podsumowanie

R2 odziera obiektowy storage z jego najbardziej nieprzewidywalnego kosztu i dokłada do tego naturalną integrację z Workerami oraz siecią CDN Cloudflare. Dla stron i sklepów oznacza to tanie, szybkie media; dla zespołów — backupy, których przywracanie nie boli; dla aplikacji — pliki użytkowników bez własnej infrastruktury. W kolejnym artykule serii zmieniamy temat na analitykę: przyjrzymy się PostHogowi, czyli narzędziu, które pokazuje nie tylko ile osób odwiedza stronę, ale co dokładnie na niej robią. Masz projekt, w którym rachunek za transfer spędza sen z powiek? Odezwij się — policzymy, ile zaoszczędzisz na R2.