Chmura publiczna w rozsądnej cenie: z czego składa się rachunek i gdzie ucieka budżet

Blog WebDisk · kategoria: Chmura · czas czytania: ~8 minut

W skrócie:- Rachunek za chmurę to nie jedna pozycja, tylko kilka niezależnych liczników: moc obliczeniowa, pojemność, transfer, adresy IP i kopie zapasowe. Niespodzianki biorą się prawie zawsze z trzech ostatnich.- Koszty nazywane „ukrytymi” zwykle nie są ukryte – są poza kalkulatorem: transfer wychodzący, operacje na obiektach, minimalny okres przechowywania, odtwarzanie z klas archiwalnych.- Rachunek obniżają nudne nawyki, nie negocjacje: rightsizing, harmonogram dla środowisk testowych, dopasowanie nośnika do danych, sprzątanie zasobów-sierot.

Chmura publiczna zaczyna się od zachwytu: maszyna wstaje w kilka minut, magazyn rośnie sam, nikt nie czeka na dostawę serwera. Zachwyt trwa mniej więcej do trzeciego rachunku – wtedy pada pytanie: skąd ta kwota, skoro nic nie zmienialiśmy?

Zwykle nie zmieniło się nic w maszynach – zmieniło się to, co wokół nich: przybyło danych, ruszył integrator pobierający pliki co minutę, ktoś zostawił włączone środowisko testowe po demo, a snapshoty sprzed pół roku wciąż zajmują miejsce. Rachunek rzadko rośnie z jednego powodu; rośnie z pięciu naraz, po trochu.

Ten artykuł jest rozbiorem takiego rachunku: co się na niego składa, które pozycje zaskakują najczęściej, kiedy własna serwerownia naprawdę wychodzi taniej – i co zrobić, żeby nie przepłacać. Piszemy go z perspektywy małego dostawcy chmury, więc uprzedzamy: mamy w tym interes. Staramy się za to pokazywać mechanikę, którą sprawdzisz u dowolnego dostawcy – także u nas.

Z czego składa się rachunek za chmurę publiczną?

Niezależnie od dostawcy, koszt infrastruktury jako usługi (IaaS – wynajem surowych zasobów: maszyn, dysków, sieci; różnice między IaaS, PaaS i SaaS opisuje tekst Chmura jako usługa) rozkłada się na kilka składników:

• Moc obliczeniowa – vCPU i RAM maszyn wirtualnych. Zwykle najbardziej przewidywalna pozycja, bo wynika wprost z decyzji podjętych w panelu.
• Pojemność – dyski maszyn i magazyn obiektowy. Rośnie po cichu: kilku procent miesięcznie nikt nie zauważa, po roku robi się z tego wyraźna różnica.
• Transfer – ruch sieciowy, przede wszystkim wychodzący (egress). Pozycja najwrażliwsza na zmiany, których nie kontrolujesz: skok ruchu na stronie, nowy klient API, źle napisany klient synchronizacji.
• Adresy IP – u wielu dostawców publiczny adres IPv4 jest osobno płatny, bywa że również wtedy, gdy jest zarezerwowany, ale nieużywany. Warto sprawdzić, ile ich naprawdę potrzebujesz i czy części ruchu nie przenieść na publiczną adresację IPv6. U nas podstawowe plany chmury publicznej zawierają jeden publiczny adres IPv4 w cenie – kolejne są osobną pozycją.
• Kopie zapasowe i snapshoty – najczęściej niedoszacowana pozycja, bo płacisz nie za jedną kopię, tylko za całą historię: pełną bazę plus przyrosty z każdego punktu przywracania, przez cały okres retencji. Im dłuższa retencja i im więcej danych się zmienia, tym większa różnica między „500 GB danych” a „500 GB w backupie”.

Wniosek praktyczny: rachunek trzeba rozbić na te składniki i porównać miesiąc do miesiąca. Kwota zbiorcza nic nie mówi – dopiero rozbicie pokazuje, że wzrosła pojemność, a nie moc obliczeniowa.

Jakich kosztów chmury nie widać w kalkulatorze?

Osobna kategoria to pozycje, które w rozbudowanych cennikach istnieją, ale nie pojawiają się w prostej wycenie „ile kosztuje maszyna”:

Transfer wychodzący. Najczęstsza przyczyna rachunkowych niespodzianek: dane wgrywasz za darmo, a płacisz za każdy gigabajt, który je opuszcza. Efekt uboczny jest strategiczny – im więcej masz danych, tym drożej kosztuje wyprowadzka. To klasyczny mechanizm uzależnienia od dostawcy, opisany szerzej w tekście o vendor lock-in. Unijny Data Act, stosowany od 12 września 2025 r., ogranicza opłaty za samą zmianę dostawcy do faktycznych kosztów, a od 12 stycznia 2027 r. znosi je całkowicie. Nie dotyczy to jednak zwykłego ruchu wychodzącego w trakcie korzystania z usługi – ten nadal bywa płatny.

Operacje na obiektach. W magazynach S3 płaci się nie tylko za zajęte miejsce, lecz także za liczbę żądań: zapisów, odczytów, listowania. Aplikacja odpytująca magazyn w pętli potrafi wygenerować pozycję porównywalną z kosztem przechowywania – przy niewielkiej ilości danych.

Minimalny okres przechowywania i koszt odtworzenia. Tanie klasy archiwalne mają dwa haczyki: plik usunięty przed upływem minimalnego okresu i tak jest liczony do jego końca, a odtworzenie danych bywa płatne osobno. Taka klasa jest tania dopóty, dopóki z niej nie korzystasz.

Reszta drobnicy. Godziny pracy load balancerów i bram NAT, ruch między strefami dostępności, licencje doliczane do godziny maszyny, płatne plany wsparcia. Każda pozycja z osobna wygląda niewinnie; problemem jest ich liczba. To nie zarzut – tak wygląda rozliczanie bardzo złożonej oferty. Warto jednak wiedzieć, że złożoność cennika sama w sobie jest kosztem: żeby na niej nie tracić, trzeba mieć kogoś, kto ją rozumie.

Czy własna serwerownia jest tańsza od chmury? Liczy się TCO

Po pierwszym dużym rachunku wraca pomysł: „kupimy serwery, wyjdzie taniej”. Czasem faktycznie wychodzi – przy stabilnym obciążeniu bez sezonowych szczytów. Warunek jest jeden: policzyć całkowity koszt posiadania (TCO), a nie samą cenę sprzętu. Do rachunku należą:

• kolokacja albo własne pomieszczenie: powierzchnia, zasilanie (również rezerwowe), chłodzenie, kontrola dostępu;
• łącza – najlepiej od dwóch operatorów, jeśli usługa ma być dostępna;
• licencje wirtualizacji i systemów, odnawiane co roku;
• części zapasowe i serwis, bo dysk padnie w piątek wieczorem;
• ludzie: nie tylko etat administratora, ale też dyżury i zastępstwa urlopowe – kompetencja musi istnieć w dwóch egzemplarzach;
• miejsce na kopie poza tą serwerownią, bo kopia obok serwera nie jest kopią (backup w chmurze);
• odświeżenie sprzętu co kilka lat i zapas mocy kupiony „na szczyt”, przez resztę roku stojący bezczynnie.

Uczciwa konkluzja: własny sprzęt bywa tańszy w koszcie jednostkowym i droższy w całkowitym – a różnica ujawnia się przy pierwszej awarii albo pierwszym urlopie administratora. Bywa i odwrotnie: przy płaskim obciążeniu płacenie za elastyczność nie ma sensu. Model mieszany – stabilna baza u siebie, szczyty i kopie zapasowe w chmurze – bywa optymalny częściej niż skrajności.

Jak nie przepłacać za chmurę? Cztery nawyki zamiast jednej negocjacji

1. Rightsizing. Zmierz rzeczywiste zużycie vCPU i RAM przez dwa–cztery tygodnie, zanim ustalisz rozmiar maszyny. Większość środowisk jest przewymiarowana, bo rozmiar dobrano „na oko” przy uruchomieniu i nikt do tego nie wrócił.
2. Harmonogram dla środowisk nieprodukcyjnych. Dev i test są potrzebne w godzinach pracy, a płaci się za nie całą dobę, siedem dni w tygodniu. Harmonogram wyłączeń poza godzinami pracy to zwykle najtańsza oszczędność w środowiskach nieprodukcyjnych – pod dwoma warunkami: ktoś ten harmonogram utrzymuje, a Ty wiesz, co dokładnie przestaje być liczone. Zatrzymana maszyna zwalnia procesor i pamięć, ale jej dysk zajmuje miejsce dalej – sprawdź to u dostawcy.
3. Dopasowanie nośnika do danych. Archiwum nie potrzebuje tej samej wydajności co dane produkcyjne – zanim zamówisz pojemność, sprawdź u dostawcy, jakie klasy nośnika oferuje i czym się różnią w cenie. Jak działa magazyn obiektowy i za co się w nim płaci, opisuje tekst o Object Storage w WebDisk.
4. Sprzątanie sierot. Raz na kwartał: dyski bez maszyn, snapshoty starsze niż polityka retencji, zarezerwowane i nieużywane adresy IP, stare wersje obiektów, środowiska po zakończonych projektach. To najnudniejsza godzina w kwartale i zwykle najlepiej płatna.

Dwa modele rozliczeń w WebDisk

Sporą część niespodzianek rozwiązuje model rozliczeń dopasowany do charakteru obciążenia – dlatego mamy dwa, opisane na stronie cennika:

• Model biznesowy – kupujesz pulę zasobów (vCPU, RAM, pojemność) i rozliczasz się fakturą w cyklu miesięcznym; kwota nie zmienia się wraz z bieżącym zużyciem tej puli. Dla organizacji, którym przewidywalność kosztu zastępuje rozliczanie co do godziny.
• Model ogólny – rozliczenie godzinowe za faktycznie zużyte zasoby, prepaid lub postpaid. Dla obciążeń zmiennych, testów i projektów o nieznanej z góry skali.

Modele działają w osobnych panelach i zasobów nie widać między nimi – jeśli potrzebujesz je połączyć, robi się to tunelem VPN site-to-site. Warto to uwzględnić przy wyborze. Warunki i stawki znajdziesz na stronach cennika, chmury publicznej i Object Storage – kwot nie podajemy w artykule celowo, bo blog starzeje się szybciej niż cennik.

Fundament naszej chmury to oprogramowanie open source – Apache CloudStack i Ceph – więc mechanizmy, na których stoi usługa, są publicznie udokumentowane, a integracje robisz standardowym API: s3cmd, awscli, boto3 czy dowolnym klientem zgodnym z S3. To ma związek z kosztami: standardowy interfejs sprawia, że migracja gdzie indziej jest projektem technicznym, a nie decyzją strategiczną. Kontekst prawny opisuje tekst o polskiej chmurze obliczeniowej.

Uczciwy bilans: czego tańsza chmura nie załatwi

• Niższa cena nie zastąpi projektu. Źle zaprojektowana architektura jest droga u każdego dostawcy – u tańszego po prostu wolniej to widać.
• Mniejszy dostawca to węższy katalog usług. Nie znajdziesz u nas kilkuset usług zarządzanych. Jeśli aplikacja stoi na specyficznej usłudze jednego hiperskalera, jej przeniesienie nie będzie darmowe – policz to po obu stronach.
• Oszczędność wymaga higieny. Rightsizing, harmonogramy i sprzątanie działają wszędzie, ale ktoś musi je robić. Jeśli nie ma kto – uwzględnij to w budżecie jako wsparcie.
• Tanio nie znaczy „za darmo”. Transfer, pojemność i kopie zapasowe kosztują u każdego dostawcy; różni się model i przejrzystość rozliczenia.
• Transfer liczymy i my – w jednym z modeli. W modelu godzinowym przepustowość jest pozycją rozliczaną jak vCPU czy pojemność, a w Object Storage plan zawiera 1 TB transferu miesięcznie i dopłatę za nadwyżkę. Stawki są na stronie usługi; nie ukrywamy tej pozycji za hasłem „bez opłat za transfer”.

Częste pytania

Czy warto trzymać wszystko u jednego dostawcy? Nie ma jednej odpowiedzi, ale warto wiedzieć, gdzie leżą dane i ile kosztowałoby ich wyprowadzenie. Kryterium „ile kosztuje wyjście” jest równie ważne jak „ile kosztuje wejście”.

Czy Data Act znosi opłaty za transfer danych z chmury? Tylko częściowo. Rozporządzenie, stosowane od 12 września 2025 r., ogranicza opłaty za samą zmianę dostawcy do faktycznych kosztów, a od 12 stycznia 2027 r. znosi je całkowicie. Nie obejmuje jednak zwykłego transferu wychodzącego w trakcie korzystania z usługi – ten nadal bywa płatny.

Czy da się przewidzieć rachunek przed uruchomieniem usług? W modelu godzinowym koszt szacujesz z sumy zamówionych zasobów i stawek godzinowych ze strony cennika; najpewniejsza prognoza to policzone zasoby i pojemność plus zapas na transfer i kopie zapasowe. W modelu z pulą zasobów rachunek znasz z góry.

Jak obniżyć rachunek za chmurę? Najwięcej dają cztery nawyki: rightsizing na podstawie zmierzonego zużycia, harmonogram wyłączeń środowisk nieprodukcyjnych poza godzinami pracy, dopasowanie klasy nośnika do charakteru danych oraz kwartalne sprzątanie zasobów-sierot – dysków bez maszyn, starych snapshotów, nieużywanych adresów IP. Działają u każdego dostawcy, ale ktoś musi je robić.

Mamy własne serwery – czy przenosiny się opłacą? To zależy od kształtu obciążenia i od tego, co obejmuje Twój obecny TCO. Jeśli nie ma w nim kosztu ludzi, zapasu mocy i odświeżenia sprzętu, porównanie będzie nieprawdziwe.

Podsumowanie

„Rozsądna cena” w chmurze nie bierze się z jednej negocjacji ani z jednego przełącznika. Bierze się z rozumienia, za co dokładnie płacisz – moc, pojemność, transfer, adresy, kopie – i z kilku nawyków, które trzymają te liczniki w ryzach. Reszta to wybór modelu rozliczeń pasującego do Twojego obciążenia: przewidywalna pula albo rozliczenie godzinowe.

Chcesz policzyć to na swoich danych? Sprawdź warunki na stronie cennika albo napisz do nas – pomożemy przeliczyć Twój scenariusz na naszym cenniku i powiemy wprost, czy przenosiny mają sens.