Nikt nie decyduje się świadomie marnować pieniędzy na infrastrukturę chmurową. Dzieje się to stopniowo: środowisko testowe, które miało być tymczasowe, baza danych zwymiarowana pod skok ruchu przy starcie i nigdy niezmniejszona później, polityka snapshotów, do której nikt nie wrócił. Pojedynczo każdy z tych elementów jest mały. Razem często stanowią 20-30% rachunku za chmurę, nie robiąc nic pożytecznego.

Oto co sprawdzamy najpierw podczas przeglądu utrzymaniowego środowiska AWS lub Azure klienta.

1. Osierocone zasoby dyskowe i snapshoty

Odłączone woluminy EBS, stare obrazy AMI, z których nikt już nie uruchamia maszyn, łańcuchy snapshotów sięgające lat wstecz bez polityki retencji - przestrzeń dyskowa jest tania w przeliczeniu na GB, ale sumuje się szybko, gdy nic nigdy nie jest usuwane. Polityka retencji, która jest faktycznie egzekwowana (a nie tylko udokumentowana), to pojedyncza poprawka o największej dźwigni.

2. Ponowne dobranie rozmiaru zasobów obliczeniowych

Instancje niemal zawsze są dobierane pod szczytowe obciążenie przy starcie i nigdy nie są weryfikowane później. Sprawdź metryki wykorzystania z ostatnich 30-90 dni - jeśli maszyna wirtualna konsekwentnie działa przy 8% obciążenia CPU, to nie jest “margines bezpieczeństwa”, tylko okazja do zmniejszenia zasobów. To także moment, w którym opłaca się rozważyć instancje zarezerwowane lub plany oszczędnościowe - ale dopiero gdy bazowe wymiarowanie jest już poprawne.

3. Środowiska nieprodukcyjne działające 24/7

Środowiska staging i dev, które kopiują czas działania produkcji, to jedno z najczęstszych źródeł unikalnych wydatków. Zaplanowane uruchamianie/zatrzymywanie (lub skalowanie do zera tam, gdzie architektura na to pozwala) poza godzinami pracy potrafi samo w sobie obniżyć koszty obliczeniowe środowisk nieprodukcyjnych o ponad połowę.

4. Transfer danych, którego nie planowałeś

Ruch między regionami i strefami dostępności oraz ruch kierowany przez bramę NAT, która nie musiała być zaangażowana, pojawia się jako rozmyta pozycja na fakturze, łatwa do przeoczenia, dopóki się jej nie poszuka. Decyzje architektoniczne podjęte na wczesnym etapie - jak np. w której strefie dostępności umieszczona jest baza danych względem warstwy aplikacji - często zamieniają się w powracający koszt, którego nikt nie łączy już z pierwotną decyzją projektową.

5. Alerty na koszty, nie tylko na dostępność

Większość zespołów ma solidne alertowanie dostępności i błędów, a zero alertowania kosztów, więc błędna konfiguracja uruchamiająca niespodziewanie drogie zasoby może działać tygodniami, zanim ktokolwiek zauważy ją na fakturze. Alert budżetowy z rozsądnym progiem wychwytuje to w ciągu dni, a nie cykli rozliczeniowych.

Nic z tego nie wymaga przepisania systemu ani migracji - to porządki. Ale to rodzaj porządków, które łatwo odkładać w nieskończoność, jeśli nikt nie przygląda się im regularnie - a dokładnie tę lukę ma wypełniać bieżące utrzymanie infrastruktury chmurowej.