FinOps u praksi: Kako saseći neplanirane troškove na AWS i Azure cloudu za 30%

Najbitnije u tekstu (Key Takeaways):

• FinOps u praksi nije jednokratna akcija štednje novca, već kulturološka i procesna disciplina koja spaja finansijske, inženjerske i poslovne timove radi donošenja bržih, finansijski opravdanih odluka u javnom cloudu.

• Neplanirani troškovi na AWS i Azure platformama najčešće nastaju usled labave kontrole nad resursima, zaboravljenih diskovi i mrežnih adresa, predimenzionisanih virtualnih mašina i nerazumevanja troškova prenosa podataka (Egress fees).

• Primenom metodologije FinOps-a kroz tri sukcesivne faze – Informisanje (Inform), Optimizacija (Optimize) i Upravljanje (Operate) – kompanije u roku od 90 dana bezbedno smanjuju svoje mesečne račune za oblačne servise od 20% do više od 35%.

• Ključ uspeha leži u kombinaciji tehničkih mera (prelazak na ARM procesore, korišćenje Spot instanci i prelazak na novije generacije skladišta) i uvođenju Infracost alata u CI/CD cevovode kako bi inženjeri videli cenu koda pre nego što ga pošalju u produkciju.

Mrak iza oblačnog fakturisanja: Zašto javni cloud postaje rupa bez dna

Prebacivanje infrastrukture u javni cloud pre nekoliko godina obećavalo je potpunu finansijsku fleksibilnost: pretvaranje velikih unapred plaćenih kapitalnih investicija (CapEx) u podesive operativne troškove (OpEx). Međutim, u praksi se za mnoge kompanije to pretopilo u noćnu moru nepredvidivih, astronomskih faktura na kraju svakog meseca.

Sloboda koju oblačni provajderi daju inženjerima da jednim klikom ili skriptom podignu stotine virtualnih mašina, terabajte brzog NVMe skladišta i složene mrežne balansere, u odsustvu finansijskog nadzora postaje primarni izvor odliva kapitala. Programeri su decenijama učeni da optimizuju kod za brzinu i pouzdanost, dok je cena resursa na kojima se ten kod izvršava bila briga nekog drugog odeljenja.

U okruženjima gde AWS i Azure fakturišu stotine pojedinačnih stavki svake sekunde, tradcionalni modeli finansijske kontrole potpuno zakazuju. Finansijski sektor ne razume tehničke skraćenice poput EC2, EBS, NAT Gateway ili Azure Managed Disks, dok inženjeri nemaju uvid u to kako njihove svakodnevne tehničke odluke utiču na bilans uspeha kompanije.

Tu nastaje opasni rascep. Inženjeri nastavljaju sa „click-ops“ praksom i predimenzionisanjem resursa za svaki slučaj, dok finansije na kraju meseca samo nemo potpisuju fakture koje neprestano rastu. FinOps u praksi predstavlja prekid ove štetne prakse i uvođenje finansijske odgovornosti direktno u inženjerske timove.

Šta je zapravo FinOps u praksi i kako izgleda njegov životni ciklus

Pojam FinOps potiče od kombinacije reči „Financial“ i „Operations“. Prema definiciji vodeće nezavisne organizacije FinOps Foundation, FinOps predstavlja operativnu kulturu i finansijsku disciplinu upravljanja oblačnim servisima koja omogućava organizacijama da dobiju maksimalnu poslovnu vrednost kroz spajanje inženjerskih, finansijskih i poslovnih timova.

Zabluda je smatrati da je jedini cilj FinOps-a puko skresavanje troškova po svaku cenu. FinOps ne služi tome da se ugase resursi koji su potrebni za poslovanje, već da se eliminise nepotrebno rasipanje (cloud waste) kako bi se novac preusmerio u projekte koji generišu prihode i inovacije.

Životni ciklus primene FinOps metodologije odvija se kroz tri trajna, iterativna koraka:

1. Informisanje (Inform): Prva faza uvek počinje vidljivošću. Kompanija mora tačno znati ko, gde i zašto troši novac u cloudu. Bez preciznog alociranja troškova kroz oznake (tags/labels) i mapiranja troškova na konkretne poslovne jedinice ili klijente (Unit Economics), nemoguće je sprovesti bilo kakvu optimizaciju.

2. Optimizacija (Optimize): Nakon što se uspostavi vidljivost, prelazi se na identifikaciju i primenu mera uštede. Ovo uključuje ukidanje neiskorišćenih resursa, smanjenje dimenzija predimenzionisanih mašina (Right-sizing), ugovaranje dugoročnih popusta (Reserved Instances, Savings Plans) i prelazak na ekonomičnije hardverske arhitekture.

3. Upravljanje (Operate): Treća faza pretvara stvorene mere u stalni operativni proces. Postavljaju se automatski budžeti, alarmi za odstupanja u potrošnji, a FinOps metrike postaju deo ključnih pokazatelja uspešnosti (KPI) inženjerskih timova.

Glavni izvori curenja novca na AWS i Azure platformama

Da biste sasekli troškove za 30%, morate najpre znati gde novac zapravo curi. Iskustva iz stotina obavljenih infrastrukturalnih audita pokazuju da se preko 80% nepotrebnih troškova sklapa iz samo četiri kritične kategorije.

1. „Zombi“ resursi i zaboravljene komponente

Zombi resursi su komponente koje kompanija uredno plaća iz sata u sat, a koje više ne obavljaju nikakvu korisnu funkciju u sistemu.

Najčešći primeri zombi resursa obuhvataju:

• Nevezani diskovi (Unattached EBS volumes / Azure Managed Disks): Kada obrišete ili ugasite virtualnu mašinu (EC2 ili Azure VM), povezani disk za skladištenje podataka po podrazumevanim postavkama često ostaje sačuvan u sistemu. Ovi diskovi nastavljaju da generišu punu cenu skladištenja iz meseca u mesec.

• Siročići mrežne infrastrukture (Unassociated Elastic IPs / Orphaned Load Balancers): Statikčke IP adrese koje nisu dodeljene nijednoj aktivnoj mašini oblačni provajderi posebnom taksom naplaćuju kako bi stimulisali njihovo vraćanje u bazen.

• Zastareli rezervni snimci (Orphaned Snapshots & Backups): Automatski rezervni snimci diskova koji se kreiraju svakog dana, a za koje nisu definisane politike automatskog brisanja nakon 30 ili 90 dana.

2. Predimenzionisani računarski resursi (Over-provisioning)

Inženjeri iz straha od zastoja u radu (downtime) po pravilu biraju znatno jače virtualne mašine nego što je to aplikaciji stvarno potrebno. Nije retkost videti AWS EC2 instancu sa 16 vCPU-a i 64 GB RAM-a čije prosečno opterećenje procesora tokom meseca ne prelazi 5%.

Trčanje mašina na 5% do 10% kapaciteta predstavlja finansijski katastrofalnu odluku. Ako mašina konstantno radi na minimalnom opterećenju, vi plaćate pun kapacitet hardvera koji leži potpuno neiskorišćen.

3. Skrivene mrežne takse i troškovi izlaza podataka (Data Egress)

Mreža je kategorija na kojoj se fakture najlakše otrgnu kontroli jer su cene izražene u pfeninzima po gigabajtu, ali na milionima transakcija prave ogromne cifre.

Glavni mrežni finansijski zamci:

• Saobraćaj između zona dostupnosti (Cross-AZ Traffic): Prenošenje podataka iz jedne zone dostupnosti u drugu unutar istog AWS ili Azure regiona nije besplatno. Ako vaši Kubernetes čvorovi komuniciraju sa bazom podataka u drugoj zoni bez optimizovanog mrežnog usmeravanja, plaćate dvostruke mrežne takse za svaki preneti gigabajt.

• NAT Gateway usko grlo: AWS NAT Gateway naplaćuje i satnicu postojanja i fiksnu cenu po svakom gigabajtu obrađenog saobraćaja koji iz privatne mreže ide ka internetu (na primer, preuzimanje paketa, slanje telemetrije).

• Troškovi izlaza na internet (Egress fees): Slanje podataka van oblačnog provajdera prema klijentima ili drugim servisima je izuzetno skupo u poređenju sa unosom podataka koji je besplatan.

4. Razvojna i testna okruženja koja rade 24/7

Development, Staging i QA okruženja služe inženjerima za rad tokom radnog vremena (obično od 8 do 17 časova, pet dana u nedelji). To čini ukupno oko 40 do 50 sati rada nedeljno.

Međutim, u većini kompanija ova okruženja ostaju aktivna i tokom noći, vikenda i praznika – ukupno 168 sati nedeljno. To znači da plaćate punu cenu za više od 120 sati sedmično tokom kojih niko od inženjera uopšte ne gleda niti koristi te servere.

Pet konkretnih tehničkih koraka za smanjenje računa za 30% u prvih 90 dana

Da biste ostvarili merljive rezultate u kratkom roku, nije potrebno menjati kompletnu arhitekturu aplikacija. Primenom sledećih pet inženjerskih koraka možete osloboditi značajna sredstva već u prvom tromesečju.

Korak 1: Detekcija i skriptovana eliminacija zombi resursa

Prvi zadatak FinOps tima jeste čišćenje „smeća“ iz AWS i Azure naloga. Za ovo možete iskoristiti besplatne ugrađene alate poput AWS Trusted Advisor-a ili Azure Advisor-a, ali je znatno efikasnije napisati skripte koje automatski detektuju neaktivne komponente.

Primer CLI komande za pronalazak svih EBS diskova u AWS-u koji se nalaze u stanju available (što znači da nisu povezani ni na jednu instancu):

aws ec2 describe-volumes \
    --filters Name=status,Values=available \
    --query "Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime,Zone:AvailabilityZone}" \
    --output table

Nakon pronalaska ovih diskova, uspostavite proceduru: kreirajte konačan rezervni snimak (snapshot), a zatim obrišite neiskorišćene diskove. Samom ovom akcijom mnoge kompanije trenutačno smanjuju račune za skladištenje za 10% do 15%.

Korak 2: Pravilno dimenzionisanje (Right-sizing) i prelazak na ARM čipove

Analizirajte metrike potrošnje procesora i radne memorije u periodu od bar 30 dana kroz alate AWS Compute Optimizer ili Azure Metrics.

Ako instanca ima prosečno opterećenje CPU-a ispod 15% i ne beleži iznenadne skokove (spikes), bezbedno je smanjiti njenu veličinu za bar jedan nivo (na primer, sa t3.xlarge na t3.large). Ovim jednostavnim korakom cena date mašine prepolovljuje se u sekundi.

Pored smanjenja veličine, ključni potez moderne optimizacije jeste migracija na ARM arhitekturu:

• Na AWS-u, zamenite standardne x86 (Intel/AMD) instance mašinama baziranim na AWS Graviton3 ili Graviton4 čipovima (npr. prelazak sa m6i na m6g ili m7g).

• Na Azure-u, pređite na Ampere Altra ARM virtualne mašine (npr. Dpsv5 serija).

ARM procesori pružaju do 40% bolji odnos cene i performansi u poređenju sa x86 arhitekturom za većinu modernih backend aplikacija napisanih u Go-u, Rust-u, Node.js-u, Python-u ili Java-i.

Korak 3: Optimizacija skladišnih slojeva (Storage Tiering)

Tipična greška inženjera jeste ostavljanje svih podataka na najskupljem primarnom skladištu.

Primenite sledeća tri pravila za skladišta:

1. Migracija sa gp2 na gp3 EBS diskove na AWS-u: Stariji gp2 diskovi vezuju performanse (IOPS) za samu veličinu diska. Noviji gp3 diskovi omogućavaju nezavisno podešavanje kapaciteta i brzine, pri čemu su u startu 20% jeftiniji po gigabajtu od gp2 diskova.

2. S3 Lifecycle pravila na AWS-u: Definišite pravila koja automatski premeštaju objekte u jeftinije slojeve skladištenja u zavisnosti od starosti dokumenta:

   • Od 0 do 30 dana: S3 Standard

   • Od 30 do 90 dana: S3 Standard-Infrequent Access (S3 Standard-IA)

   • Preko 90 dana: S3 Glacier Flexible Retrieval ili Glacier Deep Archive (gde su troškovi skladištenja do 90% niži u poređenju sa S3 Standardom).

3. Azure Blob Storage Access Tiers: Na Azure-u primenite identičnu logiku premeštanjem kontejnera iz Hot u Cool ili Archive slojeve.

Korak 4: Strategija ugovaranja popusta (Savings Plans i Reserved Instances)

Jednom kada ste eliminisali zombi resurse i izvršili smanjenje mašina na pravu veličinu (Right-sizing), dobili ste stabilno osnovno opterećenje (baseline workload). Ovo opterećenje nikada ne bi trebalo plaćati po standardnim, najskupljim cenama po utrošku (On-Demand).

Provajderi nude masivne popuste u zamenu za ugovornu obavezu korišćenja resursa u trajanju od jedne ili tri godine:

• AWS Savings Plans & Reserved Instances (RI): Nude popuste do 72% u poređenju sa On-Demand cenama. Compute Savings Plans pruža najveću fleksibilnost jer se popust automatski primenjuje na bilo koju porodicu mašina, region ili operativni sistem.

• Azure Reservations & Savings Plans: Pružaju identične uštede za Azure VM, SQL baze i druge servise.

zlatno pravilo FinOps-a glasi: Nikada nemojte kupovati rezervacije pre nego što očistite i optimizujete infrastrukturu. Ako kupite trogodišnju rezervaciju za predimenzionisanu mašinu, samo ste zaključali nepotreban trošak na tri godine.

Korak 5: Primena Spot instanci i automatizacija neprodukcionih okruženja

Za opterećenja koja su otporna na prekide (Stateless aplikacije, pozadinski obradni radnici, Kubernetes podovi koji se mogu lako ponovo podići), upotrebite AWS Spot Instances ili Azure Spot VMs.

Spot instance predstavljaju neiskorišćeni kapacitet oblačnih data centara koji se prodaje uz popuste od 70% do 90%. Jedina kvaka jeste u tome što provajder može povući tu instancu uz obaveštenje od 2 minuta ako mu zatreba za On-Demand klijente. Upotrebom alata kao što su Karpenter ili Spot Ocean, vaš Kubernetes klaster može bezbedno koristiti ove jeftine resurse bez ikakvog rizika po dostupnost servisa.

Za neprodukciona okruženja (Dev/Stage), uvedite automatske skripte za raspored rada (Scheduling). Koristeći alate poput Instance Scheduler na AWS-u ili Azure Auto-shutdown, podesite da se svi razvojni serveri automatski ugase radnim danima u 19h i ponovo podignu sutradan u 07h, kao i da ostanu potpuno ugašeni tokom vikenda. Ovo trenutačno smanjuje račune za te mašine za preko 60%.

Kultura označavanja (Tagging/Labeling) i Infracost u CI/CD cevovodu

Da bi FinOps u praksi dao dugoročne rezultate, finansijska svest se mora pomeriti do samog početka razvojnog procesa – procesa pisanja koda.

Politika strogog označavanja resursa (Tagging Policy)

Nemoguće je upravljati troškovima ako ne znate čiji je koji resurs. Uvođenje obaveznih oznaka na svim AWS i Azure resursima predstavlja osnovu FinOps-a.

Svaki resurs u cloudu mora obavezno imati sledeće ključne oznake:

• Environment (npr. Production, Staging, Development)

• Owner (npr. tim-alpha@kompanija.rs)

• CostCenter (npr. CC-402)

• Project (npr. e-commerce-v2)

Primenite automatske politike na nivou organizacije (AWS Service Control Policies – SCP ili Azure Policy) koje fizički blokiraju kreiranje bilo kog novog resursa koji nema definisane ove obavezne oznake.

Pomak ulevo: Infracost u CI/CD cevovodu (Shift Left Cost Control)

Najbolji način da inženjeri postanu svesni troškova jeste da im se cena prikaže pre nego što kod ode na produkciju.

Alat Infracost direktno se integriše u vaše razvojne alate (GitHub Actions, GitLab CI, Azure DevOps) i analizira izmene u Terraform / OpenTofu kodu tokom izrade Pull Request-a.

Primer Infracost komentara koji se automatski pojavljuje na Pull Request-u inženjera:

💰 Infracost estimate: monthly cost will increase by $142 (from $1,200 to $1,342)

Project: infrastructure/aws
┌───────────────────────────┬──────────────────────┬──────────────────┐
│ Resource                  │ Change               │ Monthly Cost     │
├───────────────────────────┼──────────────────────┼──────────────────┤
│ aws_instance.web_server   │ Size: t3.medium ->   │ +$84.20          │
│                           │ t3.xlarge            │                  │
│ aws_ebs_volume.db_storage │ Size: 100GB -> 500GB │ +$57.80          │
└───────────────────────────┴──────────────────────┴──────────────────┘

Kada developer na ekranu vidi da njegova izmena u kodu povećava mesečni račun za $142, on će se prirodno zapitati da li je promena veličine mašine zaista bila neophodna ili se problem mogao rešiti boljom optimizacijom.

Ova praksa se u potpunosti uklapa u koncepciju inženjerske odgovornosti, o čemu smo detaljno pisali u tekstu o tome kako se softverski arhitekta razlikuje od mlađeg developera, gde razumevanje ekonomije softvera čini jednu od osnovnih odlika pravog senioriteta.

Pregled uobičajenih mera optimizacije i ušteda u praksi

Da bismo vam pružili jasan pregled potencijala ušteda, kreirali smo uporednu tabelu mera sa procenjenim uticajem na budžet i nivoom složenosti implementacije:

Povezanost FinOps-a sa širim infrastrukturnim odlukama

FinOps ne deluje u vakuumu. Odluke koje donosite u okviru optimizacije oblačnih troškova direktno utiču na celokupnu arhitekturu vaših softverskih sistema.

Ponekad, najradikalnija i najisplativija FinOps mera nije nastavak optimizacije u cloudu, već promena same paradigme.

Ako analize pokažu da je vaša aplikacija dostigla stabilan i masivan saobraćaj gde troškovi oblačnih provajdera ostaju previsoki uprkos svim primenjenim rezervacijama i automatizacijama, pravo je vreme za razmatranje hibridnih modela ili delimičnog izlaska iz clouda. O ovome smo detaljno pisali u analizi o razlikama između Kubernetes-a i Serverless arhitekture, gde izbor prave platforme u startu eliminiše nepotrebne troškove.

Takođe, izbor programskog jezika ima direktan uticaj na vaše oblačne račune. Aplikacija napisana u jeziku sa malim memorijskim otiskom troši znatno manje procesorskih resursa i radne memorije. O tome kako se moderni jezici ponašaju u produkciji saznajte više u našoj analizi Rust vs Go u modernim backend sistemima.

Pored tehničke strane, ne smemo zaboraviti ni pravni aspekt poslovanja. Sva ušteda koju ostvarite na infrastrukturi gubi smisao ako se izložite pravnim rizikom. Zbog toga se uvek uverite da su vaši ugovori sa spoljnim saradnicima i provajderima pravno bezbedni, o čemu možete pročitati u vodiču o zaštiti intelektualne svojine i izvornog kôda, kao i u našem pravnom i poreskom vodiču za rada sa inostranstvom.

Budućnost FinOps-a: AI-driven FinOps i optimizacija AI resursa

Kada posmatramo pravce u kojima se javni cloud razvija, uočavamo dva dominantna trenda koji transformišu FinOps u praksi:

1. Eksplozija troškova veštačke inteligencije (AI/ML Workloads)

Sve veći broj kompanija integrise lokalne velike jezičke modele (LLM) ili obučava sopstvene AI modele na AWS (Sagemaker) ili Azure (Azure OpenAI) platformama. Zakup skupih GPU кластера (poput Nvidia H100 ili A100 instanci) stvorio je novu kategoriju finansijskog krvarenja. FinOps za AI (često nazvan AIOps/FinOps for AI) postaje specijalizovana grana koja se bavi optimizacijom upotrebe GPU memorije, kvantizacijom modela i dinamičkim alociranjem AI resursa.

2. Autonomni AI FinOps agenti

Tradicionalni alati za FinOps pružaju izveštaje i preporuke, ali i dalje zahtevaju da čovek ode u konzolu i ručno odobri ili izvrši promenu.

Nova generacija alata koristi autonomne AI agente koji u realnom vremenu prate opterećenje sistema, automatski preraspoređuju saobraćaj, kupuju i prodaju rezerve na berzi kapaciteta i dinamički prilagođavaju veličinu klastera bez ikakve ljudske intervencije. Sistem samostalno uočava da je saobraćaj opao, smanjuje instancu, premešta neaktivne podatke na S3 Glacier i šalje sažeti izveštaj o uštedi FinOps timu na Slack.

Kako se tržište rada menja i koje veštine postaju najtraženije u eri ove automatizacije, detaljno smo analizirali u tekstu o tržištu IT poslova u Srbiji i profilima koji pruže najveću stabilnost.

Kako započeti FinOps transformaciju već danas

Sasecanje neplaniranih troškova na AWS i Azure cloudu za 30% nije nemoguća misija, niti zahteva magiju. Ono zahteva prelazak sa stihijskog upravljanja infrastrukturom na sistemski, inženjerski i finansijski utemeljen proces.

Da biste pokrenuli FinOps transformaciju u svojoj organizaciji već od sutra, primenite sledeći akcioni plan od četiri koraka:

1. Uspostavite potpunu vidljivost: Definisiite obaveznu politiku označavanja (tagging) i postavite ugrađene besplatne budžetske alarme u AWS Cost Explorer-u ili Azure Cost Management-u koji će vas odmah obavestiti ako dnevna potrošnja prekorači planirani prag.

2. Očistite zombi resurse: Pokrenite skripte za detekciju nevezanih EBS diskova, neiskorišćenih Elastic IP adresa i starih rezervnih snimaka. Obrišite sve što ne vrši korisnu funkciju.

3. Uvedite vremenske rasporede za rad (Scheduling): Automatski gosite sva neprodukciona okruženja tokom noći i vikenda.

4. Pomerite FinOps ulevo: Integrišite alate poput Infracost-a u vaš CI/CD cevovod kako bi inženjeri dobili uvid u cene koda pre nego što on postane deo produkcije.

FinOps ne sputava inovaciju – on je omogućava. Kada eliminišete rasipanje novca na zaboravljene i predimenzionisane resurse, oslobađate značajan kapital koji vaš inženjerski tim može uložiti u razvoj novih mogućnosti proizvoda, eksperimentisanje i jačanje tržišne pozicije vaše kompanije.

Često postavljana pitanja (FAQ)

1. Šta je glavna razlika između klasične kontrole troškova i FinOps-a?

Klasična kontrola troškova je pasivan, finansijski proces u kome računovodstvo na kraju meseca pregleda račune i traži od inženjera da smanje potrošnju. FinOps je aktivan, kulturološki i inženjerski proces u kome finansije, DevOps i poslovni timovi kontinuirano sarađuju u realnom vremenu, gde su inženjeri svesni cena resursa tokom samog pisanja koda i donošenja arhitektonskih odluka.

2. Da li primena FinOps-a može da uspori razvoj i izbacivanje novih opcija proizvoda?

Ne. Pravilno primenjen FinOps ubrzava razvoj jer uklanja birokratske prepreke. Kada inženjerski timovi imaju jasne budžetske okvire, definisane politike i uvid u cene kroz alate poput Infracost-a, oni mogu samostalno da donose brze tehničke odluke i lansiraju nove opcije bez čekanja na odobrenja finansijskog direktora za svaki novi resurs.

3. Koliko vremena je potrebno da se uoče prvi finansijski rezultati primene FinOps-a?

Prvi rezultati vidljivi su već na narednom mesečnom računu. Akcije poput eliminisanja nevezanih diskova (EBS/Managed Disks), ukidanja neiskorišćenih IP adresa i postavljanja skripti za noćno gašenje testnih okruženja donose trenutačne uštede u roku od 24 do 48 sati od trenutka primene.

4. Šta je to „Unit Economics“ u kontekstu FinOps-a i zašto je važno?

Unit Economics (jedinična ekonomija) jeste merenje oblačnih troškova u odnosu na konkretnu poslovnu metriku (na primer: trošak clouda po jednom aktivnom korisniku, trošak po obrađenoj narudžbini ili trošak po gigabajtu obrađenog videa). Ovo je izuzetno važno jer ako vaš ukupni račun za cloud raste za 20%, ali je broj obrađenih transakcija u istom periodu porastao za 100%, vaš jedinici trošak je zapravo opao, što znači da vaša infrastruktura postaje efikasnija kako kompanija raste.

5. Koje alate je najbolje koristiti za početak primene FinOps-a?

Za početak je najbolje iskoristiti besplatne ugrađene alate samih provajdera: AWS Cost Explorer, AWS Budgets, AWS Compute Optimizer, odnosno Azure Cost Management + Billing i Azure Advisor. Kako proces sazreva, preporučuje se uvođenje otvorenih alata poput Infracost-a (za proveru cena u CI/CD-u) i Kubecost-a (za precizno alociranje troškova unutar Kubernetes klastera).