AWS bez kontroli: jak zapomniane środowiska testowe potrafią zjeść marżę firmy B2B

Coraz więcej firm z sektora B2B obserwuje niepokojącą zależność: faktura od dostawcy chmury rośnie regularnie, a biznes - liczba klientów, przychody, skala działania - pozostaje na podobnym poziomie. Szukając przyczyny, menedżerowie zwykle w pierwszej kolejności podejrzewają architekturę systemów produkcyjnych. Dokładniejszy przegląd wydatków w AWS zwykle wskazuje jednak na coś innego - zaniedbane, rozrośnięte i nikomu niepilnowane środowiska Dev, Test i staging. To właśnie one, jak się okazuje, najczęściej odpowiadają za nieuzasadniony wzrost kosztów.

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

W większości organizacji cała energia zarządcza idzie w stronę środowisk produkcyjnych - tam pilnuje się dostępności, bezpieczeństwa i wydajności. W obszarze Dev/Test panuje jednak zupełnie inna kultura, bliska niepisanej tolerancji dla operacyjnego bałaganu. Deweloperzy dostają szerokie uprawnienia do samodzielnego tworzenia zasobów, bo potrzebują szybkości działania. Gdy nie idzie za tym żadna procedura kontrolna, powstaje efekt zwany Cloud Sprawl - niekontrolowane mnożenie się maszyn wirtualnych, baz danych i przestrzeni dyskowej, które po zakończonych testach nikt nie usuwa.

Jeden serwer chmurowy postawiony na chwilę, by przetestować wydajność, sam w sobie nie wygląda na duży koszt. Problem zaczyna się, gdy takie działania mnoży kilkunastu inżynierów pracujących równolegle na kilkudziesięciu projektach - w skali roku suma robi się liczona w tysiącach dolarów wydanych bez realnego uzasadnienia. W software house'ach obsługujących klientów B2B rozrost zespołu programistycznego bez dojrzałych mechanizmów kontrolnych prowadzi zarząd do jednego wniosku: marża projektowa systematycznie się kurczy.

Skalę zjawiska potwierdzają dane branżowe. Analizy Gartnera wskazują, że ponad 30% wydatków firm na chmurę publiczną jest po prostu tracone - głównie z powodu przewymiarowania zasobów (overprovisioning) oraz braku wyłączania środowisk, które nie są aktualnie używane.

Dobrze ilustruje to przykład średniej wielkości software house'u B2B, dostarczającego rozwiązania klasy ERP. W ciągu roku liczba aktywnych klientów firmy praktycznie się nie zmieniła, mimo to miesięczna faktura z AWS wzrosła o 40%. Przeprowadzony audyt infrastruktury wykazał, że winne były tymczasowe środowiska klienckie tworzone przez zespół QA - kilkanaście instancji postawionych do jednorazowych testów integracyjnych działało nieprzerwanie przez blisko dziewięć miesięcy.

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

Nowe konta w chmurze zwykle korzystają z promocyjnych warunków proponowanych przez dostawcę. AWS Free Tier to dobre rozwiązanie do nauki, prototypowania czy testowania usług. Kłopoty zaczynają się, gdy organizacja próbuje uczynić z darmowego pakietu stały fundament budżetu na infrastrukturę deweloperską.

Według oficjalnych zasad AWS Free Tier darmowy limit dla popularnych instancji EC2 (np. t2.micro lub t3.micro) wynosi 750 godzin miesięcznie w ciągu pierwszych 12 miesięcy od założenia konta. To liczba godzin odpowiadająca w praktyce pracy jednej maszyny przez cały miesiąc. Jeśli zespół uruchomi równolegle cztery takie instancje testowe, darmowy limit wyczerpie się już po siedmiu dniach, a każda kolejna godzina zostanie rozliczona według standardowych stawek On-Demand.

Częstym błędem zarządczym bywa też brak śledzenia momentu, w którym konto przekracza próg 12 miesięcy od rejestracji. Po tym terminie promocyjny Free Tier wygasa, a dotychczas darmowe środowiska testowe zaczynają generować pełne opłaty z dnia na dzień. Bez alarmów skonfigurowanych w AWS Budgets informacja o zakończeniu okresu próbnego trafia do firmy zwykle w postaci nieoczekiwanie wysokiej faktury na koniec miesiąca.

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

Jednym z najbardziej kosztownych przyzwyczajeń przeniesionych z modelu on-premise jest trzymanie infrastruktury w trybie ciągłej pracy. W tradycyjnym centrum danych fizyczny serwer był już opłacony, więc jego nieprzerwane działanie nie zwiększało kosztów zmiennych. W chmurze publicznej domyślny model rozliczeń dla instancji EC2 wygląda inaczej - płaci się za realny czas pracy (On-Demand).

Instancja EC2, której nikt nie zatrzymuje, generuje opłaty za każdą sekundę działania - niezależnie od tego, czy procesor akurat wykonuje obliczenia, czy stoi bezczynnie (idle). Jeśli środowisko testowe jest wykorzystywane przez inżynierów jedynie w godzinach pracy, od poniedziałku do piątku między 9:00 a 17:00, realnie działa 40 godzin w tygodniu. Pozostawienie go włączonym cały tydzień oznacza jednak płacenie za 168 godzin. Innymi słowy, aż 76% poniesionych wydatków to koszt utrzymywania zasobów, z których nikt w danym momencie nie korzysta - nocą i w weekendy.

Skalę strat dobrze widać na przykładzie firmy utrzymującej 10 instancji testowych EC2 rozliczanych w modelu On-Demand w trybie harmonogramowanym (9:00-17:00, pon-pt). Suma opłat naliczanych za czas, w którym ze środowiska nikt nie korzysta, rośnie proporcjonalnie do skali projektu. Brak automatycznych harmonogramów wyłączania maszyn na noc i weekendy przekłada się bezpośrednio na to, jak wysoki staje się jednostkowy koszt utrzymania serwera w budżecie IT.

Błąd 3: zapomniane zasoby sieroce (EBS, Snapshots, Elastic IP)

Samo wyłączenie albo usunięcie instancji EC2 nie kończy problemu narastających opłat. Typowy błąd operacyjny polega na myśleniu, że skasowanie serwera równa się usunięciu wszystkich powiązanych z nim komponentów. W AWS poszczególne usługi są jednak rozliczane niezależnie od siebie.

Głównym źródłem skrytych kosztów są wolumeny Amazon EBS (Elastic Block Store), czyli dyski podłączane do maszyn wirtualnych. Zgodnie z dokumentacją opłat za wolumeny Amazon EBS dostawca pobiera stałą opłatę za zarezerwowaną pojemność, liczoną w gigabajtach na miesiąc, niezależnie od tego, czy dysk jest aktywnie podłączony do działającej instancji, czy funkcjonuje jako zasób sierocy (unattached volume). Jeśli programista usunie serwer testowy, ale nie zaznaczy opcji automatycznego usuwania dysku przy terminacji instancji, opłata za przestrzeń dyskową będzie naliczana bez przerwy.

• Automatyczne i ręczne migawki (EBS Snapshots / RDS Snapshots) - tworzone przed każdą istotną zmianą w kodzie, a potem zapominane; przechowywanie setek gigabajtów archiwalnych stanów dysków każdego miesiąca kosztuje realne pieniądze.
• Nieprzypisane elastyczne adresy IP (Elastic IP) - AWS nie obciąża rachunku za publiczny adres IP, dopóki jest on przypisany do działającej instancji EC2; po zatrzymaniu lub usunięciu serwera adres, który zostaje nieprzypisany, zaczyna generować opłatę za każdą godzinę bezczynności.
• Porzucone bazy danych Amazon RDS - środowiska bazodanowe stawiane na potrzeby jednego sprintu, które po jego zakończeniu nadal działają i odpowiadają na zapytania od serwisów, które już dawno zostały wyłączone.

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

Trudno zarządzać czymś, czego nie można zmierzyć. W wielu firmach korzystających z AWS zbiorczy rachunek traktowany jest jak jedna, niepodzielna pozycja w kosztach stałych. Kiedy zarząd pyta, który zespół albo która usługa odpowiada za skok wydatków, brak odpowiedniej struktury danych uniemożliwia udzielenie konkretnej odpowiedzi.

Podstawowym mechanizmem 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, by w pełni korzystać z alokacji kosztów w AWS Cost Explorer i AWS Budgets.

• Brak rozróżnienia środowisk - pominięcie podstawowych tagów, takich jak Environment=Production i Environment=Test, utrudnia szybkie oddzielenie kosztów obsługi klienta od kosztów wytwarzania oprogramowania.
• Brak przypisania właściciela - zasoby bez etykiet Owner lub Team sprawiają, że nikt w organizacji nie czuje się odpowiedzialny za ich późniejsze usunięcie.
• Brak standaryzacji nazw - niekonsekwentne stosowanie wielkości liter (np. env:dev, Environment:Dev, ENV:DEVELOPMENT) powoduje, że raporty finansowe traktują te same kategorie jako odrębne grupy, zniekształcając obraz wydatków.

Bez wdrożonej polityki tagowania nie da się jasno wyznaczyć odpowiedzialności biznesowej za koszty. W efekcie kierownictwo widzi jedynie rosnącą kwotę na fakturze, nie mając wiedzy, które projekty badawczo-rozwojowe generują straty, a które trzymają się zakładanego budżetu.

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

Uporządkowanie wydatków w chmurze nie wymaga drastycznego ograniczania zasobów dla zespołów inżynieryjnych. Kluczem jest zmiana podejścia operacyjnego i automatyzacja nadzoru nad infrastrukturą. Jak wskazują standardy 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 można oprzeć na czterech filarach:

1. Automatyzacja cyklu życia (Lifecycle Automation) - wdrożenie gotowych narzędzi, takich jak AWS Instance Scheduler, albo własnych skryptów opartych na AWS Lambda i Amazon EventBridge, które 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, które wysyłają maile lub wiadomości na Slacku zespołu, gdy prognozowane wydatki dla danego tagu (np. Environment=Test) przekroczą 80% zakładanego budżetu miesięcznego.
3. Wykorzystanie instancji Spot - przeniesienie bezstanowych testów automatycznych i procesów CI/CD na instancje EC2 Spot, co pozwala ograniczyć koszty mocy obliczeniowej względem stawek On-Demand, przy założeniu, że praca maszyny może zostać przerwana przez dostawcę.
4. Weryfikacja infrastruktury i dojrzałość procesowa - regularne audyty umożliwiające szybkie wykrywanie sierocych dysków EBS, nieużywanych adresów IP oraz przestarzałych migawek.

Wprowadzenie tych zmian wymaga połączenia wiedzy architektonicznej z pragmatycznym podejściem biznesowym. Wsparciem może być tu współpraca z zewnętrznym partnerem - specjalistyczne usługi optymalizacji kosztowej FinOps od Devopsity pomagają precyzyjnie zlokalizować obszary marnotrawstwa, wdrożyć polityki automatyzacji i przeszkolić zespół w dobrych praktykach zarządzania chmurą, bez ryzyka dla ciągłości dostarczania oprogramowania. Odzyskanie kontroli nad środowiskami testowymi to najszybsza droga do zmniejszenia rachunku za AWS i ochrony marży firmy działającej w modelu B2B.