Budgets and Alerts: Finding Out Before the Invoice

Set these up first

1. A monthly budget at your expected spend, with alerts at 50, 80 and 100 per cent of the forecast.
2. A forecast alert, which fires when the projected month-end total exceeds the budget — often days before the actual figure would.
3. A daily spend alert at roughly 1.5 times normal daily spend. This is the one that catches a runaway within hours rather than weeks.
4. Anomaly detection, available on all major platforms, which flags unusual patterns rather than absolute thresholds.
5. Per-service budgets for anything that can scale without limit — compute, egress, serverless invocations.

The daily alert is the most valuable and the least commonly configured. Monthly budgets tell you about a problem after most of the damage is done.

Where to find them

All of these are free. There is no cost argument against configuring them.

Tagging is what makes alerts actionable

An alert saying spend rose 40 per cent is useful. An alert saying spend on the staging environment for the search project rose 40 per cent is immediately actionable.

• Decide a small tag set: environment, project, owner, cost centre. Four is enough.
• Apply them in infrastructure code so new resources are tagged automatically.
• Enforce with policy where the platform supports it — reject untagged resources.
• Report on untagged spend monthly and drive it toward zero.
• Enable cost allocation tags in the billing console, or tags will not appear in cost reports.

That last step is easy to miss on AWS: tags exist but do not show in cost reporting until activated, and activation is not retroactive.

Route alerts where someone will see them

A billing alert to an unmonitored address is a log entry. Send budget alerts to the same channel as operational alerts — chat, on-call, wherever the team actually looks.

Include the account, the service and the amount in the message. An alert that requires logging in to understand is an alert that gets deferred.

Hard limits, where they exist

Most cloud platforms will not stop serving when a budget is exceeded, since that would cause outages. You can approximate limits yourself:

• Set maximum sizes on autoscaling groups so scaling cannot run away.
• Set concurrency limits on serverless functions.
• Use service quotas as a ceiling on resource creation.
• For non-production accounts, trigger an automated shutdown on a budget alert.
• Restrict which instance families and regions can be used, so an expensive mistake is not available.

Automated shutdown on budget breach is appropriate for development and dangerous for production. Apply it deliberately.

A monthly review that takes fifteen minutes

1. Total spend against budget, and the trend over three months.
2. The top ten line items, and whether each is expected.
3. The largest month-on-month increases.
4. Untagged spend as a proportion of the total.
5. Commitment utilisation, if you have any.
6. One action item. Not ten — one that will actually get done.

Common questions

Where to go next

See why cloud bills surprise people and cutting a cloud bill.