Self-hosting vs chmura — analiza TCO Cloudflare R2 i VPS OVH na realnych liczbach

Decyzja o tym, gdzie postawić warstwę storage aplikacji — w obiektowym storage chmurowym takim jak Cloudflare R2 czy na własnym, dedykowanym serwerze VPS — bywa pierwszą poważną architektoniczną rozmową w każdym projekcie B2B. Z naszej perspektywy w Synlogii rozmowa ta zwykle nie sprowadza się do prostego „co jest tańsze". Zamiast tego porównujemy całkowity koszt posiadania (Total Cost of Ownership, TCO) wraz z transferem, operacjami, czasem inżynierskim i zobowiązaniami umownymi. Ten artykuł pokazuje, jak rozpisać taką analizę na realnych, publicznie zweryfikowalnych liczbach.

Dwa modele rozliczania — fundament różnicy

Cloudflare R2 i klasyczny VPS to dwa skrajne modele kosztowe:

• R2 (model usage-based) — płacisz za to, co przechowujesz, oraz za operacje (Class A — zapisy/listy, Class B — odczyty). Cloudflare nie pobiera opłat za egress, czyli ruch wychodzący do internetu (Cloudflare, n.d.).
• VPS (model flat-rate) — płacisz stałą miesięczną kwotę za maszynę o określonej specyfikacji (vCPU, RAM, dysk, transfer), niezależnie od tego, ile faktycznie zużyjesz.

Pierwszy model nagradza projekty z nieprzewidywalnym lub niskim wolumenem, drugi — projekty stabilnie obciążone, dla których przewidywalność rachunku ma większą wagę niż elastyczność.

Realne liczby — Cloudflare R2 (stan publicznych cenników)

Zgodnie z publiczną stroną cenową Cloudflare (Cloudflare, n.d.), R2 rozlicza się następująco:

• Storage: 0,015 USD za GB-miesiąc (po przekroczeniu darmowego progu 10 GB w planie Standard).
• Class A operations (PUT, COPY, POST, LIST): 4,50 USD za milion żądań.
• Class B operations (GET, HEAD): 0,36 USD za milion żądań.
• Egress: 0,00 USD — Cloudflare promuje brak opłat za ruch wychodzący jako kluczowy wyróżnik wobec konkurencji.

Dla scenariusza średniej aplikacji z 200 GB danych, 5 milionami odczytów i 500 tys. zapisów miesięcznie rachunek wygląda następująco: (200 × 0,015) + (5 × 0,36) + (0,5 × 4,50) ≈ 3,00 + 1,80 + 2,25 = 7,05 USD/miesiąc. Dodatkowo pełny egress 1 TB do internetu nie generuje żadnego dodatkowego kosztu — to fundamentalna różnica względem klasycznego AWS S3, gdzie zgodnie z dokumentacją Amazon Web Services pierwszy 1 TB ruchu wychodzącego do internetu wynosi 0,09 USD za GB w większości regionów (Amazon Web Services, n.d.).

Realne liczby — VPS klasy produkcyjnej

Po stronie self-hostingu skupmy się na typowej maszynie do warstwy storage. Plany VPS na rynku europejskim (OVHcloud, Hetzner, Contabo) obejmują maszyny z 4–8 vCPU, 8–24 GB RAM, 100–400 GB SSD i kilkoma terabajtami transferu. Ceny tej klasy kształtują się dziś w widełkach ~10–30 EUR/miesiąc (ceny zgodne z publicznymi cennikami dostawców na dzień opracowania artykułu).

Sam serwer to jednak nie pełen rachunek. Do TCO trzeba dodać:

1. Kopie zapasowe — albo wbudowane snapshots dostawcy (od 1 EUR/miesiąc), albo niezależny mechanizm typu rsync/restic do drugiego regionu.
2. Monitoring i alerting — Prometheus + Grafana (samohostowane, „darmowe" tylko w pieniądzach), albo zewnętrzny serwis (Better Stack, UptimeRobot — od kilku EUR/miesiąc).
3. Czas inżynierski — utrzymanie systemu (aktualizacje OS, certyfikaty, hardening). W naszej praktyce zakładamy 2–4 godziny inżyniera/miesiąc na stabilną maszynę po wdrożeniu.
4. Brak SLA na pojedynczym VPS — pojedynczy host bez replik to ryzyko, które trzeba albo zaakceptować, albo zniwelować przez drugą maszynę i load balancer (i wtedy rachunek się dubluje).

Realistyczne pełne TCO pojedynczego, dobrze utrzymywanego VPS w skali małej firmy to 20–60 EUR/miesiąc kosztów twardych plus kilka godzin czasu inżynierskiego, którego godzinowy koszt zależy od stawek wewnętrznych zespołu.

Kiedy R2 wygrywa

• Aplikacja serwuje pliki publicznie (zdjęcia produktowe, dokumenty PDF, exporty CSV) — brak egress eliminuje największą pułapkę chmury.
• Wolumen jest mały lub bardzo zmienny — start-up lub MVP nie chce wiązać się z ryczałtem za serwer, którego użyje w 5%.
• Zespół nie ma kompetencji DevOps — R2 wymaga konfiguracji bucketu i kluczy, ale nie wymaga utrzymywania OS, kerneli i certyfikatów.
• Wymagana jest wysoka dostępność bez stawiania własnej redundancji.

Kiedy VPS wygrywa

• Operacje na danych są intensywne i przewidywalne — dla milionów odczytów dziennie ryczałt VPS jest tańszy niż usage-based bilingu.
• Aplikacja potrzebuje uruchamiać dodatkową logikę przy storage (kompresja w locie, generowanie thumbnailów, transformacje) — własny serwer pozwala uruchomić ImageMagick czy ffmpeg bez stack chmurowego.
• Wymagania regulacyjne lub zaufanie wymagają trzymania danych „pod własnym kluczem" w konkretnej jurysdykcji.
• Suwerenność infrastrukturalna — projekty publiczne lub samorządowe coraz częściej w specyfikacjach wymuszają lokalizację UE i właściciela infrastruktury.

Hybryda — w praktyce najczęstszy wybór

W naszych wdrożeniach najczęściej rekomendujemy konfigurację mieszaną: VPS dla aplikacji i bazy danych (gdzie liczy się stała wydajność i niski latency między usługami), R2 lub równoważny obiektowy storage do zasobów statycznych i kopii zapasowych. Taki układ łączy dwie zalety: przewidywalność rachunku za rdzeń aplikacji i elastyczność za storage, który skaluje się z liczbą użytkowników.

Dla zilustrowania: w naszych własnych projektach storage statyczny przeniesiony z bind mountów lokalnych na obiektowy storage typu R2 zmniejszył presję na monitoring miejsca na dysku VPS i pozwolił bezpiecznie wykonywać częstsze deploye bez ryzyka zapełnienia partycji.

Lista kontrolna decyzji

1. Oszacuj realny wolumen danych i operacji (nie domyślny narzut).
2. Policz koszt obu wariantów dla 12 miesięcy z zapasem 30% wzrostu.
3. Doliczy do wariantu VPS koszt inżyniera (godziny × stawka), a do wariantu chmurowego koszt egress przy realnym wzorcu ruchu.
4. Sprawdź wymagania umowne klienta dotyczące lokalizacji danych i SLA.
5. Wybierz model dopasowany do fazy projektu — wczesna faza skaluje się przez chmurę, dojrzała przez VPS.

Dobra analiza TCO to nie ćwiczenie z księgowości, lecz część architektury. Decyzja podjęta dziś będzie kosztować lub oszczędzać przez kolejne 24–36 miesięcy działania systemu.

Bibliografia (APA 7)

• Amazon Web Services. (n.d.). Amazon S3 pricing. Retrieved February 14, 2026, from https://aws.amazon.com/s3/pricing/
• Cloudflare. (n.d.). R2 pricing. Retrieved February 14, 2026, from https://developers.cloudflare.com/r2/pricing/
• Hetzner Online. (n.d.). Cloud servers. Retrieved February 14, 2026, from https://www.hetzner.com/cloud
• OVHcloud. (n.d.). VPS — porównanie planów. Retrieved February 14, 2026, from https://www.ovhcloud.com/pl/vps/