Detekcija anomalija u cloud troškovima…

Ažurirano: 13. lipnja 2026.

Detekcija anomalija u cloud troškovima je proces automatskog otkrivanja neuobičajenih skokova u potrošnji na AWS-u, Azureu i GCP-u prije nego što mjesečni račun eksplodira. Sva tri davatelja danas nude besplatne ML-bazirane servise (AWS Cost Anomaly Detection, Azure Cost Management anomaly alerts, GCP Budget anomaly alerts) koji analiziraju dnevne troškove, uče sezonske obrasce i šalju upozorenja unutar 24 sata od pojave anomalije. U ovom vodiču pokazujem kako sam tijekom 2026. postavio detekciju anomalija u multi-cloud okruženju s manje od 50 lažnih pozitiva mjesečno, koje pragove koristim i kako anomalije rutiram u Slack, PagerDuty i Jiru.

AWS Cost Anomaly Detection koristi Random Cut Forest algoritam, besplatan je i otkriva anomalije unutar 24 sata; konfigurira se po linked accountu, servisu, cost category ili tagu.
Azure Cost Management anomaly detection je besplatan na subscription razini i šalje obavijesti putem Action Groupa (email, SMS, webhook, Logic App).
GCP nema dedicirani anomaly service kao AWS, pa se obično kombinira Budget API s programski definiranim alertima ili se koriste treća rješenja poput Looker Studio dashboarda na BigQuery billing exportu.
Pravilo palca koje koristim: minimum threshold od 100 USD i percentage threshold od 40% smanjuje 80% lažnih alarma na manjim računima.
Integracija sa Slackom putem SNS → Lambda → Webhook smanjuje vrijeme reakcije s prosječnih 19 sati (email) na manje od 30 minuta.
Detekcija anomalija nije zamjena za budžete; radi u tandemu s budgetima i tagging strategijom za potpunu vidljivost.

Što je anomalija u cloud troškovima?

Iskreno, definicija je jednostavnija nego što zvuči. Anomalija u cloud troškovima je svaki dnevni ili tjedni skok potrošnje koji značajno odstupa od povijesnog obrasca za određeni servis, account ili tim. Razlikujem tri tipa s kojima se najčešće susrećem u proizvodnji.

Nagli skok (sudden spike) gdje EC2 ili Compute Engine potrošnja preko noći skoči 300%, najčešće zbog runaway batch joba ili krivo konfiguriranog autoscalinga. Na taj sam tip naletio prošle godine kada je test job ostavljen u petak ujutro i odlepio 4.000 USD do ponedjeljka. Postupno povećanje (gradual creep) gdje S3 ili Blob Storage troškovi rastu 5–10% tjedno zbog logova bez lifecycle politika. Ponavljajuća anomalija (recurring) gdje se isti skok pojavljuje svakog vikenda zbog cron joba koji zaboravlja ugasiti dev klaster.

ML modeli kod sva tri davatelja gledaju 10–14 dana povijesti, uzimaju u obzir sezonske obrasce (dan-noć, radni dan-vikend) i koriste anomaly score za odlučivanje treba li poslati alert. Ručno postavljeni budgeti hvataju samo apsolutne pragove, dok anomaly detection hvata relativna odstupanja. Kombinacija oba pristupa je standardni FinOps obrazac koji preporučujem.

Kako funkcionira AWS Cost Anomaly Detection?

AWS Cost Anomaly Detection (CAD) je besplatan servis unutar Cost Managementa koji koristi Random Cut Forest ML algoritam za otkrivanje neobične potrošnje. Konfiguracija se sastoji od dva koraka: definiranja monitora (što pratimo) i subskripcije (kako i kome šaljemo alert). U organizaciji s 40+ AWS accounta koristim četiri tipa monitora: AWS services (default, pokriva sve), Linked account, Cost category i Cost allocation tag.

Evo Terraform konfiguracije koju koristim za production setup s alertima preko SNS topica:

resource "aws_ce_anomaly_monitor" "service_monitor" {
  name              = "prod-service-monitor"
  monitor_type      = "DIMENSIONAL"
  monitor_dimension = "SERVICE"
}

resource "aws_ce_anomaly_subscription" "prod_alerts" {
  name             = "prod-anomaly-alerts"
  frequency        = "IMMEDIATE"
  monitor_arn_list = [aws_ce_anomaly_monitor.service_monitor.arn]

  subscriber {
    type    = "SNS"
    address = aws_sns_topic.cost_anomalies.arn
  }

  threshold_expression {
    and {
      dimension {
        key           = "ANOMALY_TOTAL_IMPACT_ABSOLUTE"
        values        = ["100"]
        match_options = ["GREATER_THAN_OR_EQUAL"]
      }
    }
    and {
      dimension {
        key           = "ANOMALY_TOTAL_IMPACT_PERCENTAGE"
        values        = ["40"]
        match_options = ["GREATER_THAN_OR_EQUAL"]
      }
    }
  }
}

Dva praga u threshold_expression bloku zajedno znače sljedeće: pošalji alert samo ako je apsolutni utjecaj ≥ 100 USD I postotni ≥ 40%. Ovo je ključno za smanjenje šuma. Bez toga ćete u prvih tjedan dana dobiti desetke alarma za dev environment u kojem je netko pokrenuo jedan ec2.large instanca koji prelazi 200% dnevnog prosjeka, ali u apsolutnom iznosu 8 USD. Više o pragovima i strukturi threshold_expression možete pronaći u službenoj AWS dokumentaciji za Cost Anomaly Detection.

Kako postaviti detekciju anomalija u Azureu?

Azure Cost Management ima dvije razine anomaly detekcije: automatska detekcija (uvijek uključena na subscription razini, vidljiva u Cost analysis viewu) i konfigurabilna anomaly alerts koja šalju notifikacije. Za razliku od AWS-a, Azure detekcija je trenutno ograničena na subscription i resource group scope. Nema cost allocation tag pomoću kojeg možete pratiti anomalije po timu ili projektu, što je značajan nedostatak ako koristite multi-tenant subscription model.

Postavljanje preko Azure CLI-ja:

# Definiraj akcijsku grupu za webhook u Slack
az monitor action-group create \
  --name finops-anomaly-ag \
  --resource-group finops-rg \
  --action webhook slack-anomaly https://hooks.slack.com/services/XXX

# Stvori anomaly alert na subscription razini
az costmanagement alert create \
  --scope "/subscriptions/$SUB_ID" \
  --alert-name "prod-anomaly-alert" \
  --alert-type Anomaly \
  --action-group-id "/subscriptions/$SUB_ID/resourceGroups/finops-rg/providers/microsoft.insights/actionGroups/finops-anomaly-ag" \
  --threshold 100 \
  --threshold-type Actual

Azure koristi vlastiti ML model treniran na povijesnim podacima u Cost Management API-ju; obavijesti dolaze u prosjeku 36 sati nakon dana u kojem se anomalija dogodila, što je sporije od AWS-ovih 24 sata. Detalji o algoritmu i podržanim scope opcijama dostupni su u Microsoftovoj dokumentaciji o analizi neočekivanih troškova.

GCP detekcija anomalija putem Budget API-ja

GCP još uvijek nema dedicirani anomaly detection servis ekvivalentan AWS-ovom CAD-u, što je po mom mišljenju najveća rupa u Google Cloud FinOps stacku u 2026. Standardni pristup koji koristim u praksi je kombinacija tri komponente: (1) Budget API alerti s programski izračunatim pragovima, (2) BigQuery billing export kao izvor podataka i (3) Scheduled Query ili Cloud Function koja računa odstupanje od pokretnog prosjeka.

Primjer SQL upita koji svakodnevno traži anomalije u BigQueryju nad cloud_billing_export tablicom:

WITH daily AS (
  SELECT
    DATE(usage_start_time) AS day,
    service.description AS service,
    SUM(cost) AS daily_cost
  FROM `myproj.billing_export.gcp_billing_export_v1_XXXX`
  WHERE DATE(usage_start_time) >= DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)
  GROUP BY day, service
),
stats AS (
  SELECT
    service,
    AVG(daily_cost) AS avg_cost,
    STDDEV(daily_cost) AS std_cost
  FROM daily
  WHERE day < CURRENT_DATE()
  GROUP BY service
)
SELECT
  d.service,
  d.daily_cost,
  s.avg_cost,
  ROUND((d.daily_cost - s.avg_cost) / NULLIF(s.std_cost, 0), 2) AS z_score
FROM daily d JOIN stats s USING(service)
WHERE d.day = CURRENT_DATE() - 1
  AND ABS((d.daily_cost - s.avg_cost) / NULLIF(s.std_cost, 0)) > 2.5
  AND d.daily_cost > 50;

Z-score od 2.5 (oko 99% interval) i minimalni dnevni trošak od 50 USD daju mi sličnu kvalitetu signala kao AWS CAD s default pragovima. Rezultat se Cloud Scheduler-om gura u Pub/Sub topic, koji aktivira Cloud Function koja formatira poruku i šalje je u Slack kanal. Kompletan setup košta oko 3 USD mjesečno za billing export, što je dramatično jeftinije od trećih FinOps platformi koje za istu funkcionalnost naplaćuju 500+ USD mjesečno.

Usporedba: AWS vs Azure vs GCP detekcija anomalija

Značajka	AWS Cost Anomaly Detection	Azure Cost Management Anomaly	GCP (Budget + BigQuery)
Cijena	Besplatno	Besplatno	~3 USD/mj za billing export
Vrijeme do alerta	~24 sata	~36 sati	24h (ovisi o scheduleru)
ML model	Random Cut Forest	Vlastiti (nije javno dokumentiran)	Custom (Z-score, MAD, Prophet)
Scope granularnost	Service, account, cost category, tag	Subscription, resource group	Project, label, SKU (custom SQL)
Frequency	Immediate, Daily, Weekly	Daily samo	Po vlastitom scheduleu
Integracije	SNS, Email, Chatbot	Action Groups (webhook, Logic App)	Pub/Sub, Cloud Function, bilo što
Multi-account	Da (Organization)	Da (Management Group)	Da (Folder/Org export)
Najbolje za	Tim koji želi out-of-the-box rješenje	EA klijenti s manjim brojem subskripcija	Timovi koji žele potpunu kontrolu

Kako smanjiti broj lažnih pozitiva u detekciji anomalija?

Najveća pritužba inženjerskih timova nakon uvođenja anomaly detekcije je preplavljenost alarmima. Vidio sam timove koji su nakon tjedan dana isključili sve obavijesti jer su dobivali 80+ alarma dnevno. Pet pravila koje primjenjujem da se broj alarma sveo na realnih 1–3 dnevno:

Kombinirana apsolutni + postotni prag umjesto samo jedan.
Odvojeni monitori za prod i nonprod jer dev environment ima prirodno volatilniju potrošnju.
Izuzeti servise s prirodno spiky potrošnjom poput Lambda invocationa ili BigQuery on-demand upita.
Blackout window-i tijekom planiranih migracija ili Black Friday rasprodaja.
Tjedni audit alarma u kojem označavate svaki alarm kao "stvaran" ili "lažni". Taj feedback ne ide natrag u ML model, ali pomaže ručno kalibrirati pragove.

Za detaljniji pristup tagging strategiji koja drastično poboljšava kvalitetu detekcije, preporučujem da pročitate naš vodič o right-sizingu cloud instanci. Pravilno taggiranje resursa po environment, team i project tagovima omogućuje da CAD monitore postavljate per-team i izbjegavate šum koji nastaje miješanjem prod i dev troškova.

Integracija sa Slackom, PagerDutyjem i Jirom

Email obavijesti su mrtvo slovo na papiru. Moja interna metrika pokazuje da inženjeri otvaraju email anomaly alert prosječno 19 sati nakon slanja. Slack i PagerDuty su standardni izbor; preporučujem ovaj tijek za AWS:

CAD šalje obavijest na SNS topic cost-anomalies.
Lambda funkcija pretplaćena na topic parsira poruku, dohvaća dodatni kontekst iz Cost Explorer API-ja (top 3 doprinositelja troška).
Lambda formatira Slack Block Kit poruku s gumbima "Acknowledge", "Investigate", "Open Jira ticket".
Za anomalije s utjecajem ≥ 1000 USD, Lambda dodatno triggers PagerDuty Events v2 API.

Primjer Python kodiranja Slack poruke iz Lambde:

import json, os, urllib.request

def lambda_handler(event, context):
    for record in event["Records"]:
        msg = json.loads(record["Sns"]["Message"])
        impact = msg["impact"]["totalImpact"]
        service = msg["rootCauses"][0]["service"]

        slack_payload = {
            "blocks": [
                {"type": "header", "text": {"type": "plain_text",
                 "text": f"Anomalija troška: +{impact:.0f} USD"}},
                {"type": "section", "fields": [
                    {"type": "mrkdwn", "text": f"*Servis:* {service}"},
                    {"type": "mrkdwn", "text": f"*Account:* {msg['accountId']}"},
                ]},
                {"type": "actions", "elements": [
                    {"type": "button", "text": {"type": "plain_text",
                     "text": "Otvori Cost Explorer"},
                     "url": msg["anomalyDetailsLink"]}
                ]}
            ]
        }
        req = urllib.request.Request(
            os.environ["SLACK_WEBHOOK"],
            data=json.dumps(slack_payload).encode(),
            headers={"Content-Type": "application/json"}
        )
        urllib.request.urlopen(req)
    return {"statusCode": 200}

Root cause analiza skoka troškova

Detekcija anomalije je tek pola posla. Drugi dio je brza root cause analiza. AWS CAD u svakoj obavijesti vraća rootCauses array s do 10 doprinositelja po servisu, regiji i usage type-u, što je u 80% slučajeva dovoljno. Kada nije, koristim sljedeći triage tijek koji odrađujem u manje od 15 minuta:

Otvorim Cost Explorer s granulacijom Hourly za zadnja 3 dana, grupirano po Usage Type.
Filtriram na servis koji je triggerao alarm i identificiram točan sat skoka.
Otvorim CloudTrail za taj prozor i pretražujem RunInstances, CreateBucket, PutObject i slične API pozive.
Korelliram sa CI/CD deploy logovima. Najčešći krivac je krivi Terraform plan koji je proveden u prod.

Za sustavno hvatanje uzroka preporučujem također i naš tekst o automatskom otkrivanju neiskorištenih cloud resursa. Često se ispostavi da je "anomalija" zapravo zaboravljeni resurs koji se nakon migracije nije ugasio, a periodičan cleanup script eliminira velik dio repetitivnih alarma.

FinOps proces oko detekcije anomalija

Tehnologija je beskorisna bez ljudskog procesa. FinOps Foundation framework definira tri faze (Inform, Optimize, Operate) i detekcija anomalija primarno spada u Operate fazu. U organizacijama u kojima sam vodio FinOps inicijativu, definirao sam tri uloge oko svakog alarma: First responder (DevOps inženjer na on-call rotaciji), Cost owner (tech lead tima koji je vlasnik servisa) i FinOps champion (koordinator koji prati trendove i postotak lažnih pozitiva).

SLA koji preporučujem: acknowledge unutar 1 sata radnim danom, 4 sata vikendom; root cause identificiran unutar 24 sata; action item u Jiri unutar 48 sati. Bez SLA-a alarmi postaju buka koju svi ignoriraju. Za dublje pokrivanje obvezujućih popusta koji često uzrokuju "lažne" anomalije (kada se diskonti istroše), pogledajte vodič o Reserved Instances i Savings Plans.

Često postavljana pitanja

Je li AWS Cost Anomaly Detection besplatan?

Da, AWS Cost Anomaly Detection je u potpunosti besplatan servis bez naknada za broj monitora, subskripcija ili otkrivenih anomalija. Plaćate samo SNS i Lambda invocation troškove ako koristite te servise za rutiranje obavijesti, što je u praksi ispod 1 USD mjesečno.

Koliko vremena treba da AWS detektira anomaliju?

AWS Cost Anomaly Detection procesira troškove na dnevnoj razini i obično šalje alert unutar 24 sata od kraja dana u kojem se anomalija dogodila. U praksi to znači da skok od ponedjeljka uvečer dobivate u utorak između 12:00 i 18:00 UTC.

Kako razlikovati anomaliju od stvarnog rasta troškova?

Anomalija je jednokratan ili kratkotrajan skok izvan očekivanog raspona varijacije, dok je rast trajno pomicanje base linije naviše. ML modeli sva tri davatelja automatski uče novu baseline nakon 7–14 dana stabilne potrošnje, pa rast prestaje generirati anomaly alerte tek nakon te periode.

Može li GCP detektirati anomalije bez BigQuery exporta?

Djelomično, GCP Budget alerti podržavaju forecast alerte koji upozoravaju kada predviđanje za kraj mjeseca prelazi prag, ali to nije prava detekcija anomalija. Za detekciju neuobičajenih dnevnih obrazaca BigQuery billing export je trenutno jedini službeni put.

Trebam li i budgete i detekciju anomalija?

Da, oba mehanizma rade različite stvari. Budgeti hvataju apsolutne pragove (mjesec ne smije preći 50.000 USD), a anomaly detection hvata relativna odstupanja (Lambda je danas skočila 400% iznad prosjeka). Najbolji FinOps timovi koriste oba alata paralelno s različitim SLA-ovima.