AWS Cost Anomaly Detection: the complete guide

What AWS Cost Anomaly Detection is

AWS Cost Anomaly Detection is a free feature of AWS Cost Management. It learns the normal daily spend pattern of each thing you ask it to watch, flags a day whose spend is well outside that pattern, and sends an alert. There is no threshold to invent: the model builds the expectation from your own history and adjusts as your spend grows, including weekly and seasonal patterns.

Three facts shape everything else in this guide:

• It is free. Monitors, alert subscriptions and root-cause analysis carry no charge. The only prerequisite is that Cost Explorer is enabled on the account, which is also free (only API calls to Cost Explorer are billed).
• It is not real time. Monitors evaluate roughly three times a day, as billing data lands. A spike that starts at 9 am is normally flagged the same day or the next morning, not within the hour.
• It sees the dimensions of your bill, not your resources. It can tell you that EC2 in account 1234 rose by $800 against an expected $2,100. It cannot name the instance, the Auto Scaling group or the person who deployed it.

Used well, it is the safety net that catches the surprises before the invoice does. Used as a black box with the defaults, it produces alerts nobody reads. The rest of this guide is about the difference.

Why AWS bills spike in the first place

Across the payer accounts we watch, the same handful of causes explain almost every anomaly worth acting on:

• Auto Scaling that scaled and never came back: a scaling policy fires on a bad metric, or a minimum was raised for a launch and never lowered.
• Orphaned resources: unattached EBS volumes, old snapshots, load balancers and NAT gateways left behind by a teardown that missed a step.
• Accidental deployments and test runs at production scale: a job pointed at the wrong environment, a load test left running, an infinite Lambda loop.
• Data transfer: cross-AZ or cross-region traffic introduced by a topology change, or a public endpoint that used to be private.
• API and request volume: S3, DynamoDB or CloudWatch calls from a new client, a retry storm, or logging turned up to debug.
• Spot interruptions falling back to on-demand: the fleet keeps running, at two to five times the price.
• Security incidents: crypto-mining on a compromised key is still the most expensive version of "unusual spend".

One cause looks like an anomaly and is not: tiered pricing resetting on the first of the month. Services such as GuardDuty, CloudWatch and S3 requests charge a higher rate for the first units each month and a lower rate after a threshold. On the 1st, the rate jumps back to the top tier, spend per unit rises by as much as 95 percent, and every anomaly detector on the market flags it. Usage has not changed. If your alerts cluster on the 1st and 2nd, check the rate before the resource.

How the service works: monitors, baselines and dimensions

You create monitors. Each monitor watches one dimension and builds a separate baseline for every value in that dimension:

• AWS services: one baseline per service per account. This is the monitor everyone should have; it is the only kind a member account can create on its own.
• Linked accounts: one baseline per account in the organization.
• Cost allocation tags: one baseline per value of a tag key, for example every value of Team.
• Cost categories: one baseline per category value, for example every business unit you defined in Cost Categories.

Before November 2025, the account, tag and category dimensions were custom monitors: you listed the values to watch, and you had to add new accounts or new tag values by hand. The limit is one service monitor plus 500 custom monitors per account (Cost Management quotas). That is fine for a ten-account organization and unmanageable for a three-hundred-account one.

AWS managed monitors: the November 2025 change

In November 2025 AWS extended managed monitors, previously available only for the services dimension, to linked accounts, cost allocation tags and cost categories. A managed monitor tracks every value in its dimension automatically, up to the top 5,000 values by cost, and picks up new accounts, new tag values or new category values as soon as they start incurring cost. Each value gets its own baseline; one alert threshold applies across them.

What that means in practice:

• A management account can create one managed services monitor plus one managed monitor for linked accounts, or tags, or cost categories. Choose the dimension that matches how you assign ownership. Member accounts can only create the managed services monitor.
• A new team that starts tagging Team=ai is monitored from its first dollar. Nobody edits a monitor when the org chart changes.
• The single shared threshold is the trade-off. A $200 spike matters to a team spending $1,000 a month and is noise to one spending $80,000. Keep custom monitors for the few teams that need their own threshold, and let the managed monitor cover the long tail.

Our advice for anyone migrating: create the managed monitor, keep the existing custom monitors running in parallel for a month, compare what each catches, then retire the custom ones you no longer need. The managed monitors deep dive has console screenshots and the CLI calls for each dimension.

Step-by-step setup

The whole thing takes fifteen minutes in the management account.

1. Enable Cost Explorer (Billing and Cost Management → Cost Explorer). If it is already on, skip.
2. Create the services monitor. Cost Anomaly Detection → Cost monitors → Create monitor → AWS services. It is the baseline safety net for every service in every account.
3. Create one managed monitor for your ownership dimension. Create monitor → choose "Managed by AWS" → Linked accounts, or Cost allocation tags (pick the tag key, for example Team), or Cost categories (pick the category). If you have not decided how ownership works in your organization, read the cost allocation guide first; the monitor is only as good as the tags or categories behind it.
4. Create alert subscriptions. A subscription decides who is told, how often, and above what impact. Name it after the audience ("FinOps weekly", "Platform team, immediate"). Frequency is individual alerts (as each anomaly is found, best for the people who will act), daily summary or weekly summary (for finance and leadership). Recipients: up to ten email addresses, which must confirm the Amazon SNS subscription email, or an SNS topic, which is how you reach Slack, Microsoft Teams, a ticketing system or a Lambda function.
5. Set the threshold. A subscription only alerts on anomalies whose impact passes the threshold. You can use an absolute amount, a percentage above expected spend, or both with AND / OR. Our default for a new subscription is impact of at least $100 AND at least 40 percent above expected: the dollar floor stops small accounts from paging you over $12, the percentage stops a large account from paging you over ordinary variance. Tune it after 30 to 45 days of alerts.
6. Link the subscription to the monitors it should cover and create it. Confirm the SNS emails. The first results appear within about 24 hours; the model wants a couple of weeks of history before it is confident about a new value.

For the CLI, a managed tag monitor is one call:

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

Replace TAG with LINKED_ACCOUNT (no specification needed) or COST_CATEGORY (with "CostCategories": { "Key": "BusinessUnit" }) for the other dimensions; the field reference is in the CreateAnomalyMonitor API documentation. The setup deep dive walks through every field of the subscription form with screenshots.

Designing alerts people will act on

The failure mode is not missing anomalies. It is an inbox full of anomalies that nobody owns. Three rules fix most of it:

• One subscription per audience, not per monitor. Engineers get individual alerts for their own dimension value through SNS into their channel. Finance gets a daily or weekly summary. Nobody gets everything.
• Route by ownership, not by service. If your managed monitor is on Team, the alert already names the team. Use SNS plus a small Lambda, or Amazon Q Developer in chat applications (the service formerly called AWS Chatbot), to post it into that team's channel rather than a shared one.
• Budgets for limits, anomaly detection for surprises. AWS Budgets alerts when spend crosses a line you set; anomaly detection alerts when spend leaves the pattern, with no spend limit to maintain. You want both. A budget catches slow drift that never looks anomalous on any single day; anomaly detection catches the one-day spike that is still under budget.

The ten minutes after an alert

An alert is a question, not an answer. The routine we run:

1. Open the anomaly in the console. The detail view shows the total impact against expected spend and the root causes the service can see: the top contributing service, account, region and usage type. That is usually enough to know which team to ask.
2. Check the date. First or second of the month, or a weekday after a holiday: check tiered pricing and calendar effects before anything else.
3. Find the resource. Cost Explorer with the usage type and account filter, grouped by resource for the last 14 days (resource-level data is available for EC2 in Cost Explorer; for everything else, the Cost and Usage Report or a tool that works from it). This is the step the AWS service cannot do for you.
4. Ask the owner whether it was expected. A launch, a migration or a load test is a legitimate spike. Mark the anomaly's assessment in the console ("expected" or "not an issue") so the model learns and the record shows a decision was made.
5. Fix and confirm. Stop or right-size the resource, then watch the next two days' spend. The anomaly is closed when the bill returns to the pattern, not when the ticket does.

Automated remediation is possible (SNS → Lambda that stops tagged non-production instances, or an EventBridge rule on the anomaly event) and worth doing for the narrow cases you have already seen twice. Do not automate stopping things you have not diagnosed once by hand.

Tags and cost categories are the backbone

Every useful anomaly alert ends with a name: the team, application or environment that owns the spend. The AWS service can only give you that name if the resource carries it, either as a cost allocation tag or through a Cost Category rule. Untagged spend is detected, but it is attributed to nobody, and it is the spend most likely to be waste. Before you rely on a tag-based monitor, measure how much of your bill actually carries the tag; below 80 percent, fix tagging first or use the linked-account dimension instead. The cost categories guide shows how to build categories that map accounts and tags to business units, which is the dimension most organizations end up monitoring.

What AWS Cost Anomaly Detection does not do

	AWS Cost Anomaly Detection	Resource-level tools (for example TruCost.Cloud)
Granularity	Service, account, tag or cost category	The instance, table, bucket or endpoint that caused the change
Ownership	Alert goes to a list	Alert routed to the resource's owner, with a ticket if wanted
Explanation	Top contributing service, account, region, usage type	What changed on the resource: usage, price tier, new deployment
Response tracking	None beyond the assessment field	Open, assigned, resolved, with the saving checked against the next bill
Timing	About three evaluations a day	Same data cadence (from the Cost and Usage Report), hourly on services that report hourly
Cost	Free	Part of a paid platform

AWS's own Cost Anomaly Detection FAQ is candid about the scope: monitors, alerts and root-cause analysis by the dimensions of the bill. The honest summary from the FinOps best-practices article: the AWS service is enough to tell you that EC2 spend jumped 30 percent this week, and not enough to tell you which instance, Auto Scaling group or forgotten dev environment did it. The gap is the investigation time, which is where the money actually goes.

How TruCost.Cloud handles anomalies

TruCost.Cloud works from the Cost and Usage Report, so it sees the same spend the AWS service sees but at the resource. Each finding names the resource, what changed on it (usage, price tier, a new deployment), and the owner it belongs to under your allocation rules, and it is routed to that owner with an optional Jira ticket. Every finding has a status (open, assigned, resolved, or suppressed when the spike was expected) and the saving from a fix is checked against the following bill rather than estimated. The sensible setup is both: AWS's managed monitors as the free organization-wide net, and resource-level detection on the accounts where a spike has to be fixed the same day. See Anomaly Radar on the platform page.

Common questions

Is AWS Cost Anomaly Detection free?

Yes. There is no charge for monitors, alert subscriptions or root-cause analysis. It requires Cost Explorer to be enabled, which is free; only programmatic Cost Explorer API calls are billed.

How quickly does it detect a spike?

Monitors evaluate roughly three times a day as billing data arrives, so a spike is typically flagged the same day or the next morning. It is not real-time monitoring.

What is the difference between AWS Budgets and Cost Anomaly Detection?

Budgets alert when spend crosses a threshold you set. Anomaly detection alerts when spend deviates from the pattern it has learned, with no spend limit to maintain. Use Budgets for limits and slow drift, anomaly detection for surprises.

What changed with AWS managed monitors in November 2025?

Managed monitors, previously available only for AWS services, now cover linked accounts, cost allocation tags and cost categories. One managed monitor tracks every value in its dimension automatically (up to the top 5,000 by cost) and includes new accounts, tag values or category values as they appear. A management account can have one managed services monitor plus one managed monitor for accounts, tags or categories.

Can member accounts use managed monitors?

Member accounts can create the AWS services managed monitor only. Monitors for linked accounts, cost allocation tags and cost categories are created in the management account.

What alert threshold should I start with?

A combined threshold: impact of at least $100 and at least 40 percent above expected spend. The dollar floor keeps small accounts quiet, the percentage keeps large accounts from alerting on normal variance. Review after 30 to 45 days and adjust per subscription.

Can it tell me which resource caused the anomaly?

No. Root-cause analysis shows the top contributing service, account, region and usage type. Finding the specific instance, table or bucket needs Cost Explorer resource-level views (EC2 only) or a tool that works from the Cost and Usage Report.

Why do I get anomalies on the first of every month?

Tiered pricing. Services such as GuardDuty, CloudWatch and S3 requests charge a higher rate for the first units each month, so the rate jumps back to the top tier on the 1st and spend per unit rises even though usage is flat. Check the rate before you investigate the resource.