Will AWS Cost Anomaly Detection catch a runaway bill in time?

How the detection engine processes your spend

AWS Cost Anomaly Detection evaluates net unblended cost data, which represents your net costs after AWS calculates all applicable discounts. It doesn't look at live API calls, active EC2 runtimes, or raw network packets. Instead, it waits for the AWS billing pipeline to ingest usage records, apply discounts, and publish the results into Cost Explorer.

Because Cost Explorer itself has a delay of up to 24 hours, the anomaly detection engine is always looking backward. When you create a new cost monitor, the system can take 24 hours just to begin detecting new anomalies. If you spin up a brand new service, the delay is even longer: AWS Cost Anomaly Detection requires 10 days of historical service usage data before anomalies can be detected for that service.

Once the pipeline processes your billing records, the service runs its machine learning models roughly three times a day. When it identifies an unexpected jump, it splits the root causes across four specific dimensions:

• AWS service
• AWS account
• Region
• Usage type

The root causes appear ranked by their dollar impact. Cost impact is calculated as actual spend minus expected spend. The console also provides an impact percentage, calculated as (total cost impact / expected spend) * 100. If your expected spend for a service was zero, the impact percentage displays as "N/A" because it cannot divide by zero.

Even if a spike stays below your configured alert threshold, the underlying machine learning model still logs it. Every detected event remains visible in the Detected anomalies tab, which displays the last 90 days of anomalies by default. You can also submit an assessment for any entry - marking it as Not submitted, Not an issue, or Accurate anomaly - to provide feedback on the detection model.

Choosing between AWS managed and customer managed monitors

To start monitoring spend, you must set up at least one cost monitor in the Billing and Cost Management console or via the AWS Cost Explorer API. You can create monitors by opening the Billing and Cost Management console, navigating to Cost Anomaly Detection, selecting the Cost monitors tab, and choosing Create monitor.

AWS divides monitors into two types: AWS managed monitors and customer managed monitors (which AWS previously called custom monitors).

AWS managed monitors

AWS managed monitors track up to 5,000 values within a chosen dimension. If your organization exceeds 5,000 values, the monitor automatically tracks the top 5,000 values based on total spend. These monitors evaluate each value independently across four supported dimensions:

• AWS services (automatically tracks all services in your account)
• Linked account (tracks all member accounts automatically)
• Cost allocation tag (tracks all values for a specified tag key)
• Cost category (tracks all values in a specified category)

The AWS services monitor is unique. It's available as an AWS managed monitor in both management and member accounts, but customer managed AWS services monitors aren't supported at all.

Customer managed monitors

Customer managed monitors let you evaluate specific values in aggregate rather than tracking thousands of resources independently. Under the customer managed method, you can select up to 10 specific values to monitor together. For example, a customer managed Linked Accounts monitor aggregates total spend across up to 10 manually selected member accounts. A customer managed Cost Categories monitor is narrower: it can track only one specific cost category value that you pick manually.

Keep in mind that you can only access cost monitors and alert subscriptions under the account that created them. If you want to monitor linked accounts, cost allocation tags, or cost categories, those monitors can only be created in the management account. You can attach up to 50 tags to any cost monitor or alert subscription.

Alert subscriptions, thresholds, and delivery channels

A monitor only tracks data; it won't notify you until you attach an alert subscription. In fact, you must create at least one alert subscription for each cost monitor you configure.

Each subscription supports two threshold types:

• Absolute thresholds: triggers when an anomaly's total cost impact exceeds a set dollar amount.
• Percentage thresholds: triggers when the total impact percentage exceeds your set limit, measuring the difference between total expected spend and total actual spend.

You can configure a second threshold on the same subscription by choosing Add threshold, joining them with either an AND or an OR operator. Alert subscriptions attached to AWS managed monitors apply that same threshold across all tracked values. If you need more granular alert routing based on specific values, AWS recommends configuring AWS User Notifications with JSON filtering patterns.

Notification frequency determines how quickly those alerts leave AWS:

Individual alerts

These notify you as soon as an anomaly is detected, and you might receive multiple alerts throughout the day. Individual alerts require an Amazon SNS topic. If your team lives in chat tools, you can map that SNS topic to a Slack channel or Amazon Chime chat room using an Amazon Q Developer in chat applications configuration.

Daily summaries

Daily summaries compile the top 10 alerts from the previous day sorted by cost impact into a single email notification. The system generates this email at 00:00 UTC daily, though delivery times vary. For example, if an anomaly is detected at 04:30 UTC on January 14, it won't appear in your inbox until the daily summary goes out at 00:00 UTC on January 15. That is a massive lag.

Weekly summaries

Weekly summaries send a single email per week covering anomalies that occurred across the prior seven days. Both daily and weekly summaries require at least one email recipient.

If an anomaly continues over multiple days, alert recipients continue to receive notifications as long as the spend meets your threshold.

Where Cost Anomaly Detection fails during a live incident

Cost Anomaly Detection has blind spots that catch developers off guard.

First, it does not monitor third-party products and services available through AWS Marketplace, with one single exception: third-party foundation models on Amazon Bedrock. If an engineer subscribes to a third-party SaaS contract or marketplace AMI that runs wild, this tool won't alert you. To track non-Bedrock marketplace charges, you have to use AWS Budgets with a Billing entity filter.

Second, the service isn't available for bill source accounts that use billing transfer, and it doesn't support billing transfer views.

The most dangerous limitation, though, is the batch processing delay. Why doesn't AWS Cost Explorer show today's spend yet? Because cloud billing pipelines batch usage files asynchronously. By the time Cost Anomaly Detection identifies an issue 24 hours later, an unthrottled Lambda function, an over-provisioned cluster, or an exposed credential could run up thousands of dollars.

It is impossible to build an automated emergency stop on a 24-hour feedback loop. For early warnings, you need to configure faster tools, as outlined in our guide on how to set up AWS billing alerts.

Pairing detection models with real-time controls

Because AWS Cost Anomaly Detection looks backward, small engineering teams treat it as a secondary audit log rather than a perimeter alarm. It answers the question: "Did we spend more last week than our baseline predicted?" It cannot answer: "Is our infrastructure running out of control right now?"

For live protection, you need tools that inspect live metrics alongside billing records. Costbrake monitors spend across 23 cloud, AI, and SaaS providers. On AWS it estimates Lambda, Bedrock, NAT gateway and GPU instance spend from CloudWatch hourly on the Free plan and every 5 minutes on Pro and Team (up to every minute during a spike), and re-reads Cost Explorer every 4 hours for the rest. Instead of waiting 24 hours for Cost Explorer, Costbrake reads billed costs while also pulling live CloudWatch metrics for Lambda requests and duration, Bedrock tokens per model, NAT gateway data processed, and running G, P, and Inf instance vCPUs.

When spend spikes, alerts reach email, Slack, Discord, webhooks, or PagerDuty long before daily billing files settle. When an emergency happens, Pro and Team plans provide an opt-in, human-confirmed killswitch called brakes. An admin can stop an EC2 instance, throttle a Lambda function to zero concurrency, turn off an IAM access key, or block Bedrock access within seconds - preventing runaway charges without waiting for AWS to notice the anomaly tomorrow. You can read more about options for stopping spend in our guide on setting a hard spending limit on AWS, or connect your infrastructure via agent setup.