AWS Builder Center

Builder Center

What If Your AWS Bill Suddenly Doubled? Build a Cost Anomaly Detector with Terraform

What If Your AWS Bill Suddenly Doubled? Build a Cost Anomaly Detector with Terraform

Unexpected AWS spending can be difficult to identify without automated monitoring. In this project, I explore how to build a serverless AWS Cost Anomaly Detector using Terraform, AWS Lambda, Amazon EventBridge, AWS Cost Explorer, IAM, and Amazon SNS. The system compares daily AWS costs against a historical average and can send email alerts when spending exceeds a configurable threshold. 🚀 Explore the project on GitHub: https://github.com/sudipparamanik/Terraform-Projects

Introduction: The hidden challenge of cloud computing

Cloud computing makes it easier than ever to build and deploy applications. With services like Amazon EC2, S3, Lambda, and API Gateway, developers can create powerful solutions without managing every part of the underlying infrastructure.
But there is another side to cloud computing: cost management.
Imagine working on a personal AWS project and discovering that your daily spending has suddenly increased. A resource might have been left running, application requests may have increased, or storage usage might be growing unexpectedly.
Without monitoring, identifying the cause can take time.
This inspired me to explore a practical question:
Can we use AWS services and Terraform to automate basic cloud cost monitoring and receive an alert when spending increases beyond a defined threshold?
In this article, we will explore the architecture, detection logic, and engineering considerations behind a custom AWS Cost Anomaly Detector.

Project overview

The goal is to build a small, serverless monitoring workflow that:
  • Retrieves daily cost data from AWS Cost Explorer.
  • Calculates an average from the previous seven completed days.
  • Compares the latest completed day's cost against a configurable threshold.
  • Publishes an email alert through Amazon SNS when the threshold condition is met.
  • Uses Amazon CloudWatch logs to help inspect execution and troubleshoot errors.
  • Uses Terraform to define and manage the infrastructure.
This is a custom, threshold-based monitoring solution. It is different from AWS Cost Anomaly Detection, which uses machine learning to identify unusual spending patterns.

Architecture: How the services work together

The design uses managed AWS services so there is no need to maintain a continuously running server just to perform a daily check.
Architecture flow:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Terraform
|
| Provisions infrastructure
v
Amazon EventBridge
|
| Daily scheduled trigger
v
AWS Lambda (Python)
|
| Retrieves daily cost data
v
AWS Cost Explorer API
|
| Returns cost information
v
Cost comparison logic
|
+---- Threshold exceeded ----> Amazon SNS ----> Email alert
|
+---- Threshold not exceeded -> CloudWatch Logs
IAM controls the permissions required for Lambda to access the Cost Explorer API, publish to the designated SNS topic, and write logs.

The role of each AWS service

1. Terraform — Infrastructure as Code
Terraform defines the resources and their configuration in code. This makes infrastructure changes easier to review, reproduce, and maintain.
2. Amazon EventBridge — Scheduling
EventBridge triggers the Lambda function on a recurring schedule. This removes the need to run a separate server or manually start the monitoring process.
3. AWS Lambda — Cost analysis
A Python function retrieves the required daily cost data, calculates the historical average, evaluates the threshold, and decides whether to publish an alert.
4. AWS Cost Explorer — Cost data
The Cost Explorer API provides daily cost and usage information. The solution uses this information as the basis for its comparison.
5. AWS IAM — Access control
IAM grants the Lambda execution role only the permissions needed for the monitoring workflow.
6. Amazon SNS — Notifications
SNS distributes the alert message to a confirmed email subscription when the configured condition is met.
7. Amazon CloudWatch — Observability
CloudWatch logs help track function execution, inspect cost calculations, and investigate errors.

How does the cost detection logic work?

The detector uses a straightforward rule rather than a complex prediction model.
First, it retrieves the latest eight completed daily cost periods. It then identifies the latest completed day's cost and calculates the average of the preceding seven days.
The threshold is calculated using this formula:
Alert Threshold = Seven-Day Average × Threshold Multiplier
For example, suppose the average daily cost over the previous seven days is $4.00 and the multiplier is set to 1.5.
The threshold would be:
$4.00 × 1.5 = $6.00
If the latest completed day's cost is $8.00, the cost exceeds the threshold and the system can publish an SNS email alert.
These numbers are illustrative examples, not actual results from a deployed AWS account.
A configurable minimum-cost condition can also reduce unnecessary alerts when spending is very low.

Why use a historical average?

A historical average provides a simple baseline for comparison. It helps beginners understand how automated monitoring decisions can be made from real billing data.
However, this approach has limitations. An increase in cost does not necessarily mean something is wrong, and a seven-day average may not reflect weekly usage patterns. More advanced solutions can use longer historical windows, service-level cost breakdowns, and native AWS cost-monitoring tools.

Why Terraform matters in this project

It is possible to create each resource manually in the AWS Console. However, managing multiple connected services becomes easier when the infrastructure is defined as code.
Terraform helps by providing:
  • Repeatability: Recreate infrastructure from configuration.
  • Change visibility: Review proposed changes with terraform plan.
  • Version control: Track infrastructure changes alongside application code.
  • Maintainability: Keep resource definitions and configuration organized.
  • Automation opportunities: Integrate infrastructure provisioning into a CI/CD workflow.
For someone learning cloud engineering, this project provides practical experience with the infrastructure lifecycle: initialization, validation, planning, deployment, testing, and cleanup.

Security and reliability considerations

A cost monitoring system must be designed carefully so that the monitoring solution does not introduce unnecessary risks.
Least-privilege permissions: Restrict IAM permissions to the API actions and resources the function actually needs.
Billing data freshness: Cost Explorer data may be delayed or revised. The function should handle incomplete data safely and should not assume that all returned figures are final.
Notification delivery: The SNS email subscription must be confirmed. Lambda execution logs should be checked when an expected notification does not arrive.
Duplicate notifications: Retries or repeated evaluations may produce duplicate alerts. A production-oriented implementation should consider deduplication.
Cost awareness: Cost Explorer API requests and other AWS service usage may incur charges. Review current pricing before deploying or increasing execution frequency.
Additional safeguards: AWS Budgets and AWS Cost Anomaly Detection can complement a custom monitoring workflow. A custom script should not be treated as a real-time spending guarantee.

What could be improved next?

This project can be extended in several useful directions:
  1. Service-level cost analysis: Identify which AWS services contribute most to a spending increase.
  2. Improved baselines: Compare similar days of the week or use a longer historical period.
  3. CloudWatch alarms: Monitor Lambda failures, execution duration, and other operational metrics.
  4. Alert deduplication: Avoid repeatedly sending the same notification for an unchanged condition.
  5. Automated testing: Test normal spending, threshold boundaries, missing data, and API failures using controlled sample data.
  6. CI/CD integration: Automate validation and deployment while keeping credentials and Terraform state secure.
These improvements could make the system more useful for ongoing cloud operations.

Explore the source code

I am building and documenting cloud projects to strengthen my understanding of AWS, Terraform, and serverless architecture.
You can explore my Terraform projects here:
GitHub repository: sudipparamanik/Terraform-Projects 
The repository is a place to explore the project code, review the infrastructure configuration, and follow my hands-on learning journey. Check the aws-cost-anomaly-detector project directory for the relevant files.
I welcome suggestions, feedback, and ideas for improving the architecture.

Conclusion

Cloud engineering is not only about deploying applications. It is also about understanding resource usage, controlling access, monitoring system behavior, and making informed decisions about cost.
This AWS Cost Anomaly Detector project brings together Terraform, Lambda, EventBridge, IAM, SNS, and Cost Explorer to demonstrate how a small serverless workflow can automate a useful cloud operations task.
The most important takeaway is that cost awareness should be part of cloud design from the beginning, not something we think about only after receiving a bill.
If you were building a cost monitoring solution for a personal AWS account, would you choose a custom threshold-based approach, AWS Budgets, or AWS Cost Anomaly Detection?
I'd love to hear your thoughts and suggestions.

Official documentation

#AWS #Terraform #Serverless #CloudComputing #DevOps
# terraform# serverless# aws-cloud9# aws-cloudwatch# devops
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article