Chapter 2 of 9 · 5 checks · 3 min
Budgets and anomaly alerts
Whether unexpected spend is caught within a day by the team that caused it, not at the end of the month by finance.
Each team, account or project has a budget with alertsMust
Why it matters and how to check
A budget turns "is this normal?" into a notification. Remember that most budgets only alert: Google Cloud's documentation states plainly that an alerts-only budget does not cap usage or spending. Its default alert thresholds are 50%, 90% and 100% of the budget amount; adjust them to what is useful to you.
To verify: open AWS Budgets, Google Cloud Budgets and alerts, or Azure Cost Management budgets and confirm each team or project has one, set to a realistic amount from the cost model, with thresholds on both actual and forecast spend.
Cost anomaly detection is turned on and covers every accountMust
Why it matters and how to check
Budgets catch slow drift; anomaly detection catches a sudden spike, such as a runaway job or a misconfigured autoscaler, against your normal pattern. AWS documents that Cost Anomaly Detection runs roughly three times a day, can take up to 24 hours to detect an anomaly after the usage occurs, and needs 10 days of history before it can detect anomalies for a newly used service. Google Cloud and Azure offer anomaly alerts in their cost tools as well.
To verify: check anomaly monitors exist for all accounts or the whole billing scope, with alert subscriptions set. Look at the last few detected anomalies: did someone look at each within a day?
Budget and anomaly alerts reach the owning team, not only financeMust
Why it matters and how to check
An alert sent to a finance mailbox arrives with nobody who can stop the cause. The FinOps principle that teams need to collaborate applies here: finance sees the number, engineering knows what changed.
To verify: for each budget and anomaly monitor, read the recipients. At least one should be the owning team's channel or on-call alias. Trigger a test notification, or lower a sandbox budget temporarily, and confirm the team sees it.
Sandbox and experiment accounts have automatic spend guardrailsNice to have
Why it matters and how to check
Sandboxes are where forgotten GPU instances and test clusters live. The Azure checklist asks for spending guardrails such as governance policies and resource limits, preferring automation to manual processes. Budget actions (AWS Budgets actions, Google Cloud programmatic budget notifications, Azure budget action groups) can apply a restrictive policy or stop resources when a threshold is crossed.
To verify: check each sandbox account has a budget with an automated action and a policy limiting expensive resource types or regions. Test the action in a throwaway account.
New workloads have a cost estimate before launchShould
Why it matters and how to check
The Azure cost checklist asks for a cost model that estimates initial cost, run rate and ongoing cost, and a budget with a buffer for unplanned spend. Without an estimate, nobody can tell whether the first month's bill is a success or a problem.
To verify: for the last two launches, find the estimate (a pricing calculator export or a short table in the design doc) and compare it with the first full month of real cost. A big gap is a reason to find out why, not a failure in itself.