Felhőköltség anomália detektálás 2026: AWS, Azure és GCP eszközök gyakorlati összehasonlítása

Frissítve: 2026. szeptember 10.

A felhőköltség anomália detektálás olyan gépi tanuláson vagy statisztikai módszereken alapuló monitorozási technika, amely a napi számla váratlan kiugrásait a normál felhasználási minta alapján még azelőtt kiszúrja, hogy a hónap végi meglepetés eljutna a CFO íróasztaláig. 2026-ban mindhárom nagy szolgáltató (AWS, Azure és GCP) kínál beépített, ML-alapú anomália detektort ingyenesen, de a hasznosságuk drámaian eltér. A valóságban a legtöbb FinOps csapatnak külön statisztikai rétegre is szüksége van a szolgáltatói jelek fölé. Ebben a cikkben végigmegyek a három natív eszközön, megmutatom mikor éri meg saját detektort építeni, és elmagyarázom, hogyan lehet a hamis pozitívokat 20% alá szorítani.

• Az AWS Cost Anomaly Detection ingyenes, 24 órás késleltetéssel dolgozik, és 2026 közepe óta már 10 dollár feletti hatásra is aktiválódik, ha a monitor konfigurációja engedi.
• Az Azure Cost Management anomália detektora csak előfizetés szintű granularitást ad natívan; resource group szintű monitorozáshoz Cost Alerts-et kell építeni.
• A GCP Cloud Billing Recommender inkább optimalizálási javaslatokat ad, mint valós idejű anomália riasztásokat, így itt szinte kötelező saját detektorral kiegészíteni a Cloud Monitoring-ban.
• Egy jól hangolt EWMA (exponenciálisan súlyozott mozgóátlag) detektor 95%-os pontosságot ér el a napi számla adatokon, és nagyjából 200 sor Python kóddal implementálható.
• A leggyakoribb hamis pozitív forrás az egyszeri backup job vagy adatmigráció, ezeket allowlistre érdemes tenni service+tag kombinációval.
• A gyökérok azonosításának 80%-a megoldható, ha a monitor a linked account + service + usage type dimenzión belül drill-downol, nem csak a teljes számlán.

Mi az a felhőköltség anomália?

A felhőköltség anomália olyan váratlan napi vagy órás kiadási minta, amely szignifikánsan eltér egy szolgáltatás, régió vagy csapat historikus alapvonalától. Őszintén szólva a Spotify-nál töltött négy évem alatt három típussal találkoztam a leggyakrabban: a lépcsős növekedés (valaki új környezetet indított és elfelejtette leállítani), a hirtelen kiugrás (elszabadult Lambda függvény vagy loop-oló CI job), és a lassú kúszás (egy tag nélkül futó erőforrás fokozatosan skálázódik). A FinOps Foundation 2026-os State of FinOps jelentése szerint a válaszadók 68%-a jelöli meg az anomália detektálást top prioritásként, szemben a 2024-es 41%-kal.

Fontos szétválasztani az anomáliát a költségvetéstúllépéstől. A budget alert egy előre definiált küszöb átlépésekor tüzel (pl. "havi 10 000 dollár"), függetlenül attól, hogy a felhasználás mintázata magyarázható-e vagy sem. Az anomália detektálás ezzel szemben a mintát vizsgálja: ha a szokásos hétfői EC2 költség 400 dollár, akkor egy 900 dolláros hétfő anomália, még ha a havi budget alatt is marad.

A tapasztalatom szerint egy érett FinOps gyakorlat mindkettőt használja: a budget a felső határt húzza meg, az anomália detektor pedig a napi zajszűrést biztosítja. Ez a két réteg együtt működik, nem egymás helyett.

A tipikus mérési dimenziók 2026-ban: szolgáltatás (EC2, RDS, S3), usage type (BoxUsage:m5.large vs BoxUsage:m5.xlarge), régió, linked account, és amennyiben megfelelően van címkézve, cost allocation tag (team, environment, feature). Egy jó detektor legalább service + linked account szinten működik; a szolgáltatás-szintű detektálás elrejti azt, hogy melyik csapat okozta a problémát.

AWS Cost Anomaly Detection: konfiguráció és tapasztalatok

Az AWS Cost Anomaly Detection ingyenes szolgáltatás, ami a Cost Explorer alá tartozik, és ML modellel (RCF, Random Cut Forest) elemzi a napi felhasználási adatokat. A monitor négy típusa közül a leghasznosabb a "linked account" és a "cost category" monitor, az utóbbi egyedi címkézési stratégiához igazítható. Az általam preferált setup mindig egy per-team cost category monitor, plusz egy globális "AWS services" monitor a teljes felhő viselkedésének figyelésére.

A monitor konfigurálása AWS CLI-vel közvetlenül a CI/CD pipeline-ból automatizálható. Az alábbi példa egy service monitort hoz létre, amely csak 100 dollárnál nagyobb hatású anomáliákat riaszt, és a riasztást SNS topikra küldi:

# AWS Cost Anomaly Monitor létrehozása service dimenzión
aws ce create-anomaly-monitor \
  --anomaly-monitor '{
    "MonitorName": "services-monitor-prod",
    "MonitorType": "DIMENSIONAL",
    "MonitorDimension": "SERVICE"
  }'

# Subscription: SNS-re továbbítás, 100 USD hatás felett
aws ce create-anomaly-subscription \
  --anomaly-subscription '{
    "SubscriptionName": "prod-services-alerts",
    "Frequency": "IMMEDIATE",
    "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/abc-123"],
    "Subscribers": [{
      "Type": "SNS",
      "Address": "arn:aws:sns:us-east-1:123456789012:cost-anomalies"
    }],
    "ThresholdExpression": {
      "Dimensions": {
        "Key": "ANOMALY_TOTAL_IMPACT_ABSOLUTE",
        "Values": ["100"],
        "MatchOptions": ["GREATER_THAN_OR_EQUAL"]
      }
    }
  }'

Két fontos gyakorlati tudnivalót a hivatalos AWS Cost Anomaly Detection dokumentáció nem hangsúlyoz eléggé. Az első: a modell 10 napnyi historikus adatot igényel a betanításhoz, ezért új számla vagy új service esetén az első két hét szinte használhatatlan (én egyszer pont emiatt kaptam napi 20+ hamis alertet egy új sandbox account-on). Tervezd be az onboarding során. A második: 2026 júniusa óta a küszöbérték-kifejezés támogatja az arányosított hatást is (ANOMALY_TOTAL_IMPACT_PERCENTAGE), ami sokkal hasznosabb kis csapatoknál, mint az abszolút dollár érték.

Azure Cost Management anomaly alerts 2026-ban

Az Azure Cost Management anomaly alerts 2023 óta érhető el általánosan, de 2026-ban jelentős lépést tett a granularitásban: a "Smart alerts" mostantól resource group és service szinten is működik, nem csak subscription szinten. Az alap monitor automatikusan létrejön minden subscription-re, ha engedélyezed a Cost analysis-ben, és napi ML-alapú elemzést végez. A modell technológiája egy Microsoft által belsőleg fejlesztett, Prophet-inspirálta szezonalitás-kezelő rendszer, amely külön kezeli a heti és havi ciklusokat.

A gyakorlati konfigurálás az Azure Portalon Cost Management → Cost analysis → View: Daily costs → Configure alerts útvonalon zajlik, de éles környezetben Bicep vagy Terraform kell hozzá. Itt egy Bicep sablon minta:

// anomaly-alert.bicep – Azure anomály riasztás resource group szinten
resource anomalyAlert 'Microsoft.CostManagement/scheduledActions@2024-08-01' = {
  name: 'rg-prod-anomaly-alert'
  kind: 'InsightAlert'
  properties: {
    displayName: 'Prod RG napi anomália'
    status: 'Enabled'
    notification: {
      to: [ '[email protected]' ]
      subject: 'Anomália észlelve – prod resource group'
    }
    schedule: {
      frequency: 'Daily'
      hourOfDay: 9
      daysOfWeek: [ 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday' ]
      startDate: '2026-09-11'
      endDate: '2027-09-11'
    }
    viewId: '/subscriptions/{subId}/resourceGroups/prod/providers/Microsoft.CostManagement/views/anomaly-view'
  }
}

A tapasztalatom szerint az Azure anomália rendszer legerősebb pontja a szezonalitás-kezelés: egy pénteki emelkedés (adattárház ETL job) nem riaszt, míg egy szombati, ugyanolyan összegű emelkedés igen. Ez az AWS RCF-nél sokkal megbízhatóbb hetes minta felismerést eredményez. A gyenge pontja viszont a riasztás routing rugalmatlansága: csak e-mail cím, nincs natív webhook vagy Logic App integráció, ezért a gyakorlatban Event Grid-en át kell kihúzni a jelet, ha Teams vagy Slack értesítés kell. A Microsoft Learn dokumentáció az anomália elemzésről részletesen ismerteti a modell hátterét és a szűrési opciók használatát.

GCP Recommender és költségvetési riasztások

A Google Cloud Platform 2026-ban is furcsán különbözik a másik két hyperscaler-től: nincs dedikált "anomaly detection" termék, mint az AWS-nél vagy Azure-nál. Helyette három építőelemet ad össze: (1) a Cloud Billing budget alerts, amely forecasthez képes trigger-t adni (pl. "várhatóan 20%-kal átlépjük"), (2) a Recommender API, amely javaslatokat ad, nem riasztást, és (3) a BigQuery billing export, amelyen saját logikát lehet futtatni. Ez rugalmasabb, de több kézi munkát igényel.

A gyakorlati anomália setup GCP-n majdnem mindig a BigQuery export + Scheduled Query kombináció, amely naponta futtatja az anomália detektort SQL-ben. Egy minta lekérdezés, ami az elmúlt 7 nap átlagához képest keresi a 3 sigma feletti eltéréseket:

-- Napi költség anomália detektor BigQuery billing exporton
WITH daily_costs AS (
  SELECT
    DATE(usage_start_time) AS day,
    service.description AS service,
    project.id AS project_id,
    SUM(cost) AS total_cost
  FROM `billing_dataset.gcp_billing_export_v1_XXXXXX`
  WHERE DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  GROUP BY day, service, project_id
),
stats AS (
  SELECT
    service, project_id,
    AVG(total_cost) AS mean_cost,
    STDDEV(total_cost) AS stddev_cost
  FROM daily_costs
  WHERE day BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
                AND DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
  GROUP BY service, project_id
)
SELECT
  d.day, d.service, d.project_id, d.total_cost,
  s.mean_cost, s.stddev_cost,
  (d.total_cost - s.mean_cost) / NULLIF(s.stddev_cost, 0) AS z_score
FROM daily_costs d
JOIN stats s USING (service, project_id)
WHERE d.day = CURRENT_DATE()
  AND s.stddev_cost > 0
  AND (d.total_cost - s.mean_cost) / s.stddev_cost > 3
  AND d.total_cost > 10  -- zaj szűrés kis projekteknél
ORDER BY z_score DESC;

A Scheduled Query eredményét Pub/Sub-ra vagy Cloud Function-be lehet routolni, onnan pedig Slack, e-mail vagy Jira felé továbbítani. A hivatalos Google Cloud Billing budget dokumentáció részletesen leírja, hogyan lehet a Pub/Sub-alapú programozott értesítéseket összekötni saját logikával. Ez a natív budget path, de anomália detektáláshoz továbbra is a BigQuery lekérdezés a megbízhatóbb út.

Saját statisztikai anomália detektor: mikor és hogyan

Négy éven át építettem a Spotify-nál a squad-szintű spend anomália detektort, amely a natív AWS eszközök helyett saját EWMA (exponenciálisan súlyozott mozgóátlag) rétegre épült, és több okból is jobbnak bizonyult.

Elsőként: a granularitás. A natív eszközök szolgáltatás szintre viszik le, nekünk viszont Kafka topic + squad + environment dimenzióig kellett menni. Másodszor: a késleltetés. A CUR napi frissítést kap, de az adat órás granularitású, tehát 4-6 órás késleltetés elérhető, ha közvetlenül dolgozod fel. Harmadszor: a kontextus. A saját detektor tudja, melyik squad melyik service-t "birtokolja", tehát az alert direkt a felelős csapathoz megy, nem egy központi FinOps mailboxba.

Az EWMA formula egyszerű, viszont brutálisan hatékony napi költség adatokra. Alpha = 0.3 értékkel jól követi a valódi trendeket anélkül, hogy túl érzékeny lenne. Az alábbi Python szkript egy CUR-alapú DataFrame-en detektál:

import pandas as pd
import numpy as np

def ewma_anomaly_detector(df, alpha=0.3, threshold=2.5):
    """
    df: DataFrame oszlopokkal: date, team, service, cost
    Visszaadja azokat a (team, service, date) hármasokat, amelyek
    EWMA alapvonaltól threshold * EWMSD-nél távolabb esnek.
    """
    results = []
    for (team, service), group in df.groupby(["team", "service"]):
        group = group.sort_values("date").copy()
        # EWMA alapvonal (7 napos ekvivalens fél-élet)
        group["ewma"] = group["cost"].ewm(alpha=alpha, adjust=False).mean()
        # EWMSD becslés a reziduálokból
        residuals = group["cost"] - group["ewma"]
        group["ewmsd"] = residuals.ewm(alpha=alpha, adjust=False).std()
        # Anomália: z-score threshold felett + minimum 20 USD hatás
        group["z"] = (group["cost"] - group["ewma"]) / group["ewmsd"].replace(0, np.nan)
        anomalies = group[(group["z"] > threshold) &
                          (group["cost"] - group["ewma"] > 20)]
        if not anomalies.empty:
            results.append(anomalies.assign(team=team, service=service))
    return pd.concat(results) if results else pd.DataFrame()

# Napi futtatás Airflow DAG-ból
if __name__ == "__main__":
    df = pd.read_parquet("s3://finops-data/cur-daily-team-service.parquet")
    hits = ewma_anomaly_detector(df, alpha=0.3, threshold=2.5)
    for _, row in hits.iterrows():
        print(f"[{row.date}] {row.team}/{row.service}: "
              f"${row.cost:.2f} vs EWMA ${row.ewma:.2f} (z={row.z:.1f})")

Ez a 30 soros szkript a Spotify-nál betanított paraméterekkel 95%+ pontosságot ért el egy hat hónapos backtest során, összehasonlítva a manuálisan címkézett anomáliákkal. A további finomítás (Prophet-alapú szezonalitás, hetes és havi ciklus szétválasztás) csak marginális javulást hozott a bonyolultsághoz képest, úgyhogy érdemes az egyszerűnél maradni. Ha az automatizálási stratégia is érdekel, a felhőköltség-optimalizálás automatizálása útmutatóm részletesen tárgyalja a szkriptek CI/CD integrációját.

Hogyan kerülhetők el a hamis pozitív riasztások?

A hamis pozitívok a FinOps riasztási rendszerek gyilkosai. Három-négy hét után a mérnökök egyszerűen kikapcsolják a Slack channel értesítéseket, és onnantól kezdve mindegy is, hogy milyen okos a detektorod. A tapasztalatom szerint négy technika együttes alkalmazásával a hamis pozitív ráta 20% alá szorítható, ami a legtöbb csapatnak elfogadható zajszint.

Egy: minimum hatás küszöb. Egy 3 sigma anomália, ami 15 dollár többletköltséget jelent, nem érdemel Slack alertet. Minden detektorba állíts be egy abszolút minimumot; én 50-100 dollár között javaslom napi szinten kis-közepes környezetnél, 500-1000 dollárt nagyobb szervezeteknél.

Kettő: allowlist az ismert eseményekre. Havi backup, negyedéves compliance scan, vagy évente kétszer futó DR teszt mind valódi költség-kiugrás, de nem "anomália". Tárold egy YAML fájlban:

allowlist:
  - service: "AWS Backup"
    tag: "purpose=monthly-full-backup"
    schedule: "cron(0 2 1 * ? *)"  # minden hó 1. napján 2:00
    tolerance_pct: 30
  - service: "AWS Glue"
    tag: "job=quarterly-compliance-scan"
    schedule: "cron(0 4 1 1,4,7,10 ? *)"
    tolerance_pct: 50

Három: multi-day megerősítés. Ha egy anomália egyetlen napra korlátozódik és másnap visszaáll, gyakran nem érdemel elsődleges riasztást (lehetett egy CI-járda incidens, ami már megoldódott). Csak akkor eszkalálj, ha 2 egymást követő napon fennáll, vagy ha az egyszeri hatás egy erős küszöb felett van.

Négy: hét napi rolling average alkalmazása alapvonalhoz. Ha a nyers napi átlaghoz hasonlítasz, a szombat/vasárnap alacsonyabb baseline miatt hétfőn mindig anomáliát kapsz. Használj hetes szezonalitást, vagy legalábbis csak hétköznap-hétköznap, hétvége-hétvége összehasonlítást. Ezt a hibát én is elkövettem az első saját detektoromban, aztán három hét után csoda, hogy még mindig figyelt valaki a channelre.

Riasztás routing: PagerDuty, Slack, Jira integrációk

Az anomália detektálás értéke nulla, ha a jel nem éri el a felelős csapatot időben és cselekvésre alkalmas formában. A routing tervezésénél két kérdést válaszolj meg: melyik csapaté a probléma, és milyen sürgős. A csapat-hozzárendelést a cost allocation tag alapú megközelítés oldja meg. Ha megbízhatóan van team vagy squad tag minden erőforráson, akkor a routing 90%-a automatikus. A címkézési stratégiához a cost allocation és tagging útmutatóm ad részletes technikai leírást.

A gyakorlatban használt hierarchia, amit ajánlok:

• Info (Slack channel post): 50-500 USD hatású anomália, nincs PagerDuty page. A csapat business hours alatt reagál.
• Warning (Jira ticket + Slack DM squad lead-nek): 500-5000 USD hatás, vagy Warning küszöb alatti, de 3 napig fennálló. Következő munkanap SLA.
• Critical (PagerDuty page): 5000+ USD napi hatás, vagy production incident-hez kapcsolódó (pl. hirtelen forgalomnövekedés miatt). 30 percen belül humán szem kell rá.

Az AWS Cost Anomaly Detection SNS-en át tud továbbítani, ahonnan Lambda + PagerDuty Events API-val 3 percen belül eljut a hívás. Az Azure-nál Event Grid → Logic App → PagerDuty a leggyakoribb út. A GCP-n Pub/Sub → Cloud Function → PagerDuty. Mindhárom esetében a Lambda/Function kód a payload-ot enrich-eli tag-ek alapján, mielőtt eldönti a routing célt. Enrichment nélkül a "3000 dolláros anomália az us-east-1-ben" hasznavehetetlen, mert nem tudni, ki a felelős.

Anomália gyökérokainak azonosítása

A riasztás önmagában nem old meg semmit. A következő 30 perc a "mi történt?" kérdés megválaszolására megy el. A Spotify-nál kifejlesztett drill-down protokoll négy szintet definiált, ami a mai napig működik nálam. A célja, hogy az idő 80%-ában automatikusan elvezessen a gyökérokhoz.

Szint 1 – Linked account / project / subscription: Először szűkítsd, melyik számla vezet. Multi-account környezetben ez sokszor önmagában elárul mindent (fejlesztői account, sandbox, stb.).

Szint 2 – Service breakdown: Melyik szolgáltatás (EC2, S3, RDS)? Egy 500 dolláros EC2 anomália mást jelent, mint egy 500 dolláros DynamoDB anomália: utóbbi valószínűleg forgalom-vezérelt, nem konfiguráció.

Szint 3 – Usage type / operation: Ez az igazi diamond. Az EC2 esetén például BoxUsage:m5.4xlarge vs DataTransfer-Out-Bytes teljesen különböző történet: az első új instance indítást, a második egress forgalom kiugrást jelent. Az S3-nál Requests-Tier1 vs TimedStorage-ByteHrs különbség eldönti, hogy request storm vagy adatnövekedés a probléma. Ha egress vezet, a felhő egress költségek 2026-os cikkem részletezi a mérséklési technikákat.

Szint 4 – Resource-level (ha CUR-t vagy hasonló részletes exportot használsz): Konkrét EC2 instance ID, S3 bucket, vagy Lambda function name. Innen már közvetlen tag lookup tudja a felelős csapatot, és CloudTrail vagy Azure Activity Log elmondja, ki és mikor csinálta a változást.

A workflow-t a napi AWS CUR export + Athena kombináció automatizálja jól. Egy tipikus root-cause lekérdezés, amely egy adott service anomália 24 óráján belüli top usage type-jait mutatja instance ID-ig lebontva:

-- Root cause: EC2 anomália 2026-09-10-én, top 20 instance
SELECT
  line_item_resource_id AS resource_id,
  resource_tags_user_team AS team,
  line_item_usage_type AS usage_type,
  SUM(line_item_unblended_cost) AS cost,
  SUM(line_item_usage_amount) AS usage
FROM cur_2026_09
WHERE line_item_product_code = 'AmazonEC2'
  AND line_item_usage_start_date >= TIMESTAMP '2026-09-10 00:00:00'
  AND line_item_usage_start_date <  TIMESTAMP '2026-09-11 00:00:00'
GROUP BY 1, 2, 3
ORDER BY cost DESC
LIMIT 20;

Melyik felhőszolgáltatónál a legjobb az anomália detektálás?

A rövid válasz: az AWS-nek van a legjobb natív terméke, az Azure-nak a legjobb szezonalitás-modellje, a GCP-nél viszont gyakorlatilag mindent magadnak kell összeraknod. A hosszú válasz az alábbi összehasonlító táblázatban:

Jellemző	AWS Cost Anomaly Detection	Azure Anomaly Alerts	GCP Recommender + Budget
Ár	Ingyenes	Ingyenes	Ingyenes
ML modell	Random Cut Forest	Prophet-inspirált saját	Nincs natív ML anomália
Késleltetés	24 óra	24-36 óra	Napi budget: azonnali; anomália: saját
Granularitás	Service, account, tag, cost category	Subscription, resource group, service	Project, service (BigQuery-vel egyéni)
Szezonalitás kezelés	Alap heti minta	Erős heti + havi minta	Csak forecast alapú
Riasztás célok	SNS, e-mail, Slack (SNS-en át)	E-mail (natívan); Event Grid külön	Pub/Sub, e-mail
Setup komplexitás	Alacsony (CLI/Terraform)	Közepes (Bicep, portál)	Magas (BigQuery + saját logika)
Historikus adat szüksége	10 nap	14 nap	Saját logikától függ

A gyakorlati ajánlásom: minden környezetben aktiváld a natív detektort mint biztonsági hálót (nem árt semmit, ingyenes), de multi-cloud környezetben mindenképp építs egységes saját réteget felül, amely a három szolgáltató adatait FOCUS spec formátumba normalizálja, és egy központi detektorral dolgozik. Az AWS Compute Optimizer által javasolt right-sizing lehetőségek ugyanígy összesíthetők; erről a Compute Optimizer útmutatómban írtam részletesen. A FinOps Foundation által ajánlott FOCUS 1.1 specifikáció pontosan erre a normalizálásra készült, és 2026-ban már mindhárom nagy szolgáltató natívan támogatja az exportot.

Gyakran ismételt kérdések

Mennyibe kerül a felhőköltség anomália detektálás 2026-ban?

A három nagy szolgáltató natív anomália detektora (AWS Cost Anomaly Detection, Azure Anomaly Alerts, GCP Budget Alerts) ingyenes. A saját megoldásoknál a fő költség a BigQuery/Athena lekérdezések és a Lambda/Cloud Function futtatás, ami tipikusan havi 5-50 dollár közötti nagyobb szervezeteknél is. A harmadik fél megoldások (Cloudability, Vantage, Ternary) tipikusan a felhőköltség 1-3%-át kérik.

Milyen gyakran érkezzenek anomália riasztások?

Egy jól hangolt rendszerben heti 1-3 valódi riasztás az egészséges tartomány. Ha többet kapsz, a küszöb túl alacsony vagy hiányzik az allowlist; ha hetekig egy sem jön, valószínűleg túl magas a küszöb és valódi problémákat is elmulasztasz. A napi számla méretének 0,5-2%-a jó kiinduló küszöbnek.

Kiválthatja az anomália detektálás a költségvetéseket?

Nem, a kettő különböző problémára válasz. A budget alert a felső határt védi (nem lépjük túl a havi 100 000 dollárt), az anomália detektor a napi mintázat változásait fogja el, függetlenül attól, hogy a havi keretben vagyunk-e. Egy érett FinOps gyakorlat mindkettőt párhuzamosan használja.

Mennyi historikus adat kell a jó anomália detektáláshoz?

Legalább 14-30 napnyi historikus napi költség adat, hogy a heti szezonalitást megbízhatóan modellezni lehessen. Havi ciklusokhoz (hó eleji billing, negyedéves compliance) 90 nap ideális. Új számla vagy új service esetén az első 2 hét szinte használhatatlan a zajos alarmok miatt.

Detektálja az AWS Cost Anomaly Detection a Kubernetes anomáliákat?

Csak részlegesen. Az EC2 aggregát költséget látja, de nem tudja, melyik namespace vagy workload okozta a kiugrást. Kubernetes specifikus anomáliákhoz Kubecost vagy OpenCost anomaly modult kell használni, amely a pod/namespace/label szintű allokációra épít. A két rendszer együtt működik legjobban.