Cloud cost anomaly detection for engineering and finance teams on AWS and Google Cloud

Cloud cost anomaly detection watches your daily spend and tells you when a service, account or project breaks its own pattern, usually within a day instead of at the end of the month. This post is for engineering and finance teams on AWS and Google Cloud: how detection works, how to set up the free native tools on both clouds, how to tune thresholds so people keep reading the alerts, and a simple routine for cloud spend monitoring.

If you’re already looking at a spike and want to know what caused it, start with the usual causes of a cloud bill spike instead. This post is about catching the next one early.

How cloud cost anomaly detection works

Every detector makes the same three choices.

1. What a series is. Spend is split into series, such as one per service, per account, per project or per team tag. Detection runs on each series separately, so a spike in one small service isn’t hidden by a large, steady total.
2. What normal looks like. Each series gets an expected value for each day, the baseline. It can be a trailing average, the median of the same weekday over recent weeks, or a machine learning model.
3. How far from normal counts. A day is flagged when actual spend exceeds the baseline by more than a threshold.

The threshold needs two parts. A relative one alone flags noise: a service that goes from $3 to $6 a day doubled, and nobody should be paged for it. An absolute one alone misses what matters on small series and floods you on large ones, where $500 above typical might be a normal Tuesday. Requiring both, such as “at least $100 and at least 20% above expected”, keeps the alerts that are worth reading.

When a deviation lasts several days, a good detector reports one anomaly with a start date and a running total, not one alert per day. The start date is what you need for the investigation.

Seasonality, growth and false positives

Most false positives come from patterns the baseline didn’t account for.

• Weekly cycles. Dev environments that stop at weekends, batch jobs that run on Mondays. A trailing seven-day average makes every Monday look like a spike. Comparing each day with the same weekday in earlier weeks fixes that.
• Monthly charges. Some charges land once a month. A detector that sees the 1st of each month as an anomaly needs a longer memory, or those charges excluded.
• Growth. A product that grows 5% a month grows its bill too. A baseline that never adapts turns growth into a stream of alerts.
• Planned events. Launches, load tests, migrations and backfills are real deviations that nobody needs to be told about. Mark them as expected so the next review doesn’t chase them again.

False negatives matter as much. A slow leak, such as snapshots or logs piling up a little more each day, may never break a daily threshold. That’s what budgets and forecasts are for, covered below.

Set up AWS Cost Anomaly Detection

AWS Cost Anomaly Detection is free (AWS). It uses machine learning that accounts for weekly or monthly seasonality and natural growth, runs about three times a day, can take up to 24 hours to flag an AWS billing anomaly after the usage happens, and needs 10 days of history before it can detect anomalies for a new service. Each anomaly comes with root causes ranked by dollar impact across service, account, Region and usage type (AWS docs).

You set it up in two parts: a monitor that defines what to watch, and an alert subscription that defines who hears about it. An AWS managed monitor tracks up to 5,000 values of one dimension independently: every service, every member account, every value of a cost allocation tag, or every value of a cost category. An account gets one AWS managed monitor for services, and a management account can add one more for linked accounts, a tag or a cost category (AWS quotas).

AWS has created a services monitor automatically for new Cost Explorer users since March 2023 (AWS), so list what exists first. This only reads:

aws ce get-anomaly-monitors \
  --query 'AnomalyMonitors[].[MonitorName, MonitorType, MonitorDimension, MonitorArn]' \
  --output table

If your teams tag resources, a managed monitor on the team tag gives each team its own baseline. Run it in the management account; it creates configuration only, nothing that bills:

aws ce create-anomaly-monitor --anomaly-monitor \
  '{"MonitorName":"by-team","MonitorType":"DIMENSIONAL","MonitorDimension":"TAG","MonitorSpecification":{"Tags":{"Key":"team"}}}'

Then subscribe people to it. Frequency DAILY or WEEKLY sends an email summary to up to 10 addresses; IMMEDIATE sends each anomaly to an SNS topic, which can forward to Slack. Thresholds can be absolute, percentage, or both joined with And or Or (AWS docs):

aws ce create-anomaly-subscription --anomaly-subscription '{
  "SubscriptionName": "daily-cost-anomalies",
  "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/your-monitor-id"],
  "Subscribers": [{"Type": "EMAIL", "Address": "[email protected]"}],
  "Frequency": "DAILY",
  "ThresholdExpression": {"And": [
    {"Dimensions": {"Key": "ANOMALY_TOTAL_IMPACT_ABSOLUTE", "MatchOptions": ["GREATER_THAN_OR_EQUAL"], "Values": ["100"]}},
    {"Dimensions": {"Key": "ANOMALY_TOTAL_IMPACT_PERCENTAGE", "MatchOptions": ["GREATER_THAN_OR_EQUAL"], "Values": ["20"]}}
  ]}
}'

Anomalies below the threshold are still detected and listed; they just don’t send an alert. To review the last month from the terminal:

aws ce get-anomalies \
  --date-interval StartDate=2026-09-12,EndDate=2026-10-12 \
  --query 'Anomalies[].[AnomalyStartDate, DimensionValue, Impact.TotalImpact, RootCauses[0].UsageType]' \
  --output table

Know what it doesn’t watch. It analyzes only the Usage charge type, and it skips AWS Marketplace (except third-party models on Amazon Bedrock), AWS Support, WorkSpaces, Route 53, Shield, Certificate Manager, Cost Explorer and Budgets (AWS quotas).

Set up Google Cloud anomaly detection

Google Cloud’s anomaly detection is built into Cloud Billing and became generally available on October 30, 2025 (release notes). Google describes it as needing no setup and costing nothing (Google Cloud blog). It compares the spend of each project in a billing account with its historical patterns and lists the deviations on the Anomalies page of the Billing console.

Each anomaly has a root cause panel with the top services, regions and SKUs behind the spike. Two thresholds decide what counts: a cost impact in your billing account’s currency and a deviation percentage. Both are set automatically from your usage patterns and updated daily, and you can override them on the Manage anomalies page. By default, billing account administrators get an email for every anomaly; you can add essential contacts or project owners, or send anomalies to Pub/Sub to route them into chat or a ticket queue (Google Cloud docs).

Two practical notes. Google suggests watching anomalies for at least a month before setting one threshold across all projects. And since July 2026, a Preview feature adds early anomalies for some AI services, including the Gemini API and Cloud Run, based on near real-time cost estimates; your own thresholds don’t apply to those (release notes).

Anomaly detection and budgets do different jobs

A budget compares the month’s running total, or its forecast, with a number you chose. An anomaly detector compares each day with that series’ own past. A budget catches the slow leak and the month that ends too high. Anomaly detection catches the sudden change on the 3rd of the month, while the total is still far below budget.

Use both. Budgets with forecast alerts on each account or project, and anomaly detection on services and teams. The cloud budget alerts guide covers the budget side.

A cloud spend monitoring routine that sticks

Alerts only help if someone acts on them. A routine for a small team:

Tune thresholds from what happened. If people start ignoring the alerts, raise the absolute threshold. If a spike reached the invoice unannounced, lower it or add a monitor on the dimension that would have caught it. Record your verdicts: AWS lets you mark an anomaly as accurate or not an issue, and Google takes feedback on its anomalies too.

Ownership makes all of this faster. An anomaly on a service tagged team=payments goes straight to the payments team; one on untagged spend goes to whoever has time. Cost allocation by team explains how to get the tags in place.

How Omni FinOps detects anomalies

Omni FinOps uses plain rules rather than a model, so you can predict exactly when it fires. It splits daily cost into one series per account and service, and compares each day with the median of the same weekday over the four weeks before, so a Monday is measured against Mondays. A day is flagged when it runs more than $25 and more than 40% above that baseline. Following days that stay more than $15 and 25% above it join the same episode, so a lasting step is one anomaly, not one per day. A service that cost under $1 over the previous 28 days and more than $2 today is reported once as new spend. Severity is High at $900 or more above baseline, or at three times the baseline. Each anomaly names the regions and the resources whose cost rose during it, in one sentence, and moves through statuses (open, investigating, resolved, silenced, dismissed) with a comment on every change. Spend anomaly alerts go out by email. It reads cost through read-only access on AWS and Google Cloud and changes nothing.