AWS bez landing zone i bez kontroli kosztu

Klient prowadził usługi na AWS. Konto rosło razem z produktami, środowiskami i eksperymentami. Landing zone nie było. Typ instancji wybierała konsola, często w rozmiarze na zapas. Koszt był widoczny, gdy przychodziła faktura. Wtedy było już po miesiącu idle, oversize i usług, których nikt nie wyłączył.

Z czym przyszedł klient

Brakowało podziału kont i guardrails. Instancje stawiano z konsoli. Tagi nie były wymagane, więc usługa nie miała właściciela. Cost Explorer, jeśli włączony, nie miał rytmu. Rano nikt nie dostawał raportu. Nikt nie dostawał alertu, gdy dzienny koszt przekroczył próg.

Co zostawało w rachunku

Preview, logi bez retencji, dyski po migracji i martwy load balancer zostawały do końca okresu. Typ instancji nie był decyzją z pomiaru. Był kliknięciem. Na koniec miesiąca zespół budził się z kwotą, której nie dało się już cofnąć, tylko wyjaśnić.

To nie była zła wola. To był brak ramy: kto może stawiać zasób, w którym koncie, z jakim typem i z jakim tagiem.

Dlaczego rachunek spada na koniec miesiąca

AWS rozlicza zużycie ciągle. Widoczność raz w miesiącu nie jest kontrolą. Bez landing zone nie ma ram. Bez alertu skok widać po fakcie. Bez codziennego raportu nikt nie wiąże wczorajszego deployu z dzisiejszym kosztem.

Oversize bez listy

Typ instancji bez listy w module Terraform wraca do oversize. Idle nie ma właściciela, więc nie ma kto go zamknąć. Faktura na koniec miesiąca jest wtedy pierwszym sygnałem, nie ostatnim sprawdzeniem.

Dla finansów wygląda to jak zaskoczenie. Dla engineeringu jak miesiąc pracy bez lustra. Oba zespoły dostają ten sam plik PDF i nie mają wspólnego języka na tydzień, w którym koszt uciekł.

Jak to ułożyliśmy

Ułożyliśmy landing zone: konta, IAM, SCP, logi i domyślne sieci. Typ instancji wszedł do modułu Terraform, z osobną polityką dla produkcji i dla preview. Tagi są wymagane. Zasób bez właściciela nie przechodzi.

Raport codzienny, alert na próg

Wprowadziliśmy cykliczne, codzienne raporty kosztu per konto, usługa i środowisko. Alert idzie, gdy dzienny albo skumulowany koszt przekroczy ustalony próg, albo gdy pojawi się nowy typ wydatku. Idle, dyski po migracji i martwe load balancery zamykamy w tym samym rytmie co rightsizing.

To nie jest księgowość IT. To rytm inżynierski: tydzień anomalii, miesiąc rightsizingu, kwartał zobowiązań. Raport rano daje szansę zamknąć wyciek w tym samym tygodniu, w którym powstał.

Porządek przed zobowiązaniami

Najpierw alokacja i idle. Potem zmiana typu instancji i klasy storage tam, gdzie pomiar to potwierdza. RI i Savings Plans wchodzą po kilku cyklach, nie w pierwszym tygodniu. Inaczej zobowiązanie utrwala oversize.

Skutek

Po pomiarze i porządkach rachunek spadł o 40 procent w skali miesiąca. W skali roku to setki tysięcy dolarów, które wcześniej schodziły na oversize, brak limitu i brak właściciela. Dalszy rytm zostaje: raport, alert, przegląd kwartalny. Ten sam układ opisujemy w usłudze FinOps.

Podsumowanie

Chmura bez landing zone i bez listy typów instancji nie jest tańsza. Jest nieczytelna. Codzienny raport i alert na próg nie zastępują architektury. Dają czas, żeby architekturę i idle zamknąć zanim przyjdzie faktura.