Cloud Cost Anomaly Detection Gids (2026)

Bijgewerkt: 4 juli 2026

Cloud cost anomaly detection is het proces waarbij machine learning-modellen je dagelijkse cloudverbruik vergelijken met historische patronen en automatisch waarschuwen zodra de kosten significant afwijken van de baseline. In tegenstelling tot vaste budget-alerts (die pas afgaan wanneer een drempel is bereikt) detecteert anomaly detection binnen 24 uur een lek, meestal voordat het je maandbudget opblaast. Ik heb teams begeleid die met een goed opgezette detectie zeven cijfers per jaar bespaarden. Deze gids laat zien hoe je dit configureert in AWS, Azure en GCP.

AWS Cost Anomaly Detection is gratis en detecteert afwijkingen doorgaans binnen 24 uur na een cost spike, met een gemiddelde precisie van ~85% na 10 dagen training.
Azure Cost Management ondersteunt sinds 2024 ML-gebaseerde anomaly alerts naast klassieke budget-thresholds. GCP gebruikt Recommender in combinatie met budget alerts.
Effectieve detectie vereist minimaal 10 dagen historische data en granulaire cost allocation tags om ruis te filteren.
Integreer alerts direct met Slack, PagerDuty of Microsoft Teams. Een alert in een postbus die niemand leest, is geld weggooien.
Root cause analysis is het echte werk. Een alert vertelt je dát er iets mis is, niet wát. Bouw runbooks per resource type.
Combineer ML-detectie met threshold-alerts voor kritieke services zoals NAT Gateways en cross-region data transfer.

Wat is cloud cost anomaly detection?

Cloud cost anomaly detection is een categorie FinOps-tooling die statistische modellen (meestal een variant op seasonal ARIMA of gradient boosted trees) traint op je historische kostenpatronen per service, per account en per tag. Zodra de dagelijkse cost data ver genoeg afwijkt van de voorspelde bandbreedte, gaat er een alert af. De cruciale eigenschap is onbewaakte detectie: je hoeft geen drempel te definiëren, het model leert zelf wat "normaal" is voor jouw workload.

Waarom is dit belangrijk in 2026? De gemiddelde enterprise cloud bill groeit met 18 tot 24% per jaar volgens de FinOps Foundation State of FinOps 2026, en die complexiteit maakt handmatige monitoring eigenlijk onmogelijk. Een niet-getagde EKS cluster die per ongeluk in us-east-2 wordt uitgerold in plaats van eu-west-1 kan een team duizenden euro's kosten voordat iemand het merkt op de maandfactuur. Ik heb ooit een fintech-klant gehad waarbij één misgeconfigureerde AWS Glue job in twee dagen $47.000 verstookte. Anomaly detection ving het binnen 20 uur op; zonder die tool was het pas op factuurdatum aan het licht gekomen.

De drie hyperscalers bieden ieder een eigen native oplossing. Voor multi-cloud omgevingen zijn er third-party tools zoals CloudZero, Vantage of Kubecost, maar de native oplossingen dekken 80% van de use cases gratis. Deze gids richt zich op de native diensten omdat die voor de meeste teams de juiste startlijn zijn.

AWS Cost Anomaly Detection instellen

AWS Cost Anomaly Detection is sinds 2020 gratis beschikbaar en gebruikt een intern ML-model dat SageMaker-achtige forecasting toepast op je Cost Explorer data. Configuratie vereist twee onderdelen: een monitor die bepaalt wát gevolgd wordt, en een subscription die bepaalt hoe en aan wie alerts worden gestuurd.

De aanbeveling die ik aan elke klant geef: maak minimaal drie monitors. Eén per lineaire dimensie: AWS Services (alle services), Linked Accounts (voor Organizations users), en Cost Category gebaseerd op je tagging-strategie. Zie mijn eerdere gids over de FinOps tagging strategie voor cost allocation voor de tags-set die dit werkbaar maakt.

Hieronder een Terraform-configuratie voor productiegebruik. Let op de threshold_expression: alleen alerts sturen als de anomaly zowel absoluut ($100) als procentueel (40%) significant is. Dit filtert ruis van kleine services zoals Route53.

resource "aws_ce_anomaly_monitor" "services" {
  name              = "services-monitor"
  monitor_type      = "DIMENSIONAL"
  monitor_dimension = "SERVICE"
}

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

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

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

De IMMEDIATE frequency zorgt dat je binnen 24 uur na detectie een SNS-bericht krijgt. Kies DAILY of WEEKLY voor samengevoegde rapportages als je team overspoeld wordt door alerts. In de praktijk stuur ik altijd immediate voor productie-accounts en weekly voor development.

Azure Cost Management anomaly alerts configureren

Azure Cost Management biedt sinds oktober 2024 een ML-gebaseerde anomaly detection feature naast de traditionele budget-alerts. De feature draait automatisch op elke subscription (je hoeft geen model te trainen), maar alerts moeten expliciet worden geactiveerd via een scheduled action of via de Cost Management REST API.

Om anomaly alerts programmatisch in te richten, gebruik je een scheduled action die dagelijks de anomaly API pollt en resultaten naar een webhook stuurt. Hier is een Bicep-template voor een subscription-scope anomaly alert:

resource anomalyAlert 'Microsoft.CostManagement/scheduledActions@2023-11-01' = {
  name: 'daily-anomaly-check'
  kind: 'InsightAlert'
  properties: {
    displayName: 'Daily Cost Anomaly Alert'
    status: 'Enabled'
    notification: {
      to: ['[email protected]']
      subject: 'Kostenafwijking gedetecteerd in ${subscription().displayName}'
    }
    schedule: {
      frequency: 'Daily'
      hourOfDay: 8
      daysOfWeek: ['Monday','Tuesday','Wednesday','Thursday','Friday']
      startDate: '2026-07-05'
      endDate: '2027-07-05'
    }
    viewId: '/providers/Microsoft.CostManagement/views/ms:DailyAnomalyByResourceGroup'
  }
}

De ms:DailyAnomalyByResourceGroup view is een ingebouwde system view die Microsoft in november 2024 beschikbaar maakte. Het model gebruikt exponential smoothing met seasonal decomposition, wat het gevoelig maakt voor weekend/weekdag patronen. Dat is belangrijk voor teams die veel batch workloads op zondagavond draaien.

Belangrijk verschil met AWS: Azure's anomaly signal is nog niet uit te lezen via een dedicated event grid topic. Wil je low-latency alerts richting Teams of PagerDuty, dan is een tussenlaag met Azure Functions plus de Query Anomalies API vereist. Ik werk meestal met een timer-triggered Function die elke drie uur draait. Real-time is overkill voor cost data die met 24 uur vertraging binnenkomt.

GCP budget alerts en Recommender API

Google Cloud heeft geen dedicated "anomaly detection" service in de trant van AWS. In plaats daarvan combineer je twee mechanismen: Budget alerts met percentage-thresholds op forecasted spend, en de Recommender API die actionable insights levert over idle resources, oversized instances en committed use discounts. Voor sommige klanten voel ik nog steeds pijn hierover, want het is minder elegant dan de AWS-oplossing, maar het werkt goed als je het correct configureert.

De truc is om budget-alerts niet op absolute bedragen te zetten, maar op forecasted spend met een 100%+ threshold. Zo geeft Google de melding "Your project is forecasted to exceed the budget by X%", effectief een anomaly signal. Hier een Terraform-voorbeeld dat een budget met pub/sub notificatie aanmaakt:

resource "google_billing_budget" "production_forecast" {
  billing_account = var.billing_account_id
  display_name    = "Production Forecast Anomaly"

  budget_filter {
    projects = ["projects/${var.project_number}"]
    labels   = { environment = "production" }
  }

  amount {
    specified_amount {
      currency_code = "EUR"
      units         = "10000"
    }
  }

  threshold_rules {
    threshold_percent = 1.0
    spend_basis       = "FORECASTED_SPEND"
  }

  threshold_rules {
    threshold_percent = 1.25
    spend_basis       = "FORECASTED_SPEND"
  }

  all_updates_rule {
    pubsub_topic                     = google_pubsub_topic.budget_alerts.id
    disable_default_iam_recipients   = false
  }
}

Combineer dit met een dagelijkse Cloud Scheduler job die de Recommender API aanroept voor idle VM's en unused persistent disks. Voor onze Nederlandse klanten die BigQuery-heavy zijn: vergeet de google.bigquery.capacity.CommitmentRecommender niet, die identificeert overprovisioned slot reservations die vaak duizenden euro's per maand kosten.

Alerts routeren naar Slack en PagerDuty

Een alert die alleen naar een gedeelde mailbox gaat is verloren geld. In mijn ervaring is de mediane time-to-acknowledge voor cost anomaly emails 3 tot 5 dagen, vaak nadat het probleem zichzelf al heeft opgelost of erger is geworden. Route alerts naar een dedicated Slack-kanaal of PagerDuty schedule, en behandel high-impact anomalies (>€500/dag) als een P3-incident.

Voor AWS is de eenvoudigste route: SNS topic → Lambda → Slack Incoming Webhook. De Lambda verrijkt het bericht met Cost Explorer context (welke resource, welke tag, welke regio) voordat het naar Slack gaat. Hier een minimale Python-implementatie:

import json
import os
import urllib.request

SLACK_WEBHOOK = os.environ["SLACK_WEBHOOK_URL"]

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

        payload = {
            "text": f":warning: Cost anomaly: *${impact:.2f}* op {service} in {region}",
            "blocks": [{
                "type": "section",
                "text": {"type": "mrkdwn", "text":
                    f"*Impact:* ${impact:.2f}\n"
                    f"*Service:* {service}\n"
                    f"*Regio:* {region}\n"
                    f"*Account:* {msg['accountName']}\n"
                    f"<{msg['anomalyDetailsLink']}|Bekijk in Cost Explorer>"
                }
            }]
        }
        req = urllib.request.Request(
            SLACK_WEBHOOK,
            data=json.dumps(payload).encode(),
            headers={"Content-Type": "application/json"}
        )
        urllib.request.urlopen(req, timeout=5)
    return {"statusCode": 200}

Voor PagerDuty werkt hetzelfde patroon met een Events API v2 payload in plaats van een Slack webhook. Belangrijk: zet de dedup_key gelijk aan de anomaly monitor ARN plus datum, anders krijg je duplicate incidents als er meerdere dagen achtereen een afwijking blijft.

Root cause analyse in de praktijk

Een alert vertelt je dát je kosten stijgen, niet waarom. Root cause analysis (RCA) is 80% van het echte werk. De workflow die ik teams laat implementeren volgt drie stappen: (1) isoleer de dimensie (service, account, regio, tag), (2) identificeer de resource, (3) vind de code- of configuratie-verandering die het triggerde.

Voor stap 1 en 2 gebruik ik CUR-data (Cost and Usage Report) in Athena. Een query die me talloze keren heeft gered, deze toont de top-10 resources die het meest zijn gegroeid tussen gisteren en de afgelopen 7-daagse baseline:

WITH baseline AS (
  SELECT
    line_item_resource_id,
    line_item_usage_account_id,
    AVG(line_item_unblended_cost) AS avg_cost
  FROM cur_report
  WHERE line_item_usage_start_date >= current_date - INTERVAL '8' DAY
    AND line_item_usage_start_date <  current_date - INTERVAL '1' DAY
  GROUP BY 1, 2
),
yesterday AS (
  SELECT
    line_item_resource_id,
    line_item_usage_account_id,
    SUM(line_item_unblended_cost) AS day_cost
  FROM cur_report
  WHERE line_item_usage_start_date >= current_date - INTERVAL '1' DAY
    AND line_item_usage_start_date <  current_date
  GROUP BY 1, 2
)
SELECT
  y.line_item_resource_id,
  y.line_item_usage_account_id,
  b.avg_cost,
  y.day_cost,
  y.day_cost - b.avg_cost AS delta,
  ROUND((y.day_cost - b.avg_cost) / NULLIF(b.avg_cost, 0) * 100, 1) AS pct_change
FROM yesterday y
LEFT JOIN baseline b USING (line_item_resource_id, line_item_usage_account_id)
WHERE y.day_cost - COALESCE(b.avg_cost, 0) > 50
ORDER BY delta DESC
LIMIT 10;

Voor stap 3 correleer ik het tijdstip van de spike met CloudTrail events en de git-log van je infrastructure-as-code repo. Als een nieuwe c6i.4xlarge instance twee uur na een Terraform apply verscheen, heb je je root cause. Voor Kubernetes-workloads is Kubernetes kosten optimalisatie een parallelle discipline. Anomaly detection in de node group vertelt je zelden waar in de cluster het lek zit; daarvoor heb je Kubecost of OpenCost data nodig.

Hoe verminder je false positives?

False positives zijn de sluipmoordenaar van elk anomaly detection programma. De typische oorzaken zijn: (1) legitieme business seasonality zoals Black Friday of end-of-quarter batch loads, (2) een nieuwe workload die net gelanceerd is, en (3) reserved instance charges die op de eerste van de maand geboekt worden. Elk hiervan vereist een specifieke tegemaatregel.

Voor seasonality: label bekende terugkerende events in je cost management tool en train je model met minstens 90 dagen historie zodat het weekend- en maandpatronen leert. Voor nieuwe workloads: gebruik cost categories om nieuwe services de eerste 30 dagen uit te sluiten van alerting. Voor RI-charges: filter line_item_line_item_type = 'RIFee' uit je detection scope. Deze zijn per definitie afwijkend maar volledig verwacht.

Een concrete techniek die goed werkt is tweetrapsdetectie. Een eerste-lijns alert gaat naar een lage-prioriteit kanaal. Alleen als de anomalie 48 uur aanhoudt of >€1000/dag impact heeft, escaleert het naar PagerDuty. In een van mijn engagements bij een SaaS-bedrijf reduceerde dit de alert volume van gemiddeld 14 per week naar 2 per week, met nul gemiste incidents in Q1 2026. Combineer dit ook met de Reserved Instances vs Savings Plans analyse, want commitment-based charges vertekenen anders je baseline.

Anomaly detection vs budget alerts: het verschil

Budget alerts en anomaly detection lossen verschillende problemen op en vullen elkaar aan. Onderstaande tabel vat de verschillen samen die ik het vaakst bespreek in FinOps sessies:

Aspect	Budget alerts	Anomaly detection
Detectiemechanisme	Statische of forecasted threshold	ML-baseline vs actuele spend
Configuratie-effort	Laag: bedrag + percentage	Gemiddeld: monitors + subscriptions
False positive rate	Laag (deterministisch)	Middel (afhankelijk van workload variabiliteit)
Detectiesnelheid	Alleen wanneer threshold overschreden	Binnen 24 uur na afwijking
Vereiste historie	Geen	10 tot 30 dagen
Gebruikstijd	Governance, budget tracking	Vroege detectie van misconfigs, DDoS, runaway jobs
Kosten	Gratis in alle drie clouds	Gratis (AWS, Azure); indirect via Recommender (GCP)

Eerlijk gezegd: gebruik ze allebei. Budget alerts voor finance-gedreven governance (kwartaalbudgetten, cost center caps) en anomaly detection voor operational incidents. De twee mechanismen sturen naar verschillende teams. Finance krijgt budget alerts, engineering krijgt anomaly alerts. Een engineer wil niet elke maandag horen dat het budget op 60% zit; die wil weten dat er gisteren voor $2000 aan extra EC2 draaide.

Veelgestelde vragen

Wat is het verschil tussen AWS Cost Anomaly Detection en AWS Budgets?

AWS Budgets gebruikt vaste of forecasted thresholds die jij definieert (bijv. "alert bij 80% van $10.000"), terwijl Cost Anomaly Detection een ML-model traint op je historische patronen en automatisch afwijkingen signaleert zonder dat je een drempel hoeft in te stellen. Beide zijn gratis en vullen elkaar aan.

Hoeveel kost cloud cost anomaly detection?

De native services van AWS en Azure zijn volledig gratis. GCP heeft geen dedicated anomaly service, maar budget alerts zijn gratis en de Recommender API kost niets extra. Third-party tools zoals CloudZero of Vantage rekenen typisch 2 tot 5% van je cloud spend, of een vast maandtarief vanaf €500/maand.

Hoe snel detecteert AWS Cost Anomaly Detection een spike?

AWS Cost Anomaly Detection verwerkt kostendata met een lag van ongeveer 24 uur. Zodra een afwijking wordt vastgesteld, wordt de alert onmiddellijk verzonden bij een IMMEDIATE subscription. Effectief detecteer je een spike dus binnen 24 tot 36 uur na het optreden.

Kan ik anomaly detection instellen voor Kubernetes workloads?

Op cloud-niveau detecteer je alleen node group kosten. Voor pod-level anomaly detection heb je Kubecost, OpenCost of een vergelijkbare tool nodig die kube-state-metrics correleert met billing data. Combineer beide voor volledige zichtbaarheid.

Wat doe ik als ik te veel false positive alerts krijg?

Verhoog de threshold_expression naar minimaal $100 én 40% afwijking, sluit nieuwe workloads de eerste 30 dagen uit, en gebruik tweetrapsdetectie waarbij alleen 48-uur aanhoudende anomalies escaleren naar PagerDuty. Train je model bovendien op minimaal 30 dagen historie om weekend- en maandpatronen te leren.