AWS Builder Center
From Cloud Cost to Cloud Clarity: Building a Simple AWS Cost Watchdog

From Cloud Cost to Cloud Clarity: Building a Simple AWS Cost Watchdog

A small, practical project can make cloud spending easier to understand. This article walks through a lightweight AWS cost watchdog that checks estimated costs, flags unexpected changes, and sends a clear daily summary—so teams can catch surprises before the bill arrives.

The bill that arrived too late

Cloud bills rarely feel surprising because of one enormous decision. More often, they grow through small changes: a test instance left running, storage that was never cleaned up, or a workload that quietly became busier.
I wanted a simple way to notice those changes earlier. The goal wasn’t to build a full cost-management platform. It was to create a small watchdog that could answer three questions:
  • What has our estimated spend been lately?
  • Which service changed the most?
  • Should someone take a closer look?
AWS already provides the data needed to begin. With the right permissions, a scheduled function can request cost and usage information, summarize it, and send a report to a team.

Start with a useful report

A cost notification is only helpful if people can understand it quickly. Instead of sending a long export, the watchdog can share a short summary:
Estimated spend this month: $42.18
Largest change: Amazon EC2, up 18% from last week
Next step: Review instances running outside business hours
The report should make clear that these are estimates, since billing data can take time to update. It should also link people to the AWS billing console for details rather than trying to explain every line item in an email.

A small AWS design

One straightforward version uses three AWS services:
  1. AWS Cost Explorer provides cost and usage data.
  2. AWS Lambda runs a short scheduled check.
  3. Amazon SNS sends the summary to an email subscription or team notification endpoint.
Amazon EventBridge can trigger the Lambda function each morning. The function compares the latest available period with a previous one, applies a threshold, and formats the result.
For example, a team might choose to alert when total estimated spend rises by more than 15% week over week, or when a single service crosses a monthly budget. Those thresholds should reflect the team’s normal usage; a development account and a production account may need very different rules.

Keep the first version boring

The first version should do a few things reliably:
  • Read costs for a defined account and time window.
  • Group results by AWS service.
  • Compare the latest period with a previous period.
  • Send a readable summary.
  • Log failures so a missing report isn’t mistaken for a quiet day.
It should also follow least-privilege access. The Lambda role needs permission to read the cost data and publish the notification, but it should not receive broad administrative access.
I’d begin with a single account and one daily email. Once that works, it’s easy to add separate reports for environments, budgets, or cost allocation tags.

What can go wrong?

A cost watchdog can create noise if its comparisons are too sensitive. A brief increase may be expected during a release or a batch job. If every fluctuation triggers an alert, people will stop paying attention.
A few small design choices help:
  • Compare equivalent periods, such as the last seven complete days with the seven days before them.
  • Avoid treating partial current-day data as final.
  • Include the amount and percentage change, not just “cost increased.”
  • Set a minimum dollar change as well as a percentage threshold.
  • Send a daily digest for ordinary changes and reserve urgent notifications for budget limits.
The watchdog should also say when its data is incomplete or unavailable. A failed query is not the same as zero spending.

Make the report lead to action

The most useful notification points to a next step. A service-level increase might prompt a review of recent deployments. A rise in storage could lead to checking retention settings. A budget warning might mean contacting the service owner before making changes.
The report can include a link to the relevant billing view and the account or environment name. That context turns an alert from a number into a starting point for investigation.

A small habit with a measurable payoff

A daily cost summary won’t replace budgets, architecture reviews, or careful resource management. It can, however, shorten the time between a change in usage and someone noticing it.
That’s a good first cloud-finops project: small enough to build in an afternoon, useful enough to keep, and easy to expand as the team learns which signals matter.
The best version isn’t the one with the most charts. It’s the one that helps someone ask, “Is this expected?” while there’s still time to do something about it.
2:08 AM
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