Searching cloud budget vs forecast vs anomaly alert suggests picking one control, but a budget, a forecast alert and an anomaly alert answer three different questions. Are we within the amount we agreed? Will we exceed it before the period ends? Has something just happened that does not fit the usual pattern? Use one control to answer another's question and you get alerts that arrive too late or that nobody reads any more. This guide sets out what AWS, Azure and Google Cloud document today, how long each control takes to react, who should receive which alert, and ends with a decision table for teams without a FinOps function.
Three questions, three controls
| Question | Control | Compared against | Typical response |
|---|---|---|---|
| Are we within budget? | Budget with an actual-cost threshold | Cost accrued in the period against the budget amount | Explain the variance at the monthly review, or change the budget deliberately |
| Will we exceed it? | Budget with a forecast threshold | Projection to period end against the budget amount | Find the cause while the period is still open; get approval if needed |
| Has something unusual happened? | Anomaly detection | Actual against expected cost learned from history | Investigate the same or the next working day |
The key difference is the reference point. Budgets and forecasts measure against a number you set. Anomaly detection measures against a pattern the provider learns from your history. One service can double without a budget reacting, because other costs fell. A budget can be exceeded with no anomaly at all, because growth was steady and predictable. And a detected outlier is not an explanation: it is a cost insight that starts an investigation.
None of these controls stops spending on its own. Azure says so plainly: resources are not affected and consumption continues. On Google Cloud, an alerts-only budget does not cap usage or spend.
What the providers document today
AWS Budgets
AWS Budgets covers cost, usage, Reserved Instance and Savings Plans budgets, with notifications on actual or forecast values. Budget data is updated up to three times a day, typically 8 to 12 hours after the previous update. An actual-cost alert fires once per budget per period, when the threshold is first reached. A forecast alert can fire several times if the projection rises above the threshold, falls back and rises again. AWS needs roughly five weeks of usage data to produce forecasts; until then a forecast alert does not trigger.
Each alert can go to up to ten email addresses and one Amazon SNS topic. You choose the cost basis: unblended, amortised or net, with or without credits, taxes and support charges. Custom-period budgets do not renew and expire on their end date. Budget actions can, for example, apply an IAM policy that denies new resources once a threshold is reached. AWS warns that there is a gap between usage and notification in which further cost accrues.
AWS Cost Anomaly Detection
Cost Anomaly Detection evaluates net unblended cost roughly three times a day once billing data is processed. Because its Cost Explorer data can lag by up to 24 hours, detection can take up to 24 hours after the usage. A new monitor needs 24 hours, and a newly used service needs ten days of history.
AWS managed monitors track all services, all member accounts, every value of a cost allocation tag, or every value of a cost category, up to 5,000 values each. Customer managed monitors aggregate up to ten selected values. A subscription delivers individual alerts through SNS, a daily email summary of the ten largest alerts (generated at 00:00 UTC for the previous day), or a weekly summary. Thresholds are absolute (cost impact) or percentage, and can be combined with AND or OR. An anomaly that lasts several days keeps sending notifications. The service does not monitor AWS Marketplace purchases, apart from third-party models in Amazon Bedrock; for those, AWS points to a cost budget filtered on the billing entity.
Azure budgets
Azure budgets are available on management groups, subscriptions and resource groups, and on Enterprise Agreement and Microsoft Customer Agreement (MCA) billing scopes. Cost and usage data typically arrives within 8 to 24 hours, budgets are evaluated against it every 24 hours, and the email normally follows within an hour of evaluation. A budget holds up to five thresholds and five email addresses, each set on actual or forecast cost. Action groups, for automation or push notifications, work only at subscription and resource group scope.
Two details cause missed alerts. Every subscription in a scope must use the same currency, or the budget may not be evaluated reliably. And at MCA billing account scope, evaluation runs in USD whatever the billing currency, which matters for a UK entity invoiced in GBP. Budgets evaluate actual cost, without amortisation.
Azure cost alerts and anomaly alerts
The Cost alerts page collects budget alerts and, for Enterprise Agreements, credit alerts at 90 and 100 percent of Azure Prepayment and department spending quota alerts. Anomaly detection runs daily per subscription: a model trained on 60 days of history predicts the day's usage, and evaluation starts 36 hours after the end of the UTC day. An anomaly alert is sent once, at detection, and lists the largest changes by resource group. It can be created only at subscription scope, at most five per subscription, and needs at least the Cost Management Contributor role. Azure checks the permissions of the rule's creator before each send, so the alert goes silent if that person loses access; As a workaround, Microsoft points to a service principal that creates the alert through the Scheduled Actions API.
Google Cloud budgets
Google Cloud budgets apply to a billing account, folders, projects, services or one label. Thresholds are percentages of the budget on actual or forecast cost; the defaults are 50, 90 and 100 percent of actual cost. Custom-range budgets cannot alert on forecasts. Discounts and credits are subtracted by default before a threshold is checked, and taxes such as VAT are included. Monthly budgets keep collecting late-reported usage for the first two days of the next month. The first notification can take several hours after you create a budget; Pub/Sub messages arrive several times a day with the current status. Billing account administrators and users receive email by default, and Cloud Monitoring channels add other recipients.
Google also offers spend-cap budgets for a small set of services, including the Gemini API and Cloud Run. Once the cap is exceeded the service pauses in that project, requests in flight are still billed, persistent resources keep running, and Google states that enforcement is not instantaneous. Separately, a cost anomaly feature per billing account reports standard anomalies through its next-day channels.
How long each control takes
| Control | Earliest documented signal |
|---|---|
| AWS Budgets | Updated up to three times a day, 8 to 12 hours apart, plus billing delay |
| AWS Cost Anomaly Detection | Up to 24 hours after usage; daily summary the following day |
| Azure budgets | Data in 8 to 24 hours, evaluated every 24 hours, email within an hour |
| Azure anomaly alert | Evaluated 36 hours after the end of the UTC day |
| Google Cloud budgets | First notification after several hours; Pub/Sub several times a day |
That sets a hard limit. None of these controls protects you from a fault that becomes expensive within hours, such as a retry loop against a paid API. That needs limits in the application, quotas on the service or, where one exists, a spend cap. The cloud controls are the safety net, not the first line.
Decision table
| Situation | Control | Recipient | Note |
|---|---|---|---|
| Fixed monthly amount per team, environment or customer | Budget with actual thresholds per scope | Cost owner of the scope; finance at the monthly review | Cut scopes so that one owner is accountable |
| Warn before the budget is breached | Forecast threshold at 100 percent of budget | Owner and whoever approves budget changes | Useful only with history; roughly five weeks on AWS |
| Unexpected jump in a service or account | Anomaly detection | Engineering channel or on-call | Individual alerts for production, summaries for team leads |
| New account or service with no history | Budget with low actual thresholds | Project owner | Anomaly models need data first |
| AWS Marketplace spend | Cost budget filtered on billing entity | Procurement and owner | Anomaly detection excludes Marketplace, apart from third-party models in Bedrock |
| Sandbox or experiment with a hard ceiling | AWS budget action or Google spend cap | Owner, agreed in advance | Allow for delay; persistent resources keep running |
| Reservation or Savings Plans utilisation | AWS utilisation or coverage budget | Whoever buys commitments | Measured in percent, not money |
| Azure scope spanning several currencies | Separate budgets per currency | Owner per entity | Otherwise alerts may be missed |
Who receives which alert
An alert without a recipient who can act on it is noise. Three rules hold up in small teams:
- Every alert has an owner and a response. Record next to each threshold who receives it and what they do within what time. Without that entry the alert gets deleted, not read.
- Budget alerts go to cost owners, anomaly alerts go to engineering. A budget breach is a planning question; an anomaly is usually a technical one. On AWS, route individual alerts through SNS into a chat channel; on Azure, send the email to a shared mailbox that a ticketing tool watches, as Microsoft describes.
- Avoid personal inboxes. Google's default sends to billing administrators, and Azure anomaly alerts depend on the creator's permissions. Both break when people change roles or leave.
Common misconfigurations
- Mismatched cost basis. The budget was set from the invoice, but evaluation runs on amortised cost or after credits. Azure budgets use actual cost without amortisation; Google subtracts discounts by default. Use the same basis as your monthly cloud cost review; CUR 2.0 or FOCUS covers which AWS columns qualify.
- Forecast without history. A forecast alert on a new account stays silent until enough data exists.
- Thresholds too low. Anomaly alerts with a small cost impact fire daily, and on AWS keep firing while the anomaly lasts. Combine an absolute and a percentage threshold.
- Treating an alert as a cap. Without an action or a spend cap, consumption continues.
- Expired budgets. AWS custom-period budgets end without notice; recurring budgets are the safe default.
- Unconfirmed channels. An SNS subscription nobody confirmed, or a sender address caught by the spam filter, stops delivery.
Set-up in seven steps
- List scopes with an owner: accounts, subscriptions, projects, and tag values where needed.
- Fix and document the cost basis per provider.
- Create one recurring budget with actual-cost thresholds per scope.
- Add forecast thresholds once there is enough history.
- Turn on anomaly detection: on AWS a managed monitor for services and one for member accounts, on Azure one alert per subscription, on Google check the thresholds in the anomalies dashboard.
- Test delivery: confirm SNS, allow the sender addresses, check the channel receives messages.
- At the monthly review, go through which alerts fired, what happened, and which threshold needs to change.
What Costfluent covers
Costfluent reads AWS, Azure and Google Cloud costs through read-only connectors. You create a budget for the whole workspace, a saved cost report or one segment, in the product, through the Public API or with the Terraform provider, and Costfluent compares actual spend with the budget for its period. Each budget carries its own thresholds as a share of its amount; Costfluent checks them every hour and reports a crossed threshold in the product and to the Email, Slack, Microsoft Teams or webhook channels the budget names, as your plan allows. Cost insights highlight significant changes, growing services and anomalies, and lead into the cost data behind them; spend and change thresholds of your own are cost alerts, created through the Public API. A saved cost report can be emailed daily, weekly or monthly. Budget spend forecasts are Planned (see budgets).
Sources and method
Checked on 10 October 2026: AWS: Managing your costs with AWS Budgets, AWS: Best practices for AWS Budgets, AWS: Detecting unusual spend with Cost Anomaly Detection, AWS: Getting started with Cost Anomaly Detection, Microsoft: Create and manage budgets, Microsoft: Cost alerts, Microsoft: Identify anomalies and unexpected changes in cost, Google Cloud: Create, edit, or delete budgets and budget alerts, Google Cloud: Spend caps and Google Cloud: View and manage cost anomalies. The decision table, routing rules and set-up steps are Costfluent recommendations.
