Create a Cloud Cost Anomaly Alert

Enable AWS Cost Anomaly Detection with a dollar threshold and route alerts to the owning team's on-call channel.

~25 minawscostalerting

Task

Catch runaway spend within a day instead of at the end of the billing cycle when the invoice is already final.

When to use this

A load test is left running over the weekend and doubles the monthly compute bill. The team only notices in the monthly cost review, after the spend is committed and the budget is blown.

Prerequisites

AWS Cost Explorer enabled for the account
An SNS topic with an email or chat subscription
Permissions to create Cost Anomaly Detection monitors

Steps

1. Create a dimensional monitor that tracks spend per AWS service.

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

Expected output: The response contains a MonitorArn for acme-services.

2. Subscribe the on-call SNS topic with a daily threshold of 100 dollars.

aws ce create-anomaly-subscription \
  --anomaly-subscription '{
    "SubscriptionName": "acme-cost-alerts",
    "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/abc123"],
    "Subscribers": [
      {"Address": "arn:aws:sns:us-east-1:123456789012:platform-alerts", "Type": "SNS"}
    ],
    "Threshold": 100,
    "Frequency": "DAILY"
  }'

Expected output: Anomalies with an estimated impact above 100 dollars generate an SNS notification the next day.

3. Confirm the subscription exists and review the detection history in Cost Explorer.

aws ce get-anomaly-subscriptions --query 'AnomalySubscriptions[].SubscriptionName' --output text

Expected output: acme-cost-alerts is listed, and the Cost Explorer anomaly page shows any detected events with impact estimates.

4. Document the response: identify the service, compare with deploys, and stop the resource.

aws ce get-cost-and-usage --time-period Start=2026-10-20,End=2026-10-21 --granularity DAILY --metrics UnblendedCost --group-by Type=DIMENSION,Key=SERVICE

Expected output: A per-service cost breakdown that identifies which service increased and by how much.

Troubleshooting

Problem

No anomalies are detected after enabling the monitor

Solution

Detection needs roughly ten days of historical spend; wait for the baseline to build and verify the monitor dimension covers the service you expect.

Problem

Alerts are too noisy for small fluctuations

Solution

Raise the dollar threshold, or add an absolute impact filter so only anomalies above a meaningful amount notify the channel.

Limitations

Detection is daily and not real-time; a fast runaway can still spend significantly before the alert.
Anomaly attribution is by service or account, not by individual resource or person.

Thresholds catch what budgets miss

A monthly budget alert fires when the total crosses a line, often too late to act. Anomaly detection compares current spend with a learned baseline per service and alerts on the deviation. That catches a forgotten load test or a misconfigured autoscaler within a day, while the spend is still controllable.

Set a meaningful threshold

A threshold that is too low produces noise on normal daily variation; too high and real anomalies pass. Start at a dollar amount that matters to the business, such as 100 dollars per day, and route it to the owning team rather than a general finance channel. Use a dimensional monitor by service so the alert names where the money went.

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

Build the response

The alert is only useful with a runbook. The responder checks the service cost breakdown, correlates with deploys and test schedules, and stops or right-sizes the resource. Record the cause and the fix in the incident ticket. If the anomaly was legitimate growth, adjust the baseline expectation rather than silencing the monitor.

Cover the gaps

Anomaly detection does not replace budgets, commitments, or tagging. Add cost allocation tags so the breakdown can be attributed to a team, and review the detection history monthly. For sandbox accounts, use a much lower threshold; for production, tune against a few weeks of observed variance before trusting the alerts. Verify the path by publishing a message directly to the SNS topic and confirming it reaches the on-call channel, then wait for the first real detection to validate the threshold.