Rachunek za chmurę rośnie z miesiąca na miesiąc, a baza użytkowników oraz przychody firmy pozostają na zbliżonym poziomie. To scenariusz, z którym zmaga się wielu liderów technologicznych w sektorze B2B. Pierwszym podejrzanym zazwyczaj staje się architektura produkcyjna, jednak szczegółowa analiza wydatków w AWS często ujawnia zupełnie inne źródło problemu. Są nim zapomniane, niekontrolowane i przewymiarowane środowiska nieprodukcyjne: deweloperskie, testowe oraz stagingowe. Analizując w AWS koszty, warto w pierwszej kolejności przyjrzeć się właśnie tym obszarom.

Podstawowe błędy w zarządzaniu budżetem IT: Dlaczego środowiska testowe przepalają budżet

Główna uwaga kadry zarządzającej skupia się na środowiskach produkcyjnych. To tam dba się o wysoką dostępność, bezpieczeństwo i wydajność. Tymczasem w obszarze Dev/Test panuje ciche przyzwolenie na pobłażliwość operacyjną. Zespoły programistyczne potrzebują elastyczności, więc otrzymują uprawnienia do szybkiego powoływania nowych zasobów. Bez odpowiednich procedur prowadzi to do zjawiska określanego jako Cloud Sprawl – niekontrolowanego przyrostu maszyn wirtualnych, baz danych i zasobów dyskowych, które po zakończeniu testów nie są usuwane.

Pojedynczy serwer chmurowy uruchomiony na potrzeby krótkiego testu wydajności wydaje się tanim zasobem. Pomnożenie go przez kilkunastu inżynierów i kilkadziesiąt projektów generuje w skali roku tysiące dolarów nieuzasadnionych wydatków. W firmach software'owych B2B rozwój zespołu programistycznego bez dojrzałych mechanizmów kontroli sprawia, że zarząd obserwuje stały spadek marży projektowej.

Rozmiar tego problemu potwierdzają dane rynkowe. Z analiz opublikowanych w raportach branżowych Gartnera wynika, że ponad 30% wydatków na chmurę publiczną w organizacjach jest marnotrawione. Głównymi przyczynami tego stanu rzeczy są niewłaściwe skalowanie zasobów (overprovisioning) oraz brak wyłączania nieużywanych środowisk.

Rozważmy przypadek średniej wielkości spółki software'owej B2B, dostarczającej systemy klasy ERP. W ciągu roku firma nie zwiększyła znacząco liczby aktywnych klientów, jednak jej miesięczna faktura od AWS wzrosła o 40%. Audyt infrastruktury wykazał, że za skok odpowiadało kilkanaście tymczasowych środowisk klienckich tworzonych przez zespół QA. Środowiska te, postawione do jednorazowych testów integracyjnych, działały bez przerwy przez niemal dziewięć miesięcy.

Błąd 1: Pułapka AWS Free Tier i brak ewidencji darmowych limitów

Tworzenie nowych kont w chmurze często wiąże się z wykorzystaniem promocyjnych warunków oferowanych przez dostawcę. AWS Free Tier stanowi świetne narzędzie do nauki, prototypowania i testowania usług. Problemy pojawiają się w momencie, gdy organizacja zaczyna traktować darmowy pakiet jako substytut stałego budżetu na infrastrukturę deweloperską.

Zgodnie z oficjalnymi zasadami AWS Free Tier, darmowy limit na popularne instancje EC2 (np. t2.micro lub t3.micro) wynosi 750 godzin miesięcznie przez pierwsze 12 miesięcy od założenia konta. Wartość ta odpowiada dokładnej liczbie godzin w miesiącu dla jednej uruchomionej maszyny. Jeśli zespół deweloperski powoła równolegle cztery takie instancje testowe, darmowy limit wyczerpie się już po siedmiu dniach. Każda kolejna godzina pracy tych serwerów zostanie rozliczona według standardowych stawek On-Demand.

Częstym błędem zarządczym jest brak monitorowania momentu, w którym konto przekracza próg 12 miesięcy od rejestracji. Po upływie tego okresu promocyjne free tier wygasa, a dotychczas „darmowe” środowiska testowe z dnia na dzień zaczynają generować pełne opłaty. Bez ustawionych alarmów w AWS Budgets informacja o końcu okresu próbnego dociera do firmy dopiero w postaci zaskakująco wysokiej faktury pod koniec miesiąca.

Błąd 2: Serwer chmurowy działający 24/7 dla testów od 9:00 do 17:00

Jednym z najbardziej kosztownych nawyków przeniesionych ze środowisk on-premise jest utrzymywanie infrastruktury w trybie ciągłym. W tradycyjnym modelu centrum danych serwer fizyczny został kupiony, więc jego ciągła praca nie generowała dodatkowych kosztów zmiennych. W chmurze publicznej domyślnym modelem rozliczeniowym dla instancji EC2 jest płatność za faktyczny czas działania (On-Demand).

Niezatrzymana instancja EC2 generuje koszty za każdą sekundę pracy, niezależnie od tego, czy procesor wykonuje skomplikowane obliczenia, czy pozostaje całkowicie bezczynny (idle). Jeśli środowisko testowe jest wykorzystywane przez zespół inżynierów wyłącznie w godzinach pracy – od poniedziałku do piątku w godzinach 9:00–17:00 – działa efektywnie przez 40 godzin w tygodniu. Pozostawienie go w stanie włączonym przez cały tydzień oznacza płacenie za 168 godzin. Innymi słowy, 76% poniesionych wydatków to koszt utrzymywania nieużywanych zasobów podczas nocy i weekendów.

Aby zobrazować skalę strat, przeanalizujmy scenariusz, w którym firma utrzymuje 10 instancji testowych EC2 rozliczanych w trybie On-Demand:

Suma opłat za czas, w którym nikt nie korzysta ze środowiska, rośnie wraz ze skalą projektu. Brak automatycznych harmonogramów wyłączania maszyn wirtualnych na noc i weekendy bezpośrednio przekłada się na to, jak wysoki staje się jednostkowy koszt serwera w budżecie IT.

Błąd 3: Zapomniane zasoby sierocze (EBS, Snapshots, Elastic IP)

Wyłączenie lub usunięcie samej instancji EC2 nie rozwiązuje w pełni problemu narastających opłat. Podstawowy błąd operacyjny polega na utożsamianiu skasowania serwera z całkowitym usunięciem wszystkich powiązanych z nim komponentów. W chmurze AWS poszczególne usługi są od siebie odseparowane pod kątem rozliczeniowym.

Kluczowym źródłem ukrytych opłat są wolumeny Amazon EBS (Elastic Block Store), czyli dyski podłączone do maszyn wirtualnych. Zgodnie z dokumentacją opłat za wolumeny Amazon EBS, AWS pobiera stałą opłatę za zarezerwowaną pojemność (wyrażoną w gigabajtach na miesiąc) bez względu na to, czy dysk jest podłączony do działającej instancji, czy istnieje jako zasób sierocy (unattached volume). Jeśli programista skasuje serwer testowy, ale odznaczy opcję automatycznego usuwania dysku przy terminacji, opłata za pamięć masową będzie naliczana nieprzerwanie.

Do kategorii zasobów sierocych zaliczają się również:

• Automatyczne i ręczne migawki (EBS Snapshots / RDS Snapshots): Tworzone przed każdą większą zmianą w kodzie, a następnie zapominane. Przechowywanie setek gigabajtów historycznych stanów dysków kosztuje konkretne pieniądze każdego miesiąca.

• Nieprzypisane elastyczne adresy IP (Elastic IP): AWS nie pobiera opłat za publiczny adres IP tak długo, jak jest on przypisany do uruchomionej instancji EC2. W momencie zatrzymania lub usunięcia serwera nieprzypisany adres IP zaczyna generować stałą opłatę za każdą godzinę bezczynności.

• Porzucone bazy danych Amazon RDS: Środowiska bazy danych utworzone na potrzeby pojedynczego sprintu, które po jego zakończeniu wciąż działają i przyjmują zapytania wyłącznie od wyłączonych już serwisów.

Błąd 4: Brak strategii tagowania i zerowa widoczność kosztów

Nie można efektywnie zarządzać czymś, czego nie da się zmierzyć. W wielu organizacjach działających w AWS rachunek zbiorczy jest traktowany jako jedna, nienaruszalna pozycja w kosztach stałych firmy. Gdy zarząd pyta, która usługa lub który zespół odpowiada za skok wydatków, brak odpowiedniej struktury uniemożliwia podanie precyzyjnej odpowiedzi.

Podstawowym narzędziem do alokacji wydatków w chmurze są tagi zasobów (Resource Tags) – pary klucz-wartość przypisywane do każdego elementu infrastruktury. Zgodnie z praktykami tagowania zasobów według AWS, spójny system etykietowania jest warunkiem koniecznym do aktywacji alokacji kosztów w narzędziach AWS Cost Explorer oraz AWS Budgets.

Najczęstsze uchybienia w tym obszarze to:

• Brak rozróżnienia środowisk: Brak podstawowych tagów, takich jak Environment=Production oraz Environment=Test, co uniemożliwia szybkie oddzielenie kosztów utrzymania klienta od kosztów wytwarzania oprogramowania.

• Brak przypisania właściciela: Zasoby pozbawione etykiet Owner lub Team sprawiają, że żaden menedżer nie czuje się odpowiedzialny za ich późniejsze usunięcie.

• Brak standaryzacji nazw: Używanie wielkości liter w sposób nieuporządkowany (np. env:dev, Environment:Dev, ENV:DEVELOPMENT) powoduje, że raporty finansowe traktują te same kategorie jako osobne grupy, fałszując obraz wydatków.

Bez wdrożonej polityki tagowania niemożliwe jest wyznaczenie odpowiedzialności biznesowej. W efekcie kadra kierownicza widzi jedynie rosnącą kwotę końcową na fakturze, nie mając wiedzy, które projekty R&D generują stratę, a które mieszczą się w zakładanym budżecie.

Od chaosu do FinOps: Jak odzyskać kontrolę nad rachunkiem za AWS

Opanowanie niekontrolowanych wydatków w chmurze nie wymaga drastycznego ograniczania zasobów dla zespołów inżynieryjnych. Rozwiązaniem jest zmiana podejścia operacyjnego i automatyzacja kontroli nad infrastrukturą. Zgodnie ze standardami FinOps Foundation, FinOps to praktyka kulturowa i operacyjna łącząca finanse, technologię i biznes, której celem jest optymalizacja wartości biznesowej chmury, a nie bezrefleksyjne cięcie wydatków.

Skuteczny proces odzyskiwania kontroli nad budżetem w AWS opiera się na czterech filarach:

1. Automatyzacja cyklu życia (Lifecycle Automation): Wdrożenie gotowych narzędzi, takich jak AWS Instance Scheduler, lub własnych skryptów opartych na AWS Lambda i Amazon EventBridge. Mechanizmy te automatycznie zatrzymują instancje EC2 i bazy RDS w środowiskach nieprodukcyjnych po godzinach pracy oraz w weekendy.

2. Aktywne limity i alarmy (AWS Budgets): Skonfigurowanie twardych powiadomień finansowych. System powinien wysyłać maile lub wiadomości na kanale Slack zespołu w momencie, gdy prognozowane wydatki dla danego tagu (np. Environment=Test) przekroczą 80% założonego budżetu miesięcznego.

3. Wykorzystanie instancji Spot: Przeniesienie bezstanowych testów automatycznych oraz procesów CI/CD na instancje EC2 Spot. Pozwala to na redukcję kosztów mocy obliczeniowej w stosunku do stawek On-Demand, przy pełnej akceptacji dla ewentualnego przerwania pracy maszyny przez dostawcę.

4. Weryfikacja infrastruktury i dojrzałość procesowa: Regularne audyty pozwalające na natychmiastowe wykrywanie sierocych dysków EBS, nieużywanych adresów IP i przestarzałych migawek.

Wprowadzenie tych zmian wymaga łączenia wiedzy architektonicznej z pragmatyką biznesową. Pomocne bywa wykorzystanie zewnętrznego wsparcia – wyspecjalizowane usługi optymalizacji kosztowej FinOps od Devopsity pozwalają precyzyjnie zidentyfikować obszary marnotrawstwa, wdrożyć polityki automatyzacji oraz przeszkolić zespół w zakresie dobrych praktyk zarządzania chmurą, bez ryzyka dla płynności dostarczania oprogramowania. Odzyskanie kontroli nad środowiskami testowymi to najszybsza droga do obniżenia rachunku za AWS i zabezpieczenia marży firmy B2B.

Artykuł sponsorowany