CloudCostCompareCloud budgets and cost alerts: set them before you need them
The cheapest way to catch a cost mistake is to be told about it the same week. Every major cloud has a budgeting feature for that. Most teams set one only after the first surprise.
What the feature is called
| Cloud | Feature |
|---|---|
| AWS | AWS Budgets, plus cost anomaly detection |
| Azure | Budgets in Cost Management |
| Google Cloud | Budgets and alerts in Cloud Billing |
| Oracle Cloud | Budgets in Cost Management |
You set an amount for a period, usually a month, and choose thresholds that send a notice by email or to a message topic.
Alerts warn, they do not stop
This is the point most people miss. A budget alert is a notification. By default it does not stop spending, shut down a resource or block new ones. If a loop in your code creates servers all night, the alert arrives and the servers keep running until somebody acts.
Some clouds can run an automatic action when a threshold is crossed, such as stopping instances or removing permissions. That needs setting up deliberately and testing, because a wrong automation can take down production. For a learning account, a hard stop is reasonable. For production, an alert to a person is usually the safer choice.
Alerts lag
Cost data arrives with a delay, often several hours and sometimes more than a day. An alert at 100 percent of budget is already late. This is why forecast-based alerts, which warn that you are on course to pass the budget, are more useful than actual-spend alerts alone.
A starter set
- One account-level budget equal to what you expect to spend in a month.
- Actual-spend alerts at 50, 80 and 100 percent.
- A forecast alert at 100 percent, so you hear about a projected overrun while there is time to fix it.
- A very low budget on any learning or sandbox account, so a forgotten resource is noticed within days.
- A budget per project, once you tag your resources.
Who gets the alert
Send it to a shared address or channel, not one person’s inbox. An alert nobody reads is the same as no alert. Name an owner who looks at it the same day.
What to do when one fires
Open the cost report grouped by service and by tag, find what changed compared with last week, and check for the usual causes: a new resource, a traffic spike, data transfer, logs, or something left running. The checklist is in cloud cost mistakes to avoid.
Making this a regular habit is the core of FinOps.