Jak AI analizuje zasoby w AWS, Azure i Google Cloud i mówi, za co tak naprawdę płacicie?

AI może się podłączyć do AWS, Azure i Google Cloud przez oficjalne API każdego dostawcy, wyciągnąć listę zasobów, aktywne alerty, logi zdarzeń i zestawienie kosztów według projektów, a następnie przetworzyć to wszystko na raport zrozumiały dla osoby, która nie jest inżynierem chmury. Nie trzeba codziennie zaglądać do konsoli. Wystarczy pytanie w stylu "co się dzieje na naszych serwerach" albo "czemu rachunek w tym miesiącu jest wyższy".

Dlaczego konsola chmury to czarna skrzynka dla właściciela firmy?

AWS Console, Azure Portal i Google Cloud Console to potężne narzędzia, ale zaprojektowane z myślą o inżynierach DevOps i architektach. Typowy widok AWS pokazuje kilkaset typów usług, dziesiątki regionów i tabele z nazwami w stylu i3.xlarge albo Standard_D4s_v5. Nikt nie wytłumaczy od razu, że to maszyna wirtualna z czterema rdzeniami, która stoi bezczynnie od trzech tygodni i generuje koszty każdej godziny.

Wiele firm, które wdrożyły chmurę rok albo dwa lata temu, ma w niej zasoby, o których nikt nie pamięta. Dysk z danymi po projekcie, który się skończył. Testowa maszyna, którą ktoś zostawił włączoną. Load balancer, który obsługuje zero ruchu. To są realne pozycje na rachunku, widoczne w zestawieniu, ale ukryte pod techniczną nomenklaturą, którą trudno rozszyfrować bez wiedzy operacyjnej.

AI nie zastąpi architekta chmury przy projektowaniu infrastruktury, ale może pełnić rolę tłumacza i kontrolera finansowego: czytać dane, które tam są, i mówić po ludzku, co oznaczają.

Jakie dane możemy wyciągnąć i skąd konkretnie?

Każdy z trzech głównych dostawców udostępnia dane w kilku warstwach. W praktyce pracujemy z czterema rodzajami informacji:

• Lista zasobów: maszyny wirtualne (EC2 w AWS, Virtual Machines w Azure, Compute Engine w Google Cloud), dyski (EBS, Managed Disks, Persistent Disks), sieci, bazy danych, kolejki, funkcje serverless. Każdy zasób ma identyfikator, region, datę utworzenia i tagi (albo ich brak).
• Alerty i zdarzenia: AWS CloudWatch Alarms, Azure Monitor Alerts, Google Cloud Monitoring Alerts. To powiadomienia, które system wysyła, gdy np. zużycie CPU przekracza próg, dysk się zapełnia albo aplikacja przestaje odpowiadać. Nazwy alertów brzmią technicznie, np. HighCPUUtilization albo DiskReadOps, ale treść jest zrozumiała po przetłumaczeniu.
• Raporty kosztów: AWS Cost Explorer z zakładką Cost & Usage Report, Azure Cost Management z widokiem Cost analysis, Google Cloud Billing Reports z eksportem do BigQuery. Dane można grupować po tagach, projektach, typach usług i regionach.
• Logi aktywności: AWS CloudTrail (kto co robił na koncie), Azure Activity Log, Google Cloud Audit Logs. Przydatne, gdy chcemy wiedzieć, kto uruchomił dany zasób albo kiedy ostatnio ktoś go dotykał.

U jednego z klientów, firmy z branży e-commerce, wyciągnęliśmy listę zasobów z AWS i okazało się, że trzy środowiska testowe z kampanii sprzed roku nadal działają w pełnym wymiarze. Nikt ich nie wyłączył, bo nikt nie miał nawyku zaglądania do konsoli po zakończeniu kampanii. AI wyłapał je po tym, że tagi miały stary projekt, a metryki CloudWatch pokazywały blisko zero aktywności od miesięcy.

Jak fizycznie wygląda podłączenie AI do chmury?

To jest sekcja, którą warto przeczytać uważnie, bo od strony technicznej każdy z trzech dostawców działa trochę inaczej.

AWS udostępnia dane przez AWS SDK (dostępny w Pythonie, Node.js, Go i innych językach) oraz AWS CLI. Do połączenia potrzebny jest klucz dostępu: Access Key ID i Secret Access Key. Najlepiej założyć osobnego użytkownika IAM z polityką ReadOnlyAccess i osobno Billing Viewer do raportów kosztów. Dane o kosztach są w API CostExplorer, lista zasobów przez EC2 DescribeInstances, RDS DescribeDBInstances i analogiczne wywołania dla każdej usługi. CloudWatch dostarcza alerty przez DescribeAlarms.

Azure używa REST API z uwierzytelnieniem przez Azure Active Directory: potrzebny jest Service Principal z rolą Reader na poziomie subskrypcji i osobno Cost Management Reader. Po stronie API koszty pobiera się z Microsoft.CostManagement/query, lista zasobów przez Microsoft.Resources/resources, alerty przez Microsoft.Insights/alertRules. SDK Azure jest dostępny w Pythonie i .NET, ale samo REST API wystarczy do integracji.

Google Cloud korzysta z OAuth 2.0 i kont usługowych (Service Account). Tworzymy konto usługowe w IAM z rolą Viewer i Billing Account Viewer, pobieramy plik JSON z kluczem i używamy go do uwierzytelnienia. Zasoby są dostępne przez Cloud Asset API (cloudasset.googleapis.com), koszty przez Cloud Billing API albo eksport do BigQuery (opcja dostępna w ustawieniach konta rozliczeniowego). Alerty przez Cloud Monitoring API.

Czego producenci nie udostępniają: szczegółów konfiguracji sieciowej wymagających uprawnień do zapisu, historycznych logów starszych niż czas retencji (w AWS CloudTrail domyślnie 90 dni bez osobnego archiwum w S3), oraz części danych diagnostycznych, które wymagają włączenia dodatkowych agentów na maszynach. Ale do analizy kosztów i zasobów te ograniczenia zazwyczaj nie przeszkadzają.

Co AI robi z alertami: z technicznego żargonu na ludzki język

Alert w chmurze wygląda mniej więcej tak: ALARM: "prod-api-HighCPUUtilization" is in ALARM state. Threshold Crossed: 1 out of the last 1 datapoints [92.14 (03/11/26 08:14 GMT)] was greater than the threshold (85.0). Treat Missing Data: missing. Dla osoby nieznającej AWS to zestaw słów bez znaczenia.

AI przetwarza ten alert i mówi: serwer obsługujący aplikację produkcyjną był dziś rano przez kilka minut mocno obciążony, co może oznaczać wzmożony ruch, nieoptymalny kod albo że serwer jest za mały dla bieżącego obciążenia. Jeśli to powtarza się regularnie, warto porozmawiać z zespołem technicznym o zwiększeniu mocy.

To nie jest błahostka. Firmy dostają codziennie kilkanaście takich alertów i nikt ich nie czyta, bo wymagają kontekstu technicznego. Efekt: alerty stają się szumem. AI przywraca im sens, grupuje podobne zdarzenia w jeden komunikat i wskazuje, które wymagają reakcji, a które to normalne wahania.

Podobnie działa to z logami z AWS CloudTrail albo Azure Activity Log: AI potrafi z setek wpisów wyłowić zdarzenia, które wyglądają podejrzanie, np. logowanie z nowego kraju, masowe usuwanie zasobów albo zmiana uprawnień na koncie z uprawnieniami administracyjnymi.

Zasoby bez właściciela: gdzie firma płaci za coś, o czym nie wie

Tagi w chmurze to etykiety, które dołącza się do zasobu w momencie tworzenia: Project: CRM-2024, Owner: jan.kowalski@firma.pl, Environment: production. Bez nich nie da się powiedzieć, do czego służy dana maszyna, kto jest za nią odpowiedzialny ani czy nadal jest potrzebna.

W praktyce wiele firm ma reguły tagowania na papierze, ale w konsoli króluje chaos. Zasoby tworzone szybko, pod presją terminu, lądują bez tagów. Ktoś odchodzi z firmy i jego zasoby zostają bez właściciela. Projekt się kończy, infrastruktura zostaje.

AI przegląda całą listę zasobów i wyciąga:

• zasoby bez żadnych tagów,
• zasoby z tagiem Owner wskazującym na osobę, która już nie pracuje w firmie (na podstawie listy aktywnych kont),
• zasoby w regionach, w których firma normalnie nie operuje,
• dyski (EBS Volumes w AWS, Unattached Disks w Azure) niepodłączone do żadnej maszyny,
• snapshoty (kopie zapasowe dysków) starsze niż zadany próg, np. rok, bez widocznego właściciela projektu.

Raport z takiego przeglądu to gotowa lista do weryfikacji z zespołem technicznym. AI nie wyłącza niczego samodzielnie, bo bez wiedzy o kontekście może wyłączyć coś, co wygląda na nieużywane, a w rzeczywistości obsługuje nocne zadanie raz na kwartał. Ale zestawienie kandydatów do wyłączenia, z datą ostatniej aktywności i szacowaną liczbą godzin od ostatniego użycia, daje konkretny punkt startowy do decyzji.

Miesięczny komentarz do rachunku: co za tym wzrostem stoi

Rachunek za chmurę to kilkadziesiąt wierszy z nazwami usług, regionami i liczbami. Jeśli w tym miesiącu jest wyższy niż w poprzednim, standardowa odpowiedź działu IT brzmi "mieliśmy więcej ruchu" albo "uruchomiliśmy nowe środowisko". To zazwyczaj prawda, ale nie pełna odpowiedź.

AI potrafi porównać dwa okresy rozliczeniowe i napisać komentarz, który identyfikuje konkretne pozycje odpowiedzialne za zmianę. Typowy komentarz wygląda tak: koszt usługi Amazon RDS wzrósł w porównaniu do poprzedniego miesiąca, bo w połowie miesiąca uruchomiono nową instancję bazy danych oznaczoną tagiem Project: Nowy-modul. Jednocześnie koszty transferu danych (Data Transfer Out) spadły, prawdopodobnie przez mniejszy ruch na środowisku stagingowym. Usługa Amazon S3 generuje koszty wyższe niż miesiąc temu z powodu większego wolumenu przechowywanych danych w bucketach z tagiem Backup, co może wymagać przeglądu polityki retencji.

Taki komentarz można dołączyć do wewnętrznego raportu finansowego bez konieczności tłumaczenia go przez eksperta chmurowego. Właściciel firmy albo dyrektor finansowy dostaje odpowiedź na pytanie "dlaczego więcej?" bez angażowania zespołu technicznego w spotkanie tylko po to, żeby wytłumaczyć rachunek.

AI grupuje koszty po tagach projektów, więc jeśli firma ma tagi Client: AcmeCorp albo Project: Portal-B2B, raport pokazuje, ile kosztuje infrastruktura dla każdego klienta z osobna. To szczególnie przydatne, gdy chmura jest współdzielona między kilka projektów i firma chce wiedzieć, który projekt ile konsumuje.

Od czego zacząć, żeby to działało

Podłączenie AI do chmury nie wymaga przebudowy infrastruktury. Potrzebne są trzy rzeczy.

Pierwsza: konto techniczne z uprawnieniami tylko do odczytu. W AWS to użytkownik IAM z polityką ReadOnlyAccess i Billing Viewer, w Azure: Service Principal z rolą Reader i Cost Management Reader, w Google Cloud: Service Account z rolą Viewer i Billing Account Viewer. Żadnych uprawnień do tworzenia, modyfikowania ani usuwania zasobów. To ważne: AI czyta, nie zmienia.

Druga: włączony eksport danych. W AWS aktywujemy Cost & Usage Report do bucketa S3. W Azure eksport z Cost Management do konta magazynowego. W Google Cloud eksport danych rozliczeniowych do BigQuery w ustawieniach Billing Account. Bez tego API kosztowe zwraca dane z opóźnieniem i mniejszym poziomem szczegółowości.

Trzecia: polityka tagowania. Zanim AI zacznie analizować właścicieli zasobów, ktoś w firmie musi ustalić obowiązkowe tagi i zakomunikować to zespołowi technicznemu. Minimum to Project, Owner i Environment. Bez tego AI potrafi tylko wyłapywać brak tagów, co samo w sobie jest już przydatne, ale nie daje pełnego obrazu.

Typowo wygląda to tak, że pierwsze połączenie robi administrator razem z kimś z redAi podczas jednego spotkania. Potem AI działa samodzielnie: raz w tygodniu przegląda zasoby, raz w miesiącu przygotowuje komentarz do rachunku, a alerty tłumaczy na bieżąco, gdy się pojawiają.

Jeśli Wasza firma ma chmurę od dostawcy i zastanawiacie się, czy macie pełny obraz tego, za co płacicie, możemy to sprawdzić razem. 15 minut rozmowy wystarczy, żeby ocenić, co da się wyciągnąć z Waszej konsoli i co z tym zrobi AI. Jeśli chcecie zobaczyć, jak wyglądały podobne wdrożenia u innych firm, zerknijcie na realne wdrożenia.