Widzę to na każdym kroku. Przedsiębiorca dumny ze swojego SaaS, dumny z e-commerce, który działa w chmurze. A potem przychodzi faktura i… szok. Cloud kosztuje więcej niż czynsz za biuro. I to nie przez przewidywany wzrost ruchu, ale przez zasoby, które śpią. W ciągu ostatnich dwóch lat, rozmawiając z kilkudziesięcioma founderami małych i średnich firm, wyłoniłem trzy główne przyczyny tych kosztownych niespodzianek. I co ważniejsze – trzy strategie, które realnie pozwalają odzyskać te pieniądze.
1. Niepotrzebne środowiska i bezużyteczne snapshooty
Zaczyna się niewinnie. Zespół deweloperski chce testować nową funkcję. Tworzy środowisko testowe. Potem kolejne. A po wdrożeniu – nikt go nie wyłącza. Ba, często nikt nie wie, że ono w ogóle istnieje. W chmurze publicznej, zwłaszcza przy modelu pay-as-you-go, takie „zapomniane” instancje potrafią generować setki, a nawet tysiące złotych miesięcznie.
Pamiętam przypadek startupu z sektora fintech. Mieli 12 środowisk testowych. W rzeczywistości potrzebowali najwyżej 4. Reszta wisiała, bo kiedyś ktoś postawił je do sprintu – i tyle. Rachunek za chmurę skoczył im nagle o 40% w ciągu kwartału. Okazało się, że te „niepotrzebne” środowiska jadły łącznie 200 GB pamięci RAM i 60 rdzeni CPU. Gdyby ktoś regularnie nie monitorował, dalej płaciliby za powietrze.
Rozwiązanie? Wprowadź politykę lifecycle’u dla zasobów. Automatyczne wygaszanie instancji po 30 dniach bez aktywności. W AWS to CloudFormation, w Azure – Automation Accounts, w GCP – Cloud Scheduler. Wystarczy skrypt, który codziennie rano sprawdza, czy dana maszyna była używana. A jeśli nie – wyłącza ją. Oszczędność? 20-30% miesięcznego rachunku u niektórych moich klientów.
Drugi rodzaj bezużytecznych kosztów to migawki dysków (snapshooty). Kiedyś potrzebne do backupu przed aktualizacją – niby tanie, ale z miesiąca na miesiąc narastają. W jednej firmie e-commerce mieli ponad 300 snapshotów sprzed dwóch lat. Żaden nie był już potrzebny. Każdy kosztował kilka złotych miesięcznie – w sumie prawie tysiąc złotych miesięcznie za nic.
2. Źle dobrane instancje i overprovisioning
Kolejny klasyk. Deweloper zakłada, że aplikacja będzie potrzebować dużo RAM-u, więc wybiera instancję z 16 GB. Albo że procesor musi być najszybszy. Tylko że po wdrożeniu okazuje się, że aplikacja wykorzystuje zaledwie 20% CPU i 30% RAM. Reszta przepada. To tak, jakbyś wynajął magazyn 500 m², a postawił tam tylko jeden regał.
Sytuacja gorsza w e-commerce, gdzie ruch często jest sezonowy. W black week sklep potrzebuje 10 razy więcej zasobów niż w zwykły wtorek. Jeśli instancja jest skalowana ręcznie albo w ogóle nie jest skalowana – przez resztę roku płacisz za moc, która stoi bezczynnie.
Rozwiązanie? Po pierwsze, regularny audyt użycia. W AWS to Cost Explorer, w Azure – Advisor, w GCP – Recommender. Pokazują, które instancje są przewymiarowane. Potem wystarczy zmienić typ na mniejszy. Oszczędności potrafią sięgać 50% dla poszczególnych serwerów.
Po drugie, auto-scaling. Nie, to nie jest skomplikowane. W praktyce dla małej firmy oznacza ustawienie progów – gdy CPU przekroczy 70%, system automatycznie dodaje kolejną instancję. Gdy spadnie poniżej 30% – usuwa. Działa to świetnie w przypadku frontendowych serwerów aplikacji. W jednym z SaaSów z branży HR obniżyliśmy rachunek za chmurę o 35%, wprowadzając auto-scaling tylko dla głównej usługi.
3. Zapomniane usługi i ukryte opłaty
Chmura to nie tylko maszyny wirtualne. To też bazy danych, kolejki, funkcje serverless, load balancery. I każda z tych usług często ma swoją własną strukturę cenową. Klient często bierze bazę danych z 10 TB przestrzeni, a potrzebuje 1 TB. Albo płaci za transfer danych między regionami, nie zdając sobie sprawy, że można to zrobić w jednym.
Najbardziej irytujący jest przypadek, gdy firma płaci za usługę, z której korzystały już tylko dane testowe. Na przykład Elasticsearch do logowania – niby potrzebny, ale po miesiącu dwie trzecie danych to archiwalne logi z błędami, na które nikt nie patrzy.
Rozwiązanie? Po pierwsze, audyt wszystkich aktywnych usług. W konsoli chmurowej zobaczysz, co jest uruchomione. Wyłącz wszystko, co nie jest niezbędne. Po drugie, ustal budget alerts – dostajesz e-maila, gdy koszty przekroczą ustalony próg. To działa psychologicznie – zespół wie, że budżet jest kontrolowany, więc rzadziej tworzy niepotrzebne zasoby.
W jednej firmie zajmującej się automatyką domową odkryliśmy nieużywany load balancer, który wisiał od roku. Kosztował 200 zł miesięcznie. Niby drobne, ale w skali roku 2400 zł – tyle samo co nowy laptop. A takich „drobnych” zapomnianych usług było 7.
Podsumowanie – jak zacząć oszczędzać już dziś?
- Monitoring to podstawa – bez niego nie wiesz, co płacisz. Skonfiguruj Cost Explorer lub alternatywę i przeglądaj go raz w tygodniu.
- Ustal politykę zarządzania zasobami – automatyczne wygaszanie, tagowanie odpowiedzialnością, przegląd snapshotów co kwartał.
- Szkol zespół – jeśli deweloperzy nie wiedzą, że instancje z 8 GB RAM kosztują, będą wybierać największe. Pokaż im koszty.
Oszczędności rzędu 30-50% nie są mitem. Są realne, ale wymagają konsekwencji. A jeśli nie masz czasu na audyt clouda – to też jest sygnał, że być może potrzebujesz kogoś z zewnątrz, kto spojrzy na to świeżym okiem. Bo chmura ma być narzędziem do wzrostu, a nie dziurą w budżecie.
