AWS Budgets and cost anomalies: how to read them without mixing them up
Let's discuss your project →AWS Budgets compares costs and forecasts with a target; updates occur up to three times daily, typically every 8–12 hours. An alert alone does not stop resources: optional actions require configuration. (AWS Budgets)
Cost Anomaly Detection requires a monitor and an alert subscription; it identifies deviations and potential causes. Treat its notification as the start of an investigation. (AWS documentation)
Initial setup: a worksheet to complete
The following is a Dedaloop editorial workflow to adapt to your environment.
- Scope: choose a pilot project and record its account, included services and owner. Check that the responsible person can read cost data.
- Target: write down the planned amount, period and inclusions. Separate recorded spending, future estimates and deviations from the usual pattern.
- Recipient: name a primary owner and a backup. Check the address, subscription and acknowledgement process; do not generate paid traffic just to trigger an alert.
- Authority: decide who can approve changes and which services must remain available. Start with notifications; assess automation separately.
- Record: prepare fields for date, amount, hypothesis, evidence, decision and follow-up.
When an alert arrives
Save its time and type. Compare equivalent periods and check whether the figure is recorded spending or a forecast. Then examine service, region, account and project attribution.
| Hypothesis | Check | Owner |
|---|---|---|
| Planned release | Compare release calendar and usage | Application team |
| Test left running | Identify resource and owner | Operations |
| Wrong attribution | Check tags and cost centre | Cloud lead |
| Necessary service | Check dependencies and availability needs | Service owner |
An incorrect tag can misattribute spending; it does not prove that the tag caused the consumption. Before stopping a resource, check production, backup, security and continuity dependencies. If nobody owns it, escalate: a missing name does not authorize deletion.
Simulated example: from €40 to €120
Assume a teaching baseline of €40 per day and €120 observed: the difference is €80, or 200% of the baseline. This is neither an AWS model result nor a recommended threshold.
In this fictional case, the owner finds an authorized test that should have ended the previous evening. Before closing it, they check retention needs and whether another service depends on it. They record the action and review costs after the data updates. If a planned release explains the increase instead, they record that reason and discuss the budget with its approver.
Acceptance criteria
Close the ticket when it has an owner, an evidence-backed explanation, an authorized decision and a follow-up date. An alert disappearing is not sufficient by itself.
Measure acknowledgement time, alerts without owners and interventions that require correction. Do not promise savings before establishing a baseline. If you want to establish this process, tell us which part of cloud operations currently creates the most friction.