Skip to content

AWS Updated 2026-10-08

Setting up AWS Cost Anomaly Detection so the next surprise pages you first

Set up AWS Cost Anomaly Detection so a spend spike reaches your team's chat or paging tool within about a day, long before the invoice arrives. You pick one monitor type, route individual alerts through Amazon SNS (Simple Notification Service), and set a dollar threshold people will not learn to ignore.

If you own an AWS bill and want to hear about a spending spike days before the invoice, AWS Cost Anomaly Detection is the tool to set up, and it takes about fifteen minutes. The service is free. It learns your normal spend for each AWS service and flags days that break the pattern. The usual problem is that nobody hears the alert. A monitor gets created once, its alerts go to an inbox nobody reads, and the spike turns up on the month-end invoice instead.

The working setup has three parts. Create one monitor that watches every AWS service in the account. Send individual alerts to Amazon SNS (Simple Notification Service), which forwards them to Slack, Teams or a paging tool. Then set a dollar threshold high enough that each alert is worth interrupting someone for. Expect an alert within about a day of a spike, because AWS billing data arrives with a delay.

What’s happening

Cost Anomaly Detection trains a model on your historical spend per segment and flags deviations above the learned pattern — it catches “unusual for you,” which fixed budget thresholds cannot, because it adapts to weekly cycles and gradual growth. Three mechanics shape the setup.

Monitors define the segmentation. An AWS-services monitor models each service independently and is the recommended default — one per account, and it evaluates every service without further configuration. Custom monitors segment by linked account, cost category, or cost allocation tag instead; they make sense in an Organization where different teams should get different alerts, but they analyze total spend per segment rather than per service, so they are coarser instruments.

Subscriptions define who hears about it. Individual alerts fire as anomalies are detected and can deliver to SNS (which is how you reach Slack, Teams, or PagerDuty); daily and weekly summaries deliver by email only. The threshold on a subscription — absolute dollar impact, percentage impact, or a combination — is your noise valve.

Detection is not instant. The service evaluates after billing data is ingested, roughly a few times a day, and the underlying data itself lags. Expect to hear about a spike within about a day of it starting, sometimes sooner. A brand-new account or a brand-new service also needs some usage history before the model has a baseline to deviate from.

What to check first

  • Does a monitor already exist? Accounts often have one created during console exploration, subscribed to an inbox nobody reads.
  • Where do alerts land today? An alert that lands in a personal inbox is decoration.
  • Do you run Organizations? Configure in the management account (or delegated admin) to cover member accounts, and decide whether member-level teams need their own segmentation.
  • What dollar impact is worth interrupting someone for? Pick the number before the console asks you.

How to verify

# What monitors exist right now?
aws ce get-anomaly-monitors

# What has been flagged in the last 30 days?
aws ce get-anomalies \
  --date-interval StartDate=2026-06-04,EndDate=2026-07-04

Console path: Billing and Cost Management > Cost Anomaly Detection. The Detection history tab is the fastest health check — a populated history with no subscription means the tool has been silently working and nobody wired up the output.

The runbook

  1. Create the AWS-services monitor. Console: Cost Anomaly Detection > Cost monitors > Create monitor > AWS services. Or CLI:

    aws ce create-anomaly-monitor \
  --anomaly-monitor '{"MonitorName":"account-services","MonitorType":"DIMENSIONAL","MonitorDimension":"SERVICE"}'

  2. Create an individual-alert subscription to SNS. SNS is the integration point for anything that pages. Threshold below is “alert when total anomaly impact reaches $100” — set yours to the interruption-worthy number you chose:

    aws ce create-anomaly-subscription \
  --anomaly-subscription '{"SubscriptionName":"anomaly-individual","MonitorArnList":["<monitor-arn>"],"Subscribers":[{"Type":"SNS","Address":"arn:aws:sns:us-east-1:111111111111:cost-anomalies"}],"Frequency":"IMMEDIATE","ThresholdExpression":{"Dimensions":{"Key":"ANOMALY_TOTAL_IMPACT_ABSOLUTE","MatchOptions":["GREATER_THAN_OR_EQUAL"],"Values":["100"]}}}'

    The SNS topic needs a resource policy allowing costalerts.amazonaws.com to publish — the console flow offers to set this up; from the CLI you write the topic policy yourself.

  3. Add a weekly email summary as the safety net. A second subscription, frequency weekly, to a shared mailbox. It catches the slow-burn anomalies that sit under the individual-alert threshold.

  4. Wire SNS into the on-call path. Same pattern as CloudWatch alarms — the delivery plumbing you already use for the CloudWatch alarm baseline is the right destination here too. A cost anomaly is an operational event; route it like one.

  5. Run the response play when it fires. The alert names the service, account, and usage-type contributors — that is the head start. The rest is the same 60-minute sequence in the bill-spike triage. Mark real events as such and false positives as false in the detection history; the feedback is stored with the anomaly record.

  6. Review the threshold after a month. More than a couple of alerts a week means the threshold is training people to ignore it — raise it, or switch to a percentage-plus-absolute combination.

When this is the wrong move

Anomaly detection catches deviations from pattern; it will never flag spend that has always been wasteful — a steady oversized fleet is “normal” to the model. It is also the wrong single control for hard spend caps: it has no enforcement arm. Pair it with AWS Budgets for threshold alerting and forecasting; the two tools overlap less than they appear to. Details on the tooling family are in the AWS Cost Management docs.

Common mistakes

  • Email-only subscriptions. Individual alerts to SNS are the only path that reaches a channel people watch in near real time.
  • Threshold set to a token amount. The first week of small-dollar alerts ends with a mail filter, and the tool is dead in the org.
  • Configured only in one member account. Monitors see the account they live in; Organization-wide coverage comes from the management or delegated-admin account.
  • Expecting it to catch a leak within the hour. Data latency makes this a day-scale control; live protection is capacity limits and code review, not billing telemetry.

Prevention

  • Test the SNS path end to end when you create it — publish a test message and confirm it lands in the channel.
  • Re-check subscriptions when people leave; orphaned email subscribers are the most common silent failure.
  • Add monitor and subscription creation to your account-baseline template so new accounts are born covered.
  • Revisit thresholds quarterly as spend grows; a threshold sized for last year’s bill is noise or blindness a year later.

Fifteen minutes of setup buys you a system where the next runaway job is a Tuesday-morning Slack message instead of a month-end incident review. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.