AI-vezérelt költségelemzés és anomália-detektálás AWS-en

Bevezető

A FinOps (Financial Operations) egy működési keretrendszer és szervezeti szemlélet, amely maximalizálja a technológiai befektetések üzleti értékét, lehetővé teszi az időszerű, adatalapú döntéshozatalt, és pénzügyi elszámoltathatóságot teremt a mérnöki, pénzügyi és üzleti csapatok együttműködésén keresztül. Nem egyszerűen a költségek megvágásáról vagy a fejlesztők felelősségre vonásáról szól, hanem kulturális változás, ami analitikus pénzügyi gyakorlatot visz a felhőalapú számítástechnika világába egy folyamatosan ismétlődő gyakorlatként.

Három fő pillére van:

1. Inform - Mielőtt bármilyen költségkeretet optimalizálni tudnál, pontosan látnod kell, hova megy a pénz. Ez a fázis a felhőkörnyezet részletes átláthatóságáról szól.

2. Optimize - Miután megvannak az adatok, megkezdődik a pazarlás felszámolása.

3. Operate - A FinOps nem egy egyszeri audit, hanem egy mindennapi gyakorlat, tehát az előző lépések ismétlése.

A FinOps-hoz használt AI hasonló utat járhat be, mint más eszközök: kezdetben előnyt jelent a csapatok számára, később általános gyakorlattá válik.

Fogalmak:

A FinOps for AI a mesterséges intelligencia költségvonzataira összpontosít, mint a költségek átlátható nyomon követése, előfizetések vagy token economy. Ide tartozik még a megfelelő üzleti egységekhez rendelés és az AI beruházások értékelése is, ami röviden annyit tesz hogy az integrálást és a használatba vétel költségeit megbecsüljük és előre jelezzük, még mielőtt megérkezne a számla.

Az AI for FinOps esetén arról van szó hogy FinOps feladatokat AI segítségével látunk el. A FinOps Foundation kutatásai alapján a területen dolgozó csapatok egyre nagyobb mértékben használnak mesterséges intelligenciát a mindennapokban. Az alábbiakban példákat gyűjtöttem a FinOps Foundation összefoglalójából a témában.

A továbbiakban az AI for FinOps témakörre fogok koncentrálni, mivel a FinOps for AI egy önálló nagy terjedelmű témakör.

AI for FinOps példák:

Az mesterséges intelligencia használatát két ágazatra tudjuk bontani: az egyik a reaktív ágazat -ide tartozik a generative AI, a másik a proaktív ágazat -ide pedig az agentic AI. A kettő közül a modernebbnek a proaktív működést szoktuk jelölni, mivel a reaktív munkafolyamat egy összefoglaló generálása vagy egy szimpla válaszadás után véget ér. Az újvonalas használat a FinOps-ban sincs másként ezért igyekeztem minél több proaktív példát gyűjteni. Ezen az elven csoportosítottam őket:

AI for FinOps példák

Generative:

1. Summarize Findings - Összefoglaló készítése: Nyers adatokat kérünk le API-ból, táblázatból. Az adatokat egy LLM megkapja és ezekből összefoglalót vagy jelentést készít.

Agentic:

2. Natural Language Dashboards and Financial Reconciliation - Természetes Nyelvű Irányítópultok és Pénzügyi Egyeztetés: Agentic rendszerek használata, amik automatikusan feldolgozzák a pénzügyi adatokat, összehasonlítják a tényleges kiadásokat a költségvetéssel és jelentéseket készítenek.

3. Autonomous Waste Discovery - Autonóm Pazarlás-felderítés: Az Agentic rendszerek nem csupán jelzik a kihasználatlan erőforrásokat, hanem automatikusan megvizsgálják, azonosítják a felelős tulajdonost, és akár Jira-ticketet is létrehoznak.

4. Proactive Guardrails in the CI/CD Pipeline - Proaktív Korlátok a CI/CD Folyamatban: Az AI elemzők közvetlenül a pull request folyamatba integrálva, az infrastruktúra üzembe helyezése előtt ellenőrzik a konfigurációt a FinOps irányelvek alapján, így a költségek a használatbavétel előtt láthatóvá válnak.

5. Personalized Outreach and Gamification - Személyre Szabott Kommunikáció: Személyre szabott Slack-üzenetek küldése, amelyek azonosítják az adott szolgáltatással utoljára kapcsolatba lépő személyt, és írnak neki a chat felületen.

A cikk folytatásában ezekből a példákból fogom megvalósítani a számomra legizgalmasabbakat az OpenOps segítségével.

Mi az az OpenOps?

Az OpenOps egy kódolás nélküli automatizálási platform. Szerkeszthető workflowkat biztosít a különféle FinOps-folyamatok automatizálásához, mint például a költségoptimalizálás, a költségvetés-tervezés, az előrejelzés, az allokáció és a címkézés (taggelés). Fontos tulajdonsága hogy nyílt forráskódú és kitelepíthető akár egy EC2-re is. Kezelését tekintve egyszerű és nem technikai munkatársak is tudják használni.

Integrálható felhőszolgáltatókkal, harmadik féltől származó FinOps eszközökkel és számos egyébbel, például ticket szolgáltatásokkal (mint a Jira), monitoring rendszerekkel és adatbázisokkal.

Megvalósítás:

Az OpenOps futtatható lokálisan, vagy ahogy a fentiekben írtam: AWS EC2 Instancen is. Utóbbi azonban viszonylag költséges megoldás, mivel a Docker image-ek több mint 10 GB tárhelyet igényelnek, és az ajánlott EC2 instance típus legalább t3.medium, de inkább t3.large. Ezt is kipróbáltam de mivel téma szempontjából ez mellékesnek bizonyult, a teszteléshez kényelmi okokból a lokális futtatás mellett döntöttem.

A FinOps egyik fontos célkitűzése, hogy a különböző területekről érkező együttműködők egy közös lencsén keresztül lássák a pénzügyi működést és így könnyebben tudjanak kommunikálni és cselekedni, ezért nekem is fontos volt hogy ebben a cikkben egy olyan eszközt válasszak amihez nem kell technikai tudás. Ha ezt a feltételt nem vettem volna figyelembe, az AWS State Machine és Lambda párosítás lett volna a nyerő, hiszen ugyanezt a működést olcsóbban és profibban tudta volna produkálni.

Az OpenOps-nak hozzá kell férnie a többi szolgáltatáshoz ezért a következőkre van szüksége: egy aws access-re ami lehet user vagy role, API kulcsra egy tetszőleges AI providerhez és egy hozzáférésre a kommunikációs csatornához. A demo-hoz én az Antrhopic API-t használtam Jira és Slack integrációval, a cloud provider pedig az AWS volt. A fent felsorolt példákból kettőt implementáltam, a Személyre Szabott Kommunikációt és az Autonóm Pazarlás-felderítést. Mindenképp szerettem volna valamilyen formában chatet és ticket rendszert használni mivel CI/CD integrációt más szolgáltatások (mint például az Infracost) többnyire lefedik. Lássuk a példákat:

Személyre szabott kommunikáció:

Ebben a példában az egyik fent említett módszert, a személyreszabott kommunikációt mutatom meg. Ebben a példában a célom, hogy megnézzem a virtuális gépek kihasználtságát és ha találok valamit amit meg kell változtatni, értesítem a megfelelő személyt vagy csoportot közvetlenül chaten. Jelen esetbe ez Slack, de minimális testreszabással Discrodot vagy más chat appot is használhatunk. A FinOps Foundation összefoglalója szerint ezzel 50%-kal növelhetjük a reakciók mértékét.

A megvalósításban egy ismétlődő minta fedezhető fel: A CLI vagy az API segítségével nyers adatot kérünk le amit egy modell megkap. A promptban strukturált válaszadásra kérem amiben egy rövid összefoglalót kérek és egy döntést, hogy az előre megadott lehetőségek közül melyik irányba folytatódjon a művelet.

Lépésekre bontva ez valahogy így működik:

1. Felveszek két változót, a futási idő dátumát és az egy héttel korábbi dátumot. Ez a CLI parancsokhoz kell és csak az időintervallumot adjuk meg vele.

2. Kilistázom a gépeket, majd ezeken a listán egyesével végigmegyek.

3. Minden ismétlés alkalmával lekérem a metrikákat az adott gépre, majd egy Athropic hívás segítségével eldöntöm hogy valóban szükségünk van-e a gépre vagy egy kisebb is megefelő lehet. Erre a strukturált válaszadási képességet használom, tehát a promptban a modellt arra kérem, hogy JSON formátumban adjon választ. Ez azért előnyös mert az ilyen típusú választ később egyszerű logikával (programozással) ki tudom értékelni.

4. Eldöntendő kérdés elé állítom a modellt: ha a kérdésre igaz a válasz, a workflow tovább kutat a logokban (a naplóban), ahol kiderítem hogy ki volt utoljára kapcsolatban a géppel.

Jira Ticket Workflow

1. Miután a logokból kiderült az utolsó kapcsolat vagy változtatás módja és elkövetője, a megfelelő slack csatornára küld a rendszer üzenetet. Ha ennél pontosabbak szeretnénk lenni, megoldható konkrét személyt megszólító üzenet is, a következő példában például Jira ticketet fogunk valakihez rendelni.

A Claude Sonnet üzenete a nem megfelelően kihasznált VM-ről Slacken

Autonóm pazarlás felderítés:

Az előzőhöz hasonlóan itt is adatokat kérünk le, de összetettebb módon fogjuk kezelni őket. Több szolgáltatáson keresztül elemezzük az infrastruktúránkat majd ezekről egy modell összefoglalókat készít. Az összefoglalók naplóbejegyzésekként egy külső táblázatba kerülnek, és ennek segítségével minden futás alkalmával össze tudjuk hasonlítani a múltban felvett bejegyzéseket és az aktuális állapotot. Ezzel a módszerrel a modell képes észlelni trendeket, így ha valami szokatlant vagy rendellenességet érzékel, automatikusan készít egy Jira ticketet a megfelelő szakembernek.

Lépésekre bontva ez így működik:

1. A táblázat aktuális sorához elkérem a dátumot.

2. Két szolgáltatással szeretném górcső alá venni az infrastruktúrámat, a Compute Optimizerrel és a Cost Explorerrel. Ahhoz hogy érthetőbb és kezelhetőbb legyen a folyamat, egy loopot és egy branchet használtam, mivel az OpenOps-ban nem lehet olyan szépen párhuzamosítani mint az AWS State Machineben. A Compute Optimizer eleve mesterséges intelligenciát használ és kifejezetten számítással kapcsolatos szolgáltatásokat figyel, a Cost Explorer pedig nyers adatokat szolgáltat a széleskörű felhő használatodról.

3. Mindkét szolgáltatás esetében egy összefoglalót kérek a modelltől, amit a külső táblázatba írok. A sor kulcsa az aktuális dátum, az oszlopok pedig két eszközt jelölik.

4. A külső táblázatot elkérem (vagy az egészet vagy egy bizonyos időpontig visszamenőleg) és a modellnek adom és a ponton el kell döntenie, hogy kérjen-e beavatkozást vagy felülvizsgálatot.

5. Ha szükséges a beavatkozás, a modell készít egy leírást és egy címet a tickethez. A Jira integráció segítségével kilistázom a potenciális munkatársakat és elkészítem a ticketet.

Jira Ticket Workflow

Jira “Ticket”:

FinOps Jira Ticket

Ezekben a példákban csak jelzést ad a modell, önállóan nem pusztít el és nem skáláz le semmit. Lehetséges az automatizmusokba approve/disapprove linket tenni amivel kattintással jóvá tudsz hagyni egy destruktív műveletet, de talán jobb megoldás kilépni az automatizációból és manuálisan folytatni. Erre a feladatra tökéletes az AWS Cost Optimization bővítmény a Kiro-hoz.

Kiro Powers:

A Kiro for Cost Optimization az eddigiekhez képest kakukktojás mert nem automatizmus ,hanem egy beépített bővítmény a Kiro-hoz, ami lehetővé teszi, hogy közvetlenül a fejlesztői környezetből kérdezd le és elemezd a költségeket. A következő feladatokra alkalmas:

AWS Cost Optimization

1. Költségelemzés: megmutatja mennyit költesz, melyik szolgáltatásra, és előrejelzést ad a jövőre.

2. Optimalizálási javaslatok: megtalálja a felesleges vagy túlméretezett erőforrásokat.

3. Árazási intelligencia: összehasonlítja az AWS szolgáltatások árait régiók között, és képes elemezni az IAC projektjeidet deployment előtt.

AWS Cost Optimization Documentation

Az eszköz az első lépésekben is hasznos lehet, mivel képes költségbecslésre infrastruktúra kód alapján, de ha az automatikus vizsgálatok találnak valamit akkor a javításban és optimalizálásban is a segítségedre lehet.

Összegzés:

A FinOps Foundation 2026-os felmérése alapján a fejlettebb szervezetek valós időben figyelik a felhőköltségeket, jelzik a felesleges kiadásokat, és már a fejlesztés közben figyelmeztetnek, ha egy változtatás drágán jönne ki. Az emberi felügyelet nem tűnik el, az AI inkább tanácsadóként működik és nem önálló döntéshozóként. Ha úgy döntünk hogy szeretnénk a FinOps módszereket hasznosítani a szervezetünkben, könnyű dolgunk lesz hiszen rengeteg vizsgálatot automatizálhatunk a fentiekhez hasonlóan. A FinOps közösség a FOCUS képében egy jól definiált keretrendszert is ad, hogy tájékozódjunk és tanuljunk a felelősségteljes és profi költségkezelésről a felhőben.

Források

• Kiro Powers AWS Cost Optimization

• FinOps Helyzetjelentés 2026

• OpenOps Dokumentáció

• AI a Finops-hoz

• FOCUS

Kérdésed van? Írj nekünk és mi segítünk megtalálni a számodra ideális megoldást.