Everyone's talking about AI-powered, ML-driven, next-gen cost anomaly detection platforms. The sales decks promise you'll catch every stray penny with magical algorithms. Meanwhile, the quotes start at $50k a year and the implementation looks like a multi-quarter ordeal. I decided to see what I could cobble together in an afternoon using the tools already billing me.
Spoiler: It's not perfect, but it cost me about $3.50 in AWS charges last month and it pings a Slack channel every time my daily AWS bill jumps by more than 20% versus the previous day. It's saved my team from two unexpected spend escalations already—one from a misconfigured S3 lifecycle rule and another from a dev environment auto-scaling group gone wild.
The core idea is simple. You don't need a neural network to tell you that a 50% day-over-day cost increase is a problem. You just need the data, a baseline, and a simple threshold. Here's the architecture:
* **Source:** AWS Cost Explorer API, specifically the `GetCostAndUsage` call for daily granularity.
* **Trigger:** A CloudWatch Event Rule scheduled to run daily, just after the bill updates (I set mine for 2 AM UTC).
* **Logic:** A Python Lambda function that fetches the last two days of spend, compares them, and evaluates against a rule.
* **Alert:** A simple Slack webhook notification. Could easily be SNS, PagerDuty, or an email.
The real "insight" here is using CloudWatch Metrics for the actual anomaly detection. The Lambda publishes the daily spend as a custom metric, and then you can use CloudWatch Anomaly Detection on that metric to establish a dynamic baseline. This is the part that moves beyond a simple static percentage threshold.
Here's the core of the Lambda function (Python 3.9):
```python
import boto3
from datetime import datetime, timedelta
import os
import json
import requests
cost_explorer = boto3.client('ce')
cloudwatch = boto3.client('cloudwatch')
def lambda_handler(event, context):
# Get yesterday and the day before's costs
end = datetime.now().date()
start = end - timedelta(days=2)
response = cost_explorer.get_cost_and_usage(
TimePeriod={'Start': str(start), 'End': str(end)},
Granularity='DAILY',
Metrics=['UnblendedCost']
)
days = response['ResultsByTime']
days.sort(key=lambda x: x['TimePeriod']['Start'])
if len(days) = threshold_increase:
slack_message = {
"text": f"🚨 AWS Cost Anomaly Detected!n*Yesterday:* ${cost_yesterday:.2f}n*Day Before:* ${cost_day_before:.2f}n*Increase:* {increase_percent:.1f}%"
}
requests.post(os.environ['SLACK_WEBHOOK_URL'], json=slack_message)
return
```
Then, in CloudWatch, you create an anomaly detection model on the `Custom/Billing` metric. It will learn your weekly spend patterns (like lower weekends) and alert on true statistical anomalies, not just every Monday when work resumes.
**The Caveats (because of course there are some):**
* This is *daily* and *lagging* by about 12-24 hours. It won't catch a runaway instance in real-time.
* It's for the entire linked account. You'd need to modify the Cost Explorer query to drill into services or tags for more granularity.
* CloudWatch Anomaly Detection takes a few weeks to learn and isn't as tunable as a proper ML model.
But for the 95% of startups and mid-size companies I talk to, this is a more than sufficient first pass. It forces you to look at the data daily, and it costs less than a cup of coffee. Before you sign that PO for the shiny platform, maybe see how far the native tools can get you.
—MB
—MB
Sounds good until your cost anomaly detector itself has a cost anomaly. That Lambda reading Cost Explorer data, what's it logging? Where are the metrics stored? If your team gets excited and starts querying it more, costs climb.
Plus, you're now on the hook for maintenance. AWS changes an API field, breaks your script, and you get no alert for a week because the Lambda was erroring. The $50k platform's real cost isn't the algorithm, it's the someone-else's-problem factor.
Still, proving you can do the basics for pennies is a useful exercise. Just don't tell management, or they'll expect everything to be that cheap.
Read the contract
Your point about the "someone-else's-problem factor" is precisely where the business case gets interesting. That $50k annual fee isn't for a better algorithm, it's an insurance premium against the operational drag you just outlined: API changes, monitoring the monitor, and alert fatigue.
Where I differ is the assumption this must be a binary choice between a brittle DIY script and a full platform. The logical next step after proving the concept isn't to stop or buy. It's to formalize the script into a documented, version-controlled service with its own CloudWatch alarms for invocation failures and error rates, which costs almost nothing extra. This transforms it from a hidden liability to a managed asset, still at a fraction of the external platform cost.
The real risk is the cultural one you noted at the end. When a $3.50 solution works, it sets a dangerous precedent that overlooks the cumulative tax of a dozen similar "good enough" solutions maintained across the team. The value of the expensive platform is often in forcing a single, sanctioned approach.