Koszty chmury AWS: lekcje z redukcji rachunków o połowę

Koszty chmury AWS: lekcje z redukcji rachunków o połowę

Nie chodzi o podatki, których nikt nie lubi, ale o serwery świecące pustkami w nocy, dyski, do których nikt nie zagląda, oraz licencje kupione „na zapas”, bo tak kazała prezentacja na konferencji. To wartość zbiorcza, nie rachunek wystawiony każdej firmie według tego samego wzoru. Ale nawet jako średni obraz rynku brzmi wystarczająco źle.

Dla startupu, który właśnie dostał fakturę na siedmiocyfrową kwotę, różnica między rozsądnym wykorzystaniem chmury a kosztowym chaosem może oznaczać kolejną rundę finansowania albo list intencyjny do działu windykacji.

Mit „chmura równa się skalowalność, a skalowalność równa się sukces” ma swoją cenę. I to dosłownie. Firmy odkrywają tę prawdę w bolesnym procesie, który w branży nazywa się eufemistycznie „dojrzewaniem”. Najpierw infrastruktura ma być gotowa na każdy możliwy skok ruchu. Później ktoś zaczyna czytać rachunek i pyta, dlaczego firma płaci za gotowość na wydarzenie, które odbyło się raz, albo nie odbyło się wcale.

Optymalizacja kosztów chmury AWS w firmie nie zaczyna się więc od modnego hasła ani od wielkiej migracji. Zaczyna się od sprawdzenia, co naprawdę działa, kiedy działa i kto podjął decyzję, żeby za to płacić.

Skala marnotrawstwa: około jedna trzecia wydatków w próżnię

Zanim zaczniemy rozkminiać, jak zmniejszyć rachunek za AWS, trzeba dobrze nazwać problem. Według danych Flexera około jedna trzecia wydatków przedsiębiorstw na chmurę jest marnowana. To nie mediana i nie uniwersalna reguła mówiąca, że każda firma traci dokładnie 33% budżetu. Jedne organizacje będą daleko poniżej tego poziomu, inne — zwłaszcza te, które szybko rosły bez kontroli kosztowej — mogą marnować znacznie więcej.

Wniosek jest jednak praktyczny: skala problemu nie jest marginalna. Nie mówimy o kilku nieużywanych dyskach, które ktoś powinien usunąć przy okazji porządków. Mówimy o pozycji kosztowej, która potrafi rosnąć razem z zespołem, liczbą środowisk i kolejnymi eksperymentami produktowymi, a jednocześnie pozostawać poza czyjąkolwiek odpowiedzialnością.

Skąd to się bierze? Mechanizm jest prosty i bolesny. Zespół techniczny dostaje zielone światło od zarządu, słyszy hasło „skalowalność” i zaczyna zamawiać zasoby z dużym zapasem. Instancje są dobierane tak, żeby wytrzymały przyszły ruch, którego nikt jeszcze nie zmierzył. Pamięć masowa ląduje w najwyższym dostępnym tierze, bo „backup musi być pewny”. Rezerwy są kupowane na lata, zanim ktokolwiek sprawdzi, jak stabilne będzie obciążenie.

To klasyczny overprovisioning: zamawiasz z górką, żeby mieć bufor na „czarny piątek”, ale czarny piątek przychodzi raz, a rachunek przychodzi co miesiąc. Zapas ma sens, kiedy jest świadomą decyzją opartą na danych. Przestaje mieć sens, kiedy staje się domyślnym ustawieniem całej infrastruktury.

Drugi winowajca to środowiska deweloperskie i testowe, które żyją wiecznie. Programista uruchomił klaster rano, żeby zdebugować jeden mikroserwis, wrócił wieczorem do domu i zapomniał go wyłączyć. Albo lepiej: w piątek wdrożenie się udało, nikt nie myśli o wyłączaniu, bo rachunek i tak przyjdzie „później”. W poniedziałek zaczyna się kolejny etap pracy, powstaje następne środowisko, a poprzednie nadal działa.

Pojedyncza zapomniana instancja nie wygląda groźnie. Kilkanaście zespołów, kilka kont AWS, osobne środowiska dla testów integracyjnych i projektów tymczasowych — i nagle „tylko testy” zajmują sporą część miesięcznego budżetu. Najgorsze jest to, że taki koszt zwykle nie ma właściciela. Deweloper uważa, że odpowiada za działanie aplikacji. Finanse widzą zbiorczą fakturę. Kierownik projektu widzi termin. Nikt nie widzi zasobu, który od trzech tygodni pracuje dla nikogo.

Trzeci, bardziej wyrafinowany problem to źle dobrany typ pamięci masowej. W świecie AWS często oznacza to pozostawanie przy starszych generacjach dysków, takich jak GP2, mimo dostępności GP3, które mogą zapewnić lepszą wydajność przy niższym koszcie za gigabajt. Taka zmiana nie brzmi jak projekt, którym można otworzyć konferencję technologiczną. Właśnie dlatego często przegrywa z pilniejszymi zadaniami.

Dla firmy, która przechowuje duże ilości danych w EBS, suma małych różnic szybko przestaje być mała. Problem polega nie tylko na cenie samego wolumenu. Dochodzą dodatkowe operacje wejścia-wyjścia, kopie, migawki, logi oraz zasoby pozostawione po migracjach. Nie każda oszczędność wymaga zmiany kodu. Czasem wymaga po prostu porównania tego, co firma ma skonfigurowane, z tym, czego faktycznie używa.

Według danych Flexera około jedna trzecia wydatków przedsiębiorstw na chmurę jest marnowana. To nie wyrok dla każdej firmy, ale wystarczający powód, żeby przestać traktować rachunek AWS jak pogodę.

Anatomia optymalizacji: od eliminacji overprovisioningu po GP3

Zanim ktoś rzuci hasłem „migracja na serverless” albo „konteneryzacja wszystkiego”, warto wrócić do podstaw. Optymalizacja kosztów AWS nie zaczyna się od przebudowy architektury. Zaczyna się od pytania: za co konkretnie płacimy i czy ten wydatek ma związek z działającym produktem?

Pierwszym krokiem jest rightsizing, czyli dopasowanie rozmiaru instancji do rzeczywistego obciążenia. Firmy często zamawiają większe instancje na początku projektu, gdy nie znają jeszcze profilu ruchu. To rozsądne jako rozwiązanie tymczasowe. Problem zaczyna się wtedy, gdy tymczasowa konfiguracja zostaje na kolejne miesiące, bo nikt nie ma czasu wrócić do decyzji.

Samo zmniejszenie instancji nie powinno być jednak wykonywane na podstawie jednego odczytu z panelu. Trzeba spojrzeć na obciążenie w czasie, okresy szczytowe, pamięć, operacje dyskowe i zachowanie aplikacji po zmianie. Instancja wykorzystywana przez większość dnia w niewielkim stopniu może mieć krótki, ale krytyczny skok obciążenia. Jeśli go nie zauważymy, oszczędność na fakturze zamieni się w awarię, a wtedy rachunek będzie miał zupełnie inny charakter.

Drugi obszar to harmonogramy. AWS Instance Scheduler może automatycznie wyłączać zasoby poza godzinami pracy, co szczególnie dobrze działa w środowiskach deweloperskich, testowych i szkoleniowych. Potencjał oszczędności może sięgać 70%, ale to maksymalny potencjał wynikający z ograniczenia czasu działania zasobów, a nie obietnica, że każda firma obniży rachunek o 70%. Jeśli środowisko już pracuje tylko kilka godzin dziennie, efekt będzie mniejszy. Jeśli działa bez przerwy i rzeczywiście można je wyłączać na noc oraz w weekendy, wynik może być wyraźny.

Ważne jest też, żeby harmonogram nie był jedynie techniczną funkcją bez właściciela. Zespół musi wiedzieć, kiedy środowisko zostanie wyłączone, jak je uruchomić oraz które zasoby są wyłączone z reguły, bo służą na przykład do testów nocnych. Automatyzacja, której nikt nie rozumie, szybko zostaje wyłączona po pierwszym incydencie.

Migracja pamięci masowej z GP2 na GP3 to mniejsza operacja, ale w dużej infrastrukturze może dać konkretny efekt. Nowsze wolumeny pozwalają niezależnie podejść do pojemności i wydajności, co ułatwia dopasowanie konfiguracji do rzeczywistych potrzeb. Nie trzeba przy tym przebudowywać aplikacji. Trzeba natomiast sprawdzić zależności, okna serwisowe, politykę kopii zapasowych i zachowanie obciążonych baz danych.

W praktyce pierwsze działania optymalizacyjne zwykle układają się w taki porządek:

1. Usunięcie zasobów osieroconych — nieużywanych wolumenów, starych migawek, adresów, kopii i środowisk pozostałych po zakończonych projektach.

2. Dopasowanie rozmiarów instancji — na podstawie rzeczywistego obciążenia, a nie pierwotnych założeń z dnia uruchomienia projektu.

3. Automatyczne harmonogramy — szczególnie dla środowisk, które nie muszą działać w nocy i w weekendy.

4. Zmiana klas pamięci masowej — tam, gdzie starszy typ wolumenu nie daje już uzasadnienia kosztowego.

5. Dopiero później decyzje zakupowe — Savings Plans, Reserved Instances albo Spot, kiedy firma zna już własny profil zużycia.

Reserved Instances i Savings Plans należą do innej kategorii. Tu pytanie brzmi: czy firma wie, jaki profil obciążeń będzie miała w najbliższym roku albo trzech latach? Rezerwacja, która okazała się nietrafiona, działa jak niewykorzystany karnet na siłownię. Pieniądze zostały wydane, ale nie przynoszą oczekiwanego efektu.

Maksymalny rabat oferowany przez Savings Plans może sięgać 72%, a Reserved Instances oferują podobne poziomy. To jednak nie oznacza automatycznej oszczędności w każdej konfiguracji. Trzeba porównać zobowiązanie z cenami On-Demand, sprawdzić zakres usług i ocenić, czy obciążenie będzie wystarczająco stabilne. W przeciwnym razie firma kupi rabat na zasoby, których za kilka miesięcy przestanie potrzebować.

Na instancjach Spot można zejść jeszcze niżej, nawet do 90% rabatu, ale tu wymagana jest tolerancja na przerwanie pracy maszyny. Spot dobrze pasuje do zadań odpornych na zakłócenia: przetwarzania wsadowego, eksperymentów, części środowisk testowych czy niektórych obciążeń o charakterze elastycznym. Nie jest magicznym zamiennikiem dla każdego serwera produkcyjnego. Najtańsza instancja jest bezwartościowa, jeśli aplikacja nie potrafi obsłużyć jej zniknięcia.

Przykład wart zapamiętania? Firma reklamowa Anzu. Po migracji do AWS w 2024 roku obniżyła miesięczne koszty chmury o 50%, a liczbę serwerów zmniejszyła o 40%. Wcześniej rachunek wynosił około dwóch milionów dolarów rocznie, po migracji był niższy o około milion. To są liczby, które w prezentacji dla rady nadzorczej wyglądają jak wyrok śmierci dla dotychczasowego dostawcy. Nie chodziło jednak o jeden rewolucyjny trik. Ktoś w końcu policzył, co faktycznie działa, a co było tylko pozostałością po wcześniejszych założeniach.

FinOps w praktyce: nawyk, nie projekt jednorazowy

FinOps, czyli zarządzanie finansowym wymiarem operacji chmurowych, bywa traktowany jak kolejna metodyka wymyślona po to, żeby dorobić na konsultingu. Tyle że problem, który ma rozwiązać, jest całkiem realny. Chmura nie ma dźwigni, którą można dokręcić raz na zawsze. Cennik się zmienia, obciążenia się zmieniają, architektura się zmienia, a ludzie w zespołach zmieniają się najszybciej ze wszystkiego.

Dobrze działający FinOps nie polega na tym, że jedna osoba z finansów dostaje dostęp do konsoli AWS i raz w miesiącu wysyła wszystkim tabelę z pretensjami. Chodzi o połączenie danych kosztowych z decyzjami technicznymi. Zespół, który uruchamia nową usługę, powinien wiedzieć, jaki będzie jej koszt. Zespół, który zwiększa pojemność, powinien umieć powiedzieć, dlaczego robi to właśnie teraz. Finanse nie muszą zatwierdzać każdej instancji, ale muszą mieć możliwość zobaczenia, gdzie pieniądze znikają.

W praktyce FinOps oznacza trzy rzeczy.

Po pierwsze, widoczność. Firma musi wiedzieć, kto, za co i ile płaci. Nie wystarczy zbiorcza faktura dla całej organizacji. Potrzebny jest podział na zespoły, produkty, środowiska i usługi. Bez poprawnych tagów, kont oraz centrów kosztów rozmowa o odpowiedzialności szybko zamienia się w zgadywanie.

Po drugie, odpowiedzialność. Zespół deweloperski powinien widzieć koszt własnych decyzji, a nie tylko abstrakcyjny rachunek działu infrastruktury. Nie chodzi o karanie za każdy wzrost wydatków. Czasem większy rachunek oznacza większy ruch i sukces produktu. Chodzi o odróżnienie wzrostu wynikającego z biznesu od wzrostu wynikającego z zapomnianego środowiska.

Po trzecie, automatyzacja. AWS Instance Scheduler, Auto Scaling w Amazon ECS i reguły reagujące na wykorzystanie zasobów mogą wykonywać powtarzalne czynności bez proszenia kierownika projektu o zgodę na każdą zmianę. Człowiek powinien podejmować decyzje, które wymagają kontekstu. Nie powinien codziennie pamiętać o wyłączaniu tej samej grupy maszyn.

Polska platforma e-commerce Alerabat.com to wdrożenie, które warto znać, żeby zrozumieć, że nie trzeba być globalnym gigantem. Firma wyeliminowała overprovisioning, wdrożyła Amazon ECS z automatycznym skalowaniem oraz kupiła Savings Plans i Reserved Instances dla trzech kluczowych usług: EC2, RDS i ElastiCache.

To już jest częściowa zmiana sposobu uruchamiania aplikacji, bo ECS oznacza wykorzystanie architektury kontenerowej. Nie ma sensu udawać, że konteneryzacja nie była elementem tego wdrożenia. Jednocześnie przykład Alerabat.com nie dowodzi, że każda firma musi przepisać aplikację na kontenery, żeby ograniczyć koszty. W tym przypadku kontenery, automatyczne skalowanie i lepsze decyzje zakupowe były częścią konkretnego modelu działania. W innej organizacji podobny efekt może przynieść uporządkowanie instancji, harmonogramów i klas pamięci bez zmiany sposobu pakowania aplikacji.

Konkretna kwota oszczędności Alerabat.com nie została upubliczniona, ale sam fakt, że platforma e-commerce z polskim rodowodem poszła tą drogą, mówi sporo o tym, gdzie leżą pieniądze do odzyskania w segmencie małych i średnich firm. Nie zawsze w wielkim projekcie migracyjnym. Częściej w miejscach, które przez lata pozostawały „wystarczająco dobre”.

Canva poszła jeszcze inną ścieżką. Zredukowała koszty operacji obliczeniowych w AWS o 46% w niecałe dwa lata. Kluczem była segmentacja użytkowników i dopasowanie modelu infrastruktury do profilu ryzyka. Dla użytkowników bezpłatnych zastosowano instancje Spot, z maksymalnym rabatem sięgającym 90% wobec cen On-Demand. Dla płacących klientów Pro wykorzystywano On-Demand w ramach Savings Plans, czyli rozwiązanie zapewniające większą przewidywalność.

Produkcyjny ruch klientów płacących dostał stabilność, a eksperymentalne i mniej krytyczne ścieżki dla użytkowników bezpłatnych trafiły na tańszą, ale mniej przewidywalną warstwę obliczeniową. To nie jest rocket science. To po prostu rozsądek z podziałem na warstwy. Najdroższa forma niezawodności nie musi być przydzielona do każdego procesu tylko dlatego, że wszystkie procesy mieszkają w tej samej chmurze.

FinOps zaczyna się wtedy, gdy zespół przestaje pytać wyłącznie „czy to działa?” i dodaje drugie pytanie: „ile kosztuje to, że działa właśnie w ten sposób?”.

Zmiana zasad gry: 1 czerwca 2025 i co z tego wynika

AWS od lat pozwalał resellerom i dostawcom usług zarządzanych na dzielenie rabatów z Reserved Instances oraz Savings Plans między kontami różnych klientów końcowych. Ten model umożliwiał mniejszym firmom korzystanie z rabatów hurtowych, których same nie byłyby w stanie uzyskać. Resellerom dawał natomiast źródło marży i sposób na budowanie oferty wokół wspólnego wykorzystania zobowiązań.

Od 1 czerwca 2025 roku ta praktyka została zablokowana. Dla rynku nie jest to drobna zmiana w regulaminie. Zmienia się sposób, w jaki część pośredników może konstruować ofertę rabatową, a wraz z nim sposób, w jaki klient końcowy powinien oceniać cenę usługi zarządzanej.

Dla kogo jest to problem? Dla firm, które kupiły hosting albo usługi zarządzane od pośrednika, licząc, że ten „zorganizuje” im rabat na AWS w ramach wspólnej puli rezerwacji. Jeśli dotychczasowa oferta była oparta głównie na dzieleniu zobowiązań pomiędzy klientów, dostawca musi zmienić model działania. Klient może zostać postawiony przed wyborem: renegocjować warunki, przejść na model bezpośredni albo znaleźć dostawcę, który bierze na siebie własne zobowiązania i odpowiedzialność za ich wykorzystanie.

Dla kogo jest to szansa? Dla firm, które już płacą AWS bezpośrednio i mają uporządkowane dane o zużyciu. Dla nich większe znaczenie zyskuje własna polityka zakupowa, a nie obietnica, że pośrednik „załatwi rabat”. To również szansa dla firm konsultingowych, które rzeczywiście optymalizują środowisko od środka, zamiast opierać wartość oferty wyłącznie na różnicy między ceną katalogową a wspólną pulą zobowiązań.

Zmiana jest sygnałem dla polskiego rynku, gdzie spora część firm korzysta z usług MSP. Warto zapytać dostawcę, jak dokładnie wygląda jego model rabatowania. Nie wystarczy usłyszeć, że klient „ma rabat AWS”. Trzeba wiedzieć, czy rabat wynika z bezpośredniego zobowiązania, z modelu rozliczeń, z indywidualnego planu, czy z mechanizmu, którego dalsze stosowanie może być niemożliwe.

Dobre pytania są tu bardziej przydatne niż marketingowa prezentacja:

• Czy rabat jest przypisany do konkretnego konta i profilu zużycia?
• Kto ponosi koszt niewykorzystanego zobowiązania?
• Co stanie się z ceną, jeśli obciążenie klienta spadnie albo zmieni się architektura?
• Czy klient może przejść na rozliczenie bezpośrednie bez utraty dostępu do danych i kontroli nad środowiskiem?
• Za co dokładnie płaci MSP: za samo pośrednictwo, za obsługę, czy za realną optymalizację?

Odpowiedź w rodzaju „dzielimy z wami nasze rezerwacje” nie musi automatycznie oznaczać złej oferty. Powinna jednak uruchomić dodatkowe pytania. W modelu, w którym rabat jest częścią wspólnej puli, klient musi rozumieć, jak dzielone są korzyści i ryzyko. Bez tego porównuje nie ceny, tylko obietnice.

Lekcje od liderów: Canva, Anzu i Alerabat w jednym zestawieniu

Trzy wdrożenia, trzy różne skale, trzy różne podejścia — i jedna konkluzja. Redukcja kosztów AWS nie polega na jednym genialnym triku. Polega na serii decyzji, które ktoś musi połączyć z realnym rachunkiem.

Canva postawiła na segmentację użytkowników i dopasowanie typu instancji do profilu ryzyka. Użytkownicy bezpłatni mogą w określonych scenariuszach tolerować przerwanie obliczeń, więc Spot jest dla takich zadań rozsądnym wyborem. Płacący klienci oczekują ciągłości, dlatego bardziej przewidywalne zasoby objęto Savings Plans. Firma nie próbowała zastosować jednego modelu do całego ruchu. Rozdzieliła obciążenia według tego, ile kosztuje ich przerwanie.

Anzu poszła w stronę racjonalizacji po migracji. Zostawiła to, co działa, ograniczyła nadmiarowe zasoby i zmniejszyła liczbę serwerów. Najważniejsza lekcja nie brzmi „każdy powinien zmniejszyć liczbę serwerów o 40%”. Brzmi: po migracji nie wolno uznawać, że praca jest zakończona. Przeniesienie infrastruktury do AWS nie gwarantuje, że jej konfiguracja będzie efektywna kosztowo. Chmura może tylko szybciej ujawnić, jak dużo kosztują stare przyzwyczajenia.

Alerabat poszedł w kierunku architektury kontenerowej z automatycznym skalowaniem oraz planami oszczędnościowymi dla trzech kluczowych usług. To przykład bardziej zaangażowanej zmiany technicznej niż zwykłe wyłączenie instancji po godzinach. Kontenery i ECS mogą ułatwić dopasowanie liczby uruchomionych zadań do ruchu, ale nie zastępują kontroli kosztów. Źle skonfigurowany klaster kontenerowy również potrafi generować rachunek, którego nikt nie rozumie.

Wspólny mianownik tych wdrożeń jest prosty: ktoś musiał przestać myśleć o chmurze jak o magicznej skrzynce, która sama się skaluje. Chmura skaluje zasoby, ale nie skaluje odpowiedzialności. Jeśli nikt nie określi, kto podejmuje decyzję, kiedy zwiększyć pojemność, co wyłączyć i jaki poziom dostępności jest naprawdę potrzebny, automatyzacja będzie tylko sprawniej wykonywać kosztowne polecenia.

Przy okazji warto zauważyć coś, czego nie chcą przyznawać firmy konsultingowe sprzedające „nowoczesne architektury”. Nie każde ograniczenie kosztów wymaga przejścia na serverless, ale nie każda z opisanych firm uniknęła zmian architektonicznych. Alerabat.com wykorzystał Amazon ECS, więc konteneryzacja była elementem wdrożenia. Canva zmieniła sposób przypisywania obciążeń do typów instancji. Anzu ograniczyła nadmiarową infrastrukturę po migracji.

To ważne rozróżnienie. Nie trzeba przeprowadzać przebudowy dla samej przebudowy. Nie należy też udawać, że wszystkie oszczędności da się uzyskać jednym kliknięciem w panelu. Czasem wystarczy rightsizing. Czasem potrzebne są kontenery. Czasem trzeba zmienić model zakupowy. Decyzja powinna wynikać z obciążenia i wymagań produktu, a nie z mody na konkretną usługę AWS.

Jak sprawdzić, czy wasza firma też ma taki problem

Nie ma sensu udawać, że istnieje jedna magiczna lista kontrolna, po której odhaczeniu rachunek sam spadnie. Są za to pytania, na które odpowiedź bardzo szybko pokazuje, czy firma panuje nad infrastrukturą.

Ile środowisk deweloperskich działa w tej chwili, w środku nocy albo w weekend? Jeśli odpowiedź brzmi „nie wiem, sprawdzę”, to nie znaczy jeszcze, że firma odzyska 70% kosztów. Oznacza jednak, że istnieje niezmierzony potencjał oszczędności, a jego wielkość zależy od tego, ile zasobów można bezpiecznie wyłączać i jak długo pozostają nieużywane.

Kiedy ostatnio ktoś przejrzał rachunek AWS i porównał go z mapą środowisk? Jeśli odpowiedź brzmi „na początku roku” albo „chyba nigdy”, nie wiadomo, jaka część wydatków wynika z bieżącego produktu, a jaka z pozostałości po dawnych projektach. Zbiorcza kwota na fakturze nie odpowie na to pytanie. Potrzebne są tagi, właściciele zasobów i porównanie kosztów z wykorzystaniem.

Komu w firmie podlega rachunek? Jeśli odpowiedź brzmi „nikomu konkretnie”, problem jest organizacyjny. Żadna automatyzacja go nie naprawi, nawet ta z najnowszej wersji usługi zarządzania tożsamością i dostępem. Technologia może wyłączyć zasób. Nie zdecyduje, czy jego wyłączenie jest bezpieczne dla produktu ani kto powinien zapłacić za pozostawienie go włączonego.

Warto także sprawdzić, czy firma potrafi odróżnić trzy rodzaje wzrostu rachunku:

• wzrost wynikający z biznesu — więcej użytkowników, transakcji, danych albo operacji;
• wzrost wynikający z decyzji technicznej — większe instancje, dodatkowe repliki, wyższa wydajność dysków;
• wzrost wynikający z zaniedbania — zasoby osierocone, zapomniane środowiska i nieużywane kopie.

Każdy z tych przypadków wymaga innej reakcji. Wzrost wynikający z biznesu może być dobrym sygnałem. Wzrost techniczny powinien mieć uzasadnienie. Wzrost wynikający z zaniedbania trzeba po prostu zatrzymać.

Dobrze jest też ustalić rytm przeglądów. Nie chodzi o comiesięczne polowanie na winnych, lecz o stały proces: analiza anomalii, sprawdzenie wykorzystania, weryfikacja harmonogramów, przegląd zobowiązań i decyzja, czy nowe zasoby mają właściciela. Przy większej organizacji ten proces powinien łączyć zespoły techniczne, produktowe i finansowe. Inaczej każdy będzie optymalizował tylko własny fragment, a koszt przeniesie się gdzie indziej.

Optymalizacja kosztów chmury nie jest jednorazowym projektem w Jirze z terminem za trzy sprinty. To nawyk, który zaczyna się od pytania: „co dokładnie tutaj pracuje, dla kogo i za ile?”. Kiedy firma zaczyna regularnie zadawać to pytanie, rachunek może zacząć się zmniejszać. Nie zawsze o połowę, nie zawsze w pierwszym miesiącu i nie zawsze bez zmian w architekturze. Ale zwykle bez fanfar, bez wielkiej rewolucji i bez udawania, że sama chmura rozwiąże problem zarządzania.

Największe oszczędności rzadko leżą w jednym sekretnym ustawieniu. Są rozproszone między niewykorzystanymi instancjami, źle dobranymi dyskami, środowiskami działającymi bez powodu, zakupionymi zbyt wcześnie zobowiązaniami i zespołami, które nie widzą ceny własnych decyzji. Dlatego rachunek AWS spada nie wtedy, gdy ktoś znajdzie magiczny rabat, lecz wtedy, gdy organizacja zaczyna traktować infrastrukturę jak realną pozycję biznesową.

A jeśli ktoś obiecuje redukcję o połowę w trzy miesiące bez dotknięcia ani jednej instancji, poproście o pokaz rachunku z pierwszego miesiąca — jeszcze przed podpisaniem umowy. Nie dlatego, że każda obietnica jest oszustwem. Dlatego, że potencjał oszczędności trzeba odróżnić od gwarantowanego wyniku.

W końcu to wasza chmura i wasze pieniądze. Warto wiedzieć, które z nich pracują dla produktu, a które tylko podtrzymują stare ustawienia.