Cloud Cost Anomaly Detection: AWS Cost Anomaly Detection and a DIY Query

Last verified on Nov 8, 2026.

A cloud bill is a lagging, summarized version of what your systems did. When data transfer doubles overnight or a runaway job fills a queue, you learn about it from an invoice weeks later unless something watches the daily numbers. The fix is cheap: compare each service's spend with its recent history every day and look at the biggest movers.

You have two layers to use. Your provider's own anomaly feature is the quick start. A query over your billing export is the layer you control.

Start with the provider feature

AWS Cost Anomaly Detection uses machine learning models on your spend and, per the AWS docs, accounts for weekly or monthly seasonality and natural growth to limit false positives. You set up cost monitors that define what to track, then attach alert subscriptions that notify people by email or an Amazon SNS topic. AWS managed monitors can track costs across accounts without manual setup. Root causes are ranked by dollar impact across four dimensions: service, account, Region and usage type.

Know its limits. It runs about three times a day on data from Cost Explorer, so it can take up to 24 hours to detect an anomaly after the usage occurs. A new service needs 10 days of history before anomalies can be detected for it. Google Cloud and Azure have equivalents: Google Cloud reports spikes or deviations against historical spend, and Azure Cost Management offers anomaly detection for subscriptions in cost analysis.

What the evidence looks like

In the line items, one product and usage type jumps while the rest stay flat. This example shows daily cost for one usage type:

day         product        usage_type             cost_usd
2026-11-05  AmazonEC2      DataTransfer-Out-Bytes     212.40
2026-11-06  AmazonEC2      DataTransfer-Out-Bytes     205.15
2026-11-07  AmazonEC2      DataTransfer-Out-Bytes     431.90

Usage type is the most useful column, because it names what you are paying for.

How to detect it yourself

1. Turn on a billing export with line items. AWS Cost and Usage Reports hold a line item for each unique combination of product, usage type and operation and can be aggregated hourly or daily.
2. Load it into a table you can query, then group by day, product and usage type.
3. Compare each day with the median of the previous 14 days for the same weekday.

WITH daily AS (
  SELECT date_trunc('day', line_item_usage_start_date) AS day,
         line_item_product_code AS product,
         line_item_usage_type   AS usage_type,
         sum(line_item_unblended_cost) AS cost
  FROM cur
  WHERE line_item_usage_start_date >= current_date - interval '30 days'
  GROUP BY 1, 2, 3
), scored AS (
  SELECT d.*,
         percentile_cont(0.5) WITHIN GROUP (ORDER BY h.cost) AS typical
  FROM daily d
  JOIN daily h
    ON h.product = d.product AND h.usage_type = d.usage_type
   AND h.day < d.day AND h.day >= d.day - interval '14 days'
   AND extract(dow FROM h.day) = extract(dow FROM d.day)
  WHERE d.day = current_date - 1
  GROUP BY d.day, d.product, d.usage_type, d.cost
)
SELECT product, usage_type, cost, typical, cost - typical AS delta
FROM scored
WHERE cost > 2 * typical AND cost - typical > 50
ORDER BY delta DESC;

Run it each morning against the previous full day. For faster signals, use the hourly export with the same shape and a smaller window.

Join the result to context. Tag or account allocation tells you which team owns the spend. A deploy log tells you what changed. Your request metrics tell you whether traffic grew with it.

Thresholds and pitfalls

Use a relative multiple together with an absolute dollar floor. The floor stops a $0.40 line from alerting when it becomes $1.20. Choose it from what your team would act on, not from a percentage.

Things that cause false alarms:

• Unfinished days. Billing data arrives with a delay, so judge the last complete day and not today.
• Credits, refunds and commitment discounts. They change cost without a change in usage. Check the usage amount column next to the cost before you chase a jump.
• Month boundaries. One-time and monthly charges land on the first of the month. Exclude them or compare month to month.
• Real growth. A launch should raise spend. Compare against a driver such as requests or active users to see cost per unit, which is steadier than raw cost.
• New resources. A brand-new product has no history, so give it a fixed ceiling alert for its first weeks.

What to do when it fires

Drill from service to usage type to account to Region to resource, which matches how AWS ranks root causes. Then ask what changed. A retry loop, a debug log level left on or a batch job pointed at the wrong bucket can each double a line. Stop the source first, then fix it. Add a budget or alert on the specific usage type so you hear about a repeat in hours.

Related guides: cost anomalies covers spend across other vendors, LLM spend spikes covers model usage and cardinality jumps covers a common cause of an observability bill that suddenly grows. Infrastructure changes are the usual suspect, and the Terraform page covers connecting its CLI. For AWS-side logs, see the AWS page, and the integrations list covers other providers.